Ceph è progettato per essere scalabile e non avere un singolo punto di fallimento. Monitor (MON), Object Storage Daemon (OSD) e Metadata Servers (MDS) sono tre demoni chiave (processi Linux) nel cluster Ceph. Di solito, un cluster Ceph avrà tre o più nodi monitor per garantire la ridondanza. I monitor mantengono una copia principale delle mappe del cluster, che consentono ai client di Ceph di comunicare direttamente con OSD e MDS. Queste mappe sono uno stato critico del cluster necessario per i demoni di Ceph per coordinarsi tra di loro. I monitor sono anche responsabili della gestione dell'autenticazione tra i demoni e i clienti. I numeri dispari di monitor mantengono la mappa del cluster utilizzando un quorum. Questo algoritmo evita il singolo punto di fallimento sul monitor e garantisce che il loro consenso sia valido. OSD è il demone di archiviazione degli oggetti per Ceph. Archivia i dati, gestisce la replica dei dati, il ripristino, il riequilibrio e fornisce alcune informazioni di monitoraggio ai monitor di Ceph controllando gli altri demoni OSD per il battito cardiaco. Ogni server di archiviazione esegue uno o più demoni OSD, uno per dispositivo di archiviazione. Di solito sono necessari almeno 3 OSD per garantire ridondanza e alta disponibilità. Il demone MDS gestisce i metadati relativi ai file archiviati sul Ceph File System e coordina anche l'accesso al Ceph Storage Cluster condiviso. È possibile avere più MDS attivi per garantire la ridondanza e bilanciare il carico di ciascun MDS. Avrai bisogno di uno o più Metadata Servers (MDS) solo quando desideri utilizzare il sistema di file condiviso.

Ceph è uno storage scalabile

In un sistema di archiviazione tradizionale, i clienti parlano con un componente centralizzato (ad esempio, un adattatore di bus host o un gateway), che è un unico punto di accesso a un sottosistema complesso. Il controller centralizzato impone un limite sia alle prestazioni che alla scalabilità, introducendo anche un singolo punto di guasto. Se il componente centralizzato va giù, tutto il sistema va giù anche. I client Ceph ottengono la mappa più recente del cluster dai monitor e utilizzano l'algoritmo CRUSH per calcolare quale OSD nel cluster. Questo algoritmo consente ai clienti di interagire direttamente con Ceph OSD senza passare attraverso un controller centralizzato. L'algoritmo CRUSH elimina il percorso singolo, che causa la limitazione della scalabilità. Il cluster OSD di Ceph fornisce ai clienti un pool di archiviazione condiviso. Quando hai bisogno di maggiore capacità o prestazioni, puoi aggiungere nuovi OSD per scalare il pool. Le prestazioni di un cluster Ceph sono proporzionali in modo lineare al numero di OSD. La seguente immagine mostra l'aumento delle IOPS di lettura/scrittura se aumentiamo il numero di OSD.

L'array di dischi tradizionale utilizza il controller RAID per proteggere i dati dal fallimento del disco. La capacità di un disco rigido era di circa 20MB quando la tecnologia RAID è stata inventata. Oggi la capacità del disco è grande come 16TB. Il tempo per ricostruire un disco fallito nel gruppo RAID potrebbe richiedere una settimana. Mentre il controller RAID sta ricostruendo il disco guasto, c'è la possibilità che un secondo disco possa guastarsi contemporaneamente. Se la ricostruzione richiede più tempo, la probabilità di perdere dati è più alta.

Ceph recupera i dati persi nel disco guasto da tutti gli altri dischi sani nel cluster. Ceph ricostruirà solo i dati memorizzati nel disco guasto. Se ci sono più dischi sani, il tempo di recupero sarà più breve.