Ceph Storage w firmie — kiedy ma sens, a kiedy lepiej go unikać?

Co to jest Ceph

Ceph to rozproszony system przechowywania danych, open source, zaprojektowany od podstaw z myślą o braku single point of failure. Dane są dzielone na obiekty i rozmieszczane między węzłami klastra według algorytmu CRUSH — bez centralnego kontrolera, bez jednego serwera metadanych, który mógłby paść i zablokować wszystko. Każdy węzeł równocześnie przechowuje dane i uczestniczy w zarządzaniu klastrem.

Ceph oferuje trzy interfejsy dostępu: blokowy (RBD — Raw Block Device, używany przez Proxmox i inne hypervisory), obiektowy (kompatybilny z S3, używany do backupu i archiwum) oraz plikowy (CephFS, dla współdzielonych systemów plików). W środowiskach wirtualizacyjnych najczęściej chodzi o RBD — dyski VM jako obrazy przechowywane w klastrze Ceph.

Architektura Ceph — co robi co

OSD (Object Storage Daemon) — jeden na każdy dysk fizyczny. To tutaj leżą dane. OSD obsługuje replikację między węzłami, recovery po awarii i rebalancing. Im więcej OSD, tym większa wydajność i pojemność klastra. MON (Monitor) — utrzymuje mapę klastra (cluster map), czyli informację o tym które OSD są aktywne, jak wygląda topologia replikacji i który węzeł jest zdrowy. Minimalna liczba MON to 3, żeby mieć kworum.

MGR (Manager) — zbiera statystyki, obsługuje dashboard, integracje (Prometheus, Grafana) i moduły zarządcze. MDS (Metadata Server) — potrzebny tylko przy CephFS, obsługuje przestrzeń nazw systemu plików. Przy samym RBD MDS nie jest wymagany. W produkcyjnym klastrze najczęściej masz 3 węzły pełniące role MON+MGR, a OSD rozłożone na wszystkich węzłach według liczby dysków.

Kiedy Ceph ma sens, a kiedy nie

Ceph ma sens gdy potrzebujesz skalowalnego storage bez komercyjnej macierzy, masz co najmniej 3 fizyczne węzły (to twarde minimum dla kworum i replikacji), każdy węzeł ma dedykowane dyski pod Ceph (nie dzielone z systemem), a sieć między węzłami to co najmniej 10GbE. Poniżej tych wymagań Ceph będzie wolny, niestabilny lub po prostu za drogi w utrzymaniu w stosunku do tego co oferuje.

Ceph nie ma sensu dla małych środowisk z jednym lub dwoma serwerami — tam lepszy będzie lokalny storage z RAID lub prosta macierz NAS. Nie ma sensu gdy zespół nie ma kompetencji do zarządzania rozproszonym systemem — Ceph ma stromą krzywą uczenia i jest wymagający w utrzymaniu. Nie ma też sensu jako tanie rozwiązanie — sprzęt, sieć i czas inżynierski sumują się szybko.

Integracja z Proxmox VE

Proxmox VE ma natywną integrację z Ceph — można zarządzać klastrem Ceph bezpośrednio z GUI Proxmoxa: tworzyć OSD, Pool, monitorować stan, a VM i kontenery używają woluminów RBD jako dysków. To sensowna kombinacja: Proxmox jako hypervisor, Ceph jako storage backend, wszystko zarządzane z jednego miejsca.

Live migration VM między węzłami działa bezproblemowo, bo dane są w Ceph, a nie na lokalnym dysku hosta. To podstawa dla klastra HA w Proxmoxie — węzeł może zostać wygaszony lub paść, a VM zostaje automatycznie uruchomiona na innym węźle, bo storage jest dostępny ze wszystkich hostów. Jeśli używasz lokalnego storage na węźle, live migration wymaga kopiowania obrazu dysku przez sieć, co jest wolne i zwiększa czas przestoju.

Typowe pułapki przy wdrożeniu Ceph

Zbyt wolna sieć to najczęstszy problem. 1GbE między węzłami w praktyce całkowicie blokuje wydajność klastra — replikacja 3-krotna przy każdym zapisie przez 1Gbps to katastrofa przy jakimkolwiek realnym obciążeniu. 10GbE to minimum, 25GbE jeśli masz dużo OSD lub dużo IOPS. Mieszanie dysków rotacyjnych z SSD bez konfiguracji tiering to kolejny błąd — HDD i SSD mają różną charakterystykę latencji i Ceph nie wyrówna tej różnicy automatycznie. Osobny pool dla SSD i HDD to podstawa.

Zbyt mała liczba OSD przy dużej pojemności jest problemem bo Ceph ma problem z rebalancingiem gdy OSD jest mało a danych dużo — każde OSD "widzi" za dużo danych i recovery po awarii trwa bardzo długo, podczas którego klaster jest w stanie degraded. Zasada: więcej mniejszych dysków jest lepsze niż kilka dużych. Oraz — nie pomijaj monitoringu. Ceph bez Grafana + Prometheus to jazda na oślep.

Kiedy lepszy jest prostszy NFS lub iSCSI

Jeśli masz jeden serwer storage i kilka serwerów które potrzebują do niego dostępu — NFS lub iSCSI jest prostsze, tańsze i łatwiejsze w zarządzaniu. Jeśli Twoje wymagania to "współdzielony storage dla 3-4 serwerów" bez potrzeby maskulowania pojemności i bez wymagań na megawysoki IOPS — prosta macierz z NFS wystarczy i będzie stabilniejsza w rękach mniej doświadczonego zespołu.

iSCSI sprawdza się też lepiej gdy potrzebujesz bardzo przewidywalnej latencji dla baz danych — Ceph ma zmienną latencję zależną od stanu klastra, rebalancingu, recovery. Dla krytycznych baz danych na PostgreSQL lub MySQL z wysokim IOPS, lokalne NVMe lub dedykowana macierz często dają lepszą charakterystykę niż Ceph na HDD/SATA-SSD.

Jak wygląda Ceph w środowisku produkcyjnym

U klientów InfraZone którzy uruchomili Ceph obserwujemy kilka powtarzających się wzorców: klaster działa stabilnie gdy jest dobrze zaprojektowany i ma właściwy sprzęt, ale wymaga regularnej uwagi — aktualizacje (szczególnie przy migracji między wersjami major), obserwacja pojemności OSD i alertów HEALTH_WARN, reagowanie na wolne OSD zanim staną się problematyczne.

Klasyczna konfiguracja produkcyjna którą widzimy: 3-5 węzłów fizycznych, każdy z 4-8 dyskami NVMe lub SSD jako OSD, dedykowana sieć klastrowa 25GbE, Proxmox VE jako hypervisor, monitoring przez Prometheus + Grafana. Przy takim setupie Ceph działa niezawodnie i osiąga IOPS rzędu dziesiątek tysięcy na pool. Wdrożenia na HDD z 1GbE kończą się zwykle przebudową po pierwszym poważniejszym incydencie.