Ceph Storage – rozproszony storage dla nowoczesnej infrastruktury

Ceph to rozproszony system storage, który pozwala połączyć wiele serwerów i dysków w jeden logiczny system przechowywania danych.

Zamiast:

          Server
            |
         RAID/SAN
            |
          Disks

Ceph buduje storage z wielu niezależnych węzłów:

             Ceph Cluster
                  |
      +-----------+-----------+
      |           |           |
    Node 1      Node 2      Node 3
      |           |           |
   SSD/HDD      SSD/HDD     SSD/HDD

Dzięki temu można uzyskać redundancję, skalowanie poziome i brak pojedynczego punktu awarii.

Główna idea Ceph

Najważniejsza koncepcja:

Nie budujemy jednego wielkiego storage. Budujemy storage z wielu zwykłych serwerów.

Przykładowo:

Node 1
 ├── SSD
 ├── SSD
 └── SSD

Node 2
 ├── SSD
 ├── SSD
 └── SSD

Node 3
 ├── SSD
 ├── SSD
 └── SSD

Ceph może potraktować je jako jeden rozproszony system.

Architektura Ceph

Najważniejsze komponenty to:

Ceph Cluster
 |
 +-- MON
 |
 +-- MGR
 |
 +-- OSD
 |
 +-- MDS

Nie wszystkie są wymagane w każdej konfiguracji.

OSD – serce Ceph

OSD (Object Storage Daemon) odpowiada za przechowywanie danych.

Typowo jeden OSD jest związany z jednym urządzeniem storage:

Ceph Node
   |
   +-- OSD 1 → SSD
   +-- OSD 2 → SSD
   +-- OSD 3 → HDD

OSD zajmuje się m.in.:

• zapisem danych,
• odczytem danych,
• replikacją,
• recovery,
• rebalancingiem,
• komunikacją z innymi OSD.

MON – Monitor

MON (Monitor Daemon) przechowuje informacje o stanie klastra i jego mapach.

Można go traktować jako element odpowiedzialny za:

Cluster State
      |
      v
    MON

W produkcyjnym klastrze zazwyczaj stosuje się nieparzystą liczbę monitorów, np.:

MON1
MON2
MON3

dzięki czemu możliwe jest osiągnięcie quorum.

MGR – Manager

Ceph Manager odpowiada za funkcje zarządzające i monitoring.

MGR
 |
 +-- Metrics
 +-- Dashboard
 +-- Management
 +-- Modules

Często spotkasz:

ceph-mgr

obok:

ceph-mon
ceph-osd

MDS – Metadata Server

MDS (Metadata Server) jest potrzebny przede wszystkim przy CephFS.

CephFS
  |
  v
 MDS
  |
  v
Metadata

Nie jest wymagany dla podstawowego RBD czy RGW.

Trzy główne rodzaje storage Ceph

Ceph oferuje trzy główne interfejsy:

                 Ceph
                   |
       +-----------+-----------+
       |           |           |
      RBD        CephFS       RGW
       |           |           |
    Block        File        Object

RBD

RADOS Block Device

Daje urządzenie blokowe.

Idealne np. dla:

VM
Database
Kubernetes

CephFS

Rozproszony filesystem.

Client
  |
CephFS
  |
Ceph Cluster

RGW

RADOS Gateway

Udostępnia storage obiektowy kompatybilny m.in. z API S3.

Application
     |
    S3
     |
    RGW
     |
   Ceph

RADOS

W centrum całego Cepha znajduje się RADOS.

To właśnie warstwa rozproszonego object storage.

             Ceph
               |
             RADOS
               |
      +--------+--------+
      |        |        |
     OSD      OSD      OSD

RBD, CephFS i RGW korzystają z RADOS.

Jak Ceph wie, gdzie przechowywać dane?

To jeden z najważniejszych elementów architektury Ceph:

CRUSH.

CRUSH oznacza:

Controlled Replication Under Scalable Hashing

Zamiast klasycznej centralnej tablicy:

Data → Controller → Disk

Ceph wykorzystuje algorytm CRUSH do określenia, gdzie powinny znaleźć się dane.

Object
  |
  v
CRUSH
  |
  +---- OSD 12
  +---- OSD 27
  +---- OSD 41

Dlaczego CRUSH jest ważny?

Nie potrzebujemy centralnego storage controllera, który musi wiedzieć o każdym obiekcie.

Dzięki temu Ceph może skalować się wraz z liczbą OSD.

10 OSD
   ↓
100 OSD
   ↓
1000 OSD

Architektura pozostaje rozproszona.

Pools

Dane w Ceph są organizowane w poolach.

Przykład:

Ceph Cluster
 |
 +-- pool-vm
 |
 +-- pool-backup
 |
 +-- pool-kubernetes
 |
 +-- pool-s3

Każdy pool może mieć własne parametry.

Replication

Najprostszy model ochrony danych to replikacja.

Przykładowo:

Replication = 3

oznacza, że dane są przechowywane w trzech kopiach.

Object A
 |
 +-- OSD 1
 +-- OSD 8
 +-- OSD 14

Awaria jednego OSD nie powoduje utraty danych.

Failure Domain

Sama replikacja nie wystarczy.

Jeżeli wszystkie kopie znajdą się na jednym serwerze:

Node 1
 ├── Replica 1
 ├── Replica 2
 └── Replica 3

awaria Node 1 niszczy wszystkie kopie.

Dlatego Ceph może rozkładać dane według failure domain.

Na przykład:

Replica 1 → Node 1
Replica 2 → Node 2
Replica 3 → Node 3

Wtedy:

Node 2 DOWN
      |
      v
Replica 1 + Replica 3
      |
      v
Data nadal dostępne

Erasure Coding

Ceph może również korzystać z Erasure Coding zamiast klasycznej replikacji.

Przykładowo:

Data
 |
 +-- Chunk 1
 +-- Chunk 2
 +-- Chunk 3
 +-- Parity 1
 +-- Parity 2

Pozwala to uzyskać odporność na awarie przy mniejszym narzucie pojemności niż trzy pełne kopie.

Replication vs Erasure Coding

Ceph i Proxmox

To jedno z najczęstszych zastosowań Cepha.

Możemy zbudować:

             Proxmox Cluster
                    |
       +------------+------------+
       |            |            |
    Node 1        Node 2       Node 3
       |            |            |
     Ceph OSD     Ceph OSD     Ceph OSD
       \            |            /
        +-----------+-----------+
                    |
                  Ceph
                    |
                   RBD
                    |
                   VM

VM może korzystać z dysku znajdującego się w Ceph RBD.

Dlaczego Ceph jest świetny dla Proxmox?

Bo eliminuje problem:

„Na którym hoście znajduje się dysk tej VM?”

Przy lokalnym storage:

VM1
 |
Disk
 |
Node 1

Migracja VM wymaga przeniesienia storage.

Przy Ceph:

VM1
 |
RBD
 |
Ceph Cluster

VM może przejść:

Node 1
   ↓
Node 2

a jej dysk pozostaje w rozproszonym Ceph.

Ceph + Live Migration

To bardzo mocne połączenie.

           Ceph
        /    |    \
      Node1 Node2 Node3
        |     |     |
       VM    VM    VM
        |
   Live Migration
        |
        v
      Node 2

Compute i storage są od siebie oddzielone.

To daje dużą elastyczność klastra.

Ceph i Kubernetes

Ceph jest również bardzo popularny w Kubernetes.

Najczęściej spotkasz Rook, który pomaga zarządzać Ceph wewnątrz klastra Kubernetes.

Schemat:

Kubernetes
    |
   Rook
    |
   Ceph
    |
 +--+--+--+
 |  |  |  |
OSD OSD OSD

Ceph może dostarczać:

Block Storage
Filesystem
Object Storage

dla workloadów Kubernetes.

Ceph CSI

W Kubernetes Ceph może być wykorzystywany poprzez CSI (Container Storage Interface).

Schemat:

Pod
 |
PVC
 |
CSI
 |
Ceph RBD
 |
Ceph Cluster

Przykładowo:

Pod
 |
PersistentVolumeClaim
 |
PersistentVolume
 |
RBD
 |
Ceph

To bardzo dobrze pasuje do wcześniejszego tematu Persistent Volumes.

Ceph i sieć

Ceph jest bardzo zależny od sieci.

W małym klastrze można używać jednej sieci, ale większe instalacje często rozdzielają ruch.

Historycznie spotyka się:

Public Network

oraz:

Cluster Network

Schemat:

              Ceph
                |
        +-------+-------+
        |               |
 Public Network    Cluster Network
        |               |
      Clients        OSD replication

Dlaczego sieć jest tak ważna?

Ponieważ OSD stale komunikują się ze sobą.

Przy awarii:

OSD DOWN

Ceph musi:

wykryć awarię
     ↓
przeliczyć stan
     ↓
odtworzyć dane
     ↓
zreplikować dane

To oznacza ogromną ilość ruchu.

Dlatego Ceph bardzo dobrze wykorzystuje:

10 GbE
25 GbE
40 GbE
100 GbE

w zależności od skali.

Recovery

Załóżmy:

3 replicas

OSD1
OSD2
OSD3

OSD2 ulega awarii:

OSD1 ✓
OSD2 ✗
OSD3 ✓

Ceph rozpoczyna recovery.

Jeżeli dostępny jest OSD4:

OSD1 ✓
OSD3 ✓
OSD4 ← new replica

Ceph odbudowuje odpowiednią redundancję.

Rebalancing

Dodajemy nowy OSD:

Before:

OSD1
OSD2
OSD3

Dodajemy:

OSD4

Ceph może przenieść część danych:

OSD1 ──┐
OSD2 ──┼──> OSD4
OSD3 ──┘

Dzięki temu dane są ponownie równomiernie rozłożone.

Skalowanie

To jedna z największych zalet Cepha.

Możemy zacząć od:

3 Nodes
9 OSD

a następnie:

10 Nodes
100 OSD

i dalej zwiększać klaster.

Dodanie pojemności może wyglądać tak:

New Node
   |
New OSDs
   |
Ceph
   |
Automatic Rebalancing

Ceph nie jest RAID-em

To bardzo ważne.

RAID:

Server
 |
RAID Controller
 |
Disks

Ceph:

Node 1 ──┐
Node 2 ──┼── Ceph Cluster
Node 3 ──┘

RAID chroni przede wszystkim przed awarią dysków w określonym systemie.

Ceph może chronić przed awarią:

Disk
Node
Rack

w zależności od konfiguracji failure domain.

Ceph vs NAS

NAS:

Client
  |
  v
NAS
  |
Storage

Ceph:

Client
  |
  +---------+---------+
  |         |         |
Node 1    Node 2    Node 3

Ceph jest bardziej rozproszony.

Ale również znacznie bardziej złożony.

Ceph vs SAN

Tradycyjne SAN:

Servers
   |
   v
SAN
   |
Storage Array

Ceph:

Servers
   |
   v
Ceph Cluster
   |
Distributed Storage

Ceph pozwala budować storage z commodity hardware zamiast koniecznie kupować dedykowany storage array.

Ceph i SSD/NVMe

Ceph bardzo dobrze pasuje do szybkich dysków.

Przykład:

Node 1
 ├── NVMe
 ├── NVMe
 └── NVMe

Node 2
 ├── NVMe
 ├── NVMe
 └── NVMe

Node 3
 ├── NVMe
 ├── NVMe
 └── NVMe

Ale szybkie OSD zwiększają wymagania względem sieci i CPU.

Jeżeli storage potrafi:

10 GB/s

a sieć ma:

1 GbE

sieć stanie się oczywistym ograniczeniem.

Ceph BlueStore

Nowoczesne Ceph OSD korzystają z BlueStore jako backendu storage.

Schematycznie:

OSD
 |
BlueStore
 |
Block Device
 |
SSD/NVMe

BlueStore został zaprojektowany specjalnie dla Cepha i eliminuje konieczność korzystania z tradycyjnego filesystemu jako głównej warstwy danych OSD.

WAL i DB

W konfiguracjach BlueStore możesz spotkać:

block
block.db
block.wal

Przykładowo:

NVMe
 |
 +-- DB/WAL
 |
HDD
 |
 +-- Data

Szybsze urządzenie może zostać wykorzystane do przechowywania DB/WAL, podczas gdy większe HDD przechowują właściwe dane.

Ceph i failure domains

Możemy zdefiniować strukturę:

Datacenter
 |
 +-- Rack 1
 |    |
 |   Node 1
 |   Node 2
 |
 +-- Rack 2
      |
     Node 3
     Node 4

Ceph może odpowiednio rozłożyć repliki.

Na przykład:

Replica 1 → Rack 1
Replica 2 → Rack 2
Replica 3 → Rack 3

Awaria całego racka nie musi oznaczać utraty danych.

Ceph i quorum

MON-y korzystają z mechanizmu quorum.

Przykład:

MON1 ✓
MON2 ✓
MON3 ✗

Pozostałe dwa mogą zachować quorum.

Dlatego często stosuje się:

3 MON

a w większych klastrach:

5 MON

Ceph Dashboard

Ceph posiada również dashboard umożliwiający obserwowanie klastra.

Można monitorować m.in.:

Cluster Health
OSD
Pools
PG
Capacity
Performance
Recovery

Przy większym klastrze monitoring jest absolutnie kluczowy.

PG – Placement Groups

To jedna z ważniejszych koncepcji Cepha.

Schemat:

Pool
 |
 +-- PG1
 +-- PG2
 +-- PG3
 +-- PG4
       |
       +-- OSD
       +-- OSD
       +-- OSD

Placement Groups pomagają Cephowi zarządzać rozmieszczeniem obiektów pomiędzy OSD.

Nie myśl o PG jak o zwykłych katalogach czy partycjach.

To element logicznego mapowania danych na OSD.

Ceph Health

Stan klastra można sprawdzić:

ceph health

lub:

ceph -s

Przykładowo interesuje nas:

HEALTH_OK

ale również:

HEALTH_WARN
HEALTH_ERR

W środowisku produkcyjnym ignorowanie HEALTH_WARN może być bardzo złym pomysłem.

Ceph – pełna architektura

                         CLIENTS
                            |
             +--------------+--------------+
             |              |              |
            RBD           CephFS          RGW
             |              |              |
             +--------------+--------------+
                            |
                           RADOS
                            |
                       CRUSH / PG
                            |
          +-----------------+-----------------+
          |                 |                 |
       Node 1            Node 2            Node 3
          |                 |                 |
      +---+---+         +---+---+         +---+---+
      |   |   |         |   |   |         |   |   |
     OSD OSD OSD       OSD OSD OSD       OSD OSD OSD
          |                 |                 |
          +-----------------+-----------------+
                            |
                     Distributed Storage

Ceph + Proxmox – bardzo mocna kombinacja

Można zbudować:

                    Proxmox Cluster
                          |
          +---------------+---------------+
          |               |               |
        Node 1          Node 2          Node 3
          |               |               |
        KVM             KVM             KVM
          |               |               |
         VM              VM              VM
          \               |               /
           +--------------+--------------+
                          |
                         RBD
                          |
                         Ceph
                          |
             +------------+------------+
             |            |            |
            OSD          OSD          OSD

W takim środowisku otrzymujemy:

Compute + Distributed Storage + Live Migration + HA

w jednym klastrze.

Ceph – największa zaleta i największa wada

Zaleta

Skalowalność
+
Redundancja
+
Brak centralnego storage
+
RBD
+
CephFS
+
S3
+
Integracja z Kubernetes/Proxmox

Wada

Złożoność.

Ceph wymaga zrozumienia:

MON
MGR
OSD
RADOS
CRUSH
Pools
PG
Replication
Erasure Coding
Recovery
Rebalancing
Networking

To nie jest „postaw trzy serwery i zapomnij”.

Najważniejsze do zapamiętania

Ceph
 |
 +-- RADOS
 |
 +-- MON → cluster state / quorum
 |
 +-- MGR → management
 |
 +-- OSD → dane
 |
 +-- CRUSH → rozmieszczenie danych
 |
 +-- RBD → block storage
 |
 +-- CephFS → filesystem
 |
 +-- RGW → object/S3

A w kontekście całej serii tematów, które właśnie przerabiamy, Ceph jest naturalnym kolejnym elementem po Live Migration:

KVM
 ↓
VirtIO
 ↓
Live Migration
 ↓
Ceph
 ↓
Proxmox Cluster
 ↓
HA
 ↓
Kubernetes / Cloud Infrastructure

To właśnie tutaj zaczyna się przejście od pojedynczej wirtualizacji do prawdziwej rozproszonej infrastruktury.

Polecane wpisy

Citrix Hypervisor (XenServer): Charakterystyka i Zastosowania

Citrix Hypervisor (XenServer): Charakterystyka i Zastosowania Citrix Hypervisor, wcześniej znany jako XenServer, to zaawansowana platforma wirtualizacyjna oparta na technologii Xen, Czytaj dalej

Jak sprawdzić konfigurację kopii zapasowych maszyn wirtualnych?

💾 Jak sprawdzić konfigurację kopii zapasowych maszyn wirtualnych? Wirtualizacja zmieniła sposób, w jaki firmy zarządzają swoimi zasobami IT. Jednak nawet Czytaj dalej