Ceph został zaprojektowany tak, aby był skalowalny i nie miał pojedynczego punktu awarii. Monitor (MON), Object Storage Daemon (OSD), and Metadata Servers (MDS) są trzema kluczowymi demonami (procesami Linux) w klastrze Ceph. Zazwyczaj klastr Ceph będzie miał trzy lub więcej węzłów monitorujących dla redundancji. Monitory utrzymują główną kopię map klastra, która umożliwia klientom Ceph komunikację bezpośrednio z OSD i MDS. Te mapy są krytycznym stanem klastra wymaganym do koordynacji demonów Ceph między sobą. Monitory są również odpowiedzialne za zarządzanie uwierzytelnianiem między demonami a klientami. Nieparzysta liczba monitorów utrzymuje mapę klastra za pomocą kworum. Ten algorytm unika pojedynczego punktu awarii na monitorze i gwarantuje, że ich konsensus jest ważny. OSD to demon przechowywania obiektów dla Ceph. Przechowuje dane, obsługuje replikację danych, odzyskiwanie, równoważenie obciążenia i dostarcza pewne informacje monitorujące do monitorów Ceph, sprawdzając inne demony OSD w celu sprawdzenia stanu. Każdy serwer przechowywania uruchamia jeden lub wiele demonów OSD, jeden na urządzenie przechowywania. Zazwyczaj wymagane jest co najmniej 3 OSD-y dla zapewnienia redundancji i wysokiej dostępności. Demon MDS zarządza metadanymi dotyczącymi plików przechowywanych w systemie plików Ceph oraz koordynuje dostęp do współdzielonego klastra pamięci masowej Ceph. Możesz mieć wiele aktywnych MDS dla redundancji i równoważenia obciążenia każdego MDS. Będziesz potrzebować jednego lub więcej serwerów metadanych (MDS) tylko wtedy, gdy chcesz używać współdzielonego systemu plików.

Ceph to skalowalne przechowywanie

W tradycyjnym systemie przechowywania, klienci rozmawiają z scentralizowanym komponentem (np. host bus adaptor lub bramką), która jest jednym punktem wejścia do złożonego podsystemu. Centralizowany kontroler narzuca ograniczenia zarówno wydajności, jak i skalowalności, wprowadzając jednocześnie pojedynczy punkt awarii. Jeśli składnik centralny ulegnie awarii, cały system również ulegnie awarii. Klienci Ceph pobierają najnowszą mapę klastra od monitorów i używają algorytmu CRUSH do obliczenia, który OSD w klastrze. Ten algorytm umożliwia klientom bezpośrednią interakcję z Ceph OSD, bez konieczności korzystania z centralnego kontrolera. Algorytm CRUSH eliminuje pojedynczą ścieżkę, co powoduje ograniczenie skalowalności. Klastry OSD Ceph zapewniają klientom wspólny pulpit pamięci masowej. Kiedy potrzebujesz większej pojemności lub wydajności, możesz dodać nowy OSD, aby rozszerzyć pulę. Wydajność klastra Ceph jest liniowo proporcjonalna do liczby OSD. Następujący obraz przedstawia wzrost IOPS odczytu/zapisu wraz ze zwiększeniem liczby OSD.

Tradycyjne tablice dyskowe używają kontrolera RAID do ochrony danych przed awarią dysku. Pojemność dysku twardego wynosiła około 20MB, gdy technologia RAID została wynaleziona. Dzisiaj pojemność dysku wynosi aż 16TB. Czas odbudowy uszkodzonego dysku w grupie RAID może zająć tydzień. Podczas odbudowy kontrolera RAID uszkodzonego dysku istnieje szansa, że drugi dysk może ulec równoczesnej awarii. Jeśli odbudowa zajmuje więcej czasu, prawdopodobieństwo utraty danych jest większe.

Ceph odzyskuje dane utracone na uszkodzonym dysku za pomocą wszystkich innych zdrowych dysków w klastrze. Ceph odbuduje tylko naprawi dane przechowywane na uszkodzonym dysku. Jeśli istnieje więcej zdrowych dysków, czas odzyskiwania będzie krótszy.