Architektura Ceph: CRUSH, RADOS i samonaprawa bez centralnego kontrolera

W tradycyjnych macierzach dyskowych wydajność systemu jest ograniczona przez moc obliczeniową kontrolera (head unit). W pewnym momencie dodawanie kolejnych dysków nie przynosi zysku – procesor macierzy po prostu nie nadąża z obsługą metadanych i operacji I/O.

Co to jest Ceph? Ceph to rozproszony system pamięci masowej typu Software-Defined Storage (SDS), który eliminuje wąskie gardła tradycyjnych macierzy. Przenosi inteligencję z centralnego punktu bezpośrednio na węzły końcowe, wykorzystując architekturę RADOS (Reliable Autonomic Distributed Object Store). W SparkSome Venture wykorzystujemy to rozwiązanie, by budować systemy skalujące się liniowo, nie tracąc przy tym stabilności operacyjnej.

1. Algorytm CRUSH w architekturze Ceph: Eliminacja centralnego indeksowania

Największym hamulcem skalowalności v systemach storage są tabele metadanych (lookup tables). Jeśli system musi sprawdzić w centralnej bazie, gdzie leży każdy z miliardów obiektów, przy skali petabajtowej dochodzi do paraliżu wydajnościowego.

Ceph eliminuje ten proces za pomocą algorytmu CRUSH (Controlled Replication Under Scalable Hashing).

Jak działa CRUSH?

• Zamiast „szukać” adresu w tabeli, klient oblicza go w czasie rzeczywistym na podstawie mapy klastra.
• Operacje I/O odbywają się bezpośrednio między klientem a demonami OSD, bez udziału pośredników czy centralnych kontrolerów.
• CRUSH posiada pełną świadomość topologii fizycznej – wie, które serwery znajdują się w tej samej szafie (failure domain), co pozwala na inteligentne rozpraszanie replik w celu ochrony przed awariami całych sekcji serwerowni.

Dzięki temu klaster o pojemności 10 PB zarządza się niemal tak samo, jak klastrem 100 TB, ponieważ CRUSH i RADOS eliminują konieczność centralnego indeksowania zasobów.

2. Twierdzenie CAP: Dlaczego Ceph to system klasy CP?

W kontekście systemów rozproszonych Ceph jest klasyfikowany jako system CP (Consistency & Partition Tolerance). W przeciwieństwie do rozwiązań stawiających na dostępność kosztem spójności (AP), RADOS gwarantuje, że klient zawsze otrzyma najbardziej aktualną wersję danych lub błąd, jeśli spójność nie może zostać zachowana.

Jest to kluczowe w środowiskach bazodanowych i wirtualizacji, gdzie tzw. dirty reads mogłyby doprowadzić do krytycznego uszkodzenia struktur systemowych. Ten poziom inżynierskiego rygoru wsparcia IT jest fundamentem naszych wdrożeń. Więcej o specyfikacji technicznej można znaleźć w oficjalnej dokumentacji Ceph.

3. Unified Storage: Jeden backend, wiele protokołów

Siłą architektury Ceph jest jej uniwersalność. Warstwa RADOS stanowi fundament, na którym nadbudowane są trzy główne interfejsy usługowe:

• RBD (RADOS Block Device): Natywna pamięć blokowa dla wirtualizacji (Proxmox, OpenStack). Wspiera thin provisioning i snapshots.
• RGW (RADOS Gateway): Interfejs obiektowy kompatybilny z S3 i Swift, idealny dla aplikacji cloud-native.
• CephFS: Rozproszony system plików zgodny z POSIX, umożliwiający współdzielenie zasobów między wieloma klientami.

Jeśli chcesz zobaczyć, jak ten sam backend storage obsługuje jednocześnie środowiska kontenerowe, wirtualizację i chmurę prywatną, zajrzyj do naszego artykułu: Ceph w Kubernetes i OpenStack – jeden backend storage dla całej infrastruktury IT.

4. Architektura demonów Ceph: MON, OSD i MGR

Stabilność klastra opiera się na rygorystycznej separacji ról:

MON (Monitor) i algorytm Paxos

Monitory zarządzają mapami klastra (Cluster Map). Pracują w kworum (zazwyczaj 3 lub 5 instancji) i wykorzystują algorytm Paxos do zapewnienia spójności decyzji. Poprawna konfiguracja MON-ów to jedyna droga do uniknięcia awarii typu Split-Brain.

OSD (Object Storage Daemon) i BlueStore

Każdy dysk to proces OSD. W nowoczesnych wersjach standardem jest backend BlueStore, który zapisuje dane bezpośrednio na urządzeniu blokowym, omijając narzut tradycyjnych systemów plików. Pozwala to na drastyczne skrócenie ścieżki I/O i optymalizację pod kątem dysków NVMe.

5. Cykl życia danych: Peering i inteligentne Recovery

Gdy dochodzi do awarii węzła, Ceph uruchamia proces Peeringu. Grupy Placement Groups (PG) uzgadniają stan danych bez udziału administratora. Po ustaleniu braków system inicjuje Recovery – automatyczne kopiowanie danych na zdrowe nośniki w celu przywrócenia pełnej redundancji.

W SparkSome projektujemy te procesy tak, aby minimalizowały ryzyko niedostępności do poziomu praktycznie niezauważalnego dla biznesu. Jak wskazaliśmy w naszej analizie kosztów przestoju IT, każda sekunda automatyzacji to realna oszczędność.

6. Ekonomia odporności w Ceph: Replikacja vs Erasure Coding

Ceph pozwala na wybór polityki składowania na poziomie puli (pool), co pozwala na optymalizację TCO storage'u.

W SparkSome Venture optymalizujemy te parametry tak, by budować odporną infrastrukturę IT przy zachowaniu rynkowej efektywności kosztowej.

Szerzej porównujemy oba modele w analizie: Replikacja 3x czy Erasure Coding 4+2 w Ceph? Realny koszt wysokiej dostępności storage.

7. Separacja sieci i mechanizm Scrubbing

Profesjonalna architektura wymaga izolacji Public Network (ruch klientów) od Cluster Network (ruch replikacji i recovery). Zapobiega to paraliżowi usług podczas samonaprawy klastra. Dodatkowo mechanizm Scrubbing (Light i Deep) aktywnie walczy z cichą korupcją danych (bit rot), weryfikując sumy kontrolne obiektów w tle.

Tę wiedzę o fizyczności danych przekazujemy również dalej, będąc partnerem merytorycznym Politechniki Lubelskiej.

Podsumowanie i Roadmapa: Przyszłość w Crimson OSD

Ceph nie przestaje ewoluować. Najnowsze wydania, takie jak Ceph Squid 19.2.x, wprowadzają Crimson OSD – nową generację demona napisaną w frameworku Seastar, zoptymalizowaną pod ultra-szybkie dyski NVMe i sieci 100GbE+.

Dla inżyniera Ceph to rozproszony system operacyjny dla danych, który eliminuje wąskie gardła tradycyjnych macierzy poprzez architekturę bez centralnego ograniczenia. Jeśli planujesz środowisko cloud-native oparte o Kubernetes i Rook, Ceph jest jednym z najbardziej kompletnych backendów SDS zapewniających suwerenność i skalowalność bez vendor lock-in.

Zbuduj storage, który nie zna granic wydajności kontrolera. Umów audyt technologiczny ze SparkSome Venture