1 SES e Ceph #

Il componente base di Ceph è denominato RADOS (Reliable Autonomic Distributed Object Store), responsabile per la gestione dei dati memorizzati nel cluster. I dati in Ceph vengono in genere memorizzati come oggetti. Ciascun oggetto consiste di un identificativo e dai dati.

RADOS fornisce i seguenti metodi di accesso agli oggetti memorizzati che riguardano molti casi d'uso:

librados è utilizzata da Object Gateway e RBD mentre CephFS si interfaccia direttamente con RADOS Figura 1.1, «Interfacce con l'archivio dati Ceph».

Figura 1.1: Interfacce con l'archivio dati Ceph #

 

Il core del cluster Ceph è l'algoritmo CRUSH. CRUSH è l'acronimo di Controlled Replication Under Scalable Hashing. CRUSH è una funzione che gestisce l'allocazione dello storage e richiede comparabilmente pochi parametri. Ciò significa che è necessaria solo una piccola quantità di dati per calcolare la posizione di storage di un oggetto. I parametri sono una mappa corrente del cluster comprendente lo stato, alcune regole di posizionamento definite dall'amministratore e il nome dell'oggetto che deve essere memorizzato o recuperato. Con questi dati, tutti i nodi nel cluster Ceph sono in grado di calcolare dove si trova un oggetto e le sue repliche. Ciò rende la scrittura o la lettura dei dati molto efficace. CRUSH tenta di distribuire in modo uniforme i dati tra tutti i nodi nel cluster.

La mappa CRUSH contiene tutti i nodi di storage e le regole di posizionamento definite dall'amministratore per la memorizzazione degli oggetti nel cluster e definisce una struttura gerarchica che di solito corrisponde alla struttura fisica del cluster. Ad esempio, i dischi contenenti i dati sono negli host, gli host sono nei rack, i rack in righe e le righe nei data center. È possibile utilizzare questa struttura per definire i domini di guasto. Ceph quindi garantisce che le repliche vengano memorizzate su diverse diramazioni di uno specifico dominio di guasto.

Se il dominio di guasto è configurato su un rack, le repliche degli oggetti sono distribuite su diversi rack. Ciò può ridurre le perdite provocate da un errore di commutazione in un rack. Se un'unità di distribuzione alimentazione alimenta una riga di rack, il dominio di guasto può essere configurato su una riga. In caso di errore dell'unità di distribuzione di alimentazione, i dati replicati sono sempre disponibili su altre righe.

In Ceph, i nodi sono server che lavorano per il cluster e possono eseguire diversi tipi di daemon. Si consiglia di eseguire solo un tipo di daemon in ogni nodo, tranne per i daemon Ceph Manager che possono essere co-ubicati con i Ceph Monitor. Per ogni cluster sono necessari almeno i daemon Ceph Monitor, Ceph Manager e Ceph OSD:

Per utilizzare CephFS, Object Gateway, NFS Ganesha o iSCSI Gateway, sono richiesti nodi aggiuntivi:

Gli oggetti memorizzati in un cluster Ceph vengono posti nei pool. I pool rappresentano le partizioni logiche del cluster per l'esterno. Per ogni pool è possibile definire un set di regole, ad esempio quante repliche di ogni oggetto devono esistere. La configurazione standard dei pool è denominata pool replicato.

I pool in genere contengono oggetti, ma è possibile configurarli anche per funzionare come RAID 5. In questa configurazione, gli oggetti vengono memorizzati in chunk insieme con i chunk di codifica aggiuntivi. I chunk di codifica contengono i dati ridondanti. Il numero di dati e chunk di codifica può essere definito dall'amministratore. In questa configurazione, i pool sono denominati pool con codice di cancellazione o pool EC.

I gruppi di posizionamento (PG) sono utilizzati per la distribuzione dei dati in un pool. Quando si crea un pool, viene impostato un determinato numero di gruppi di posizionamento. I gruppi di posizionamento sono utilizzati internamente per raggruppare gli oggetti e sono un fattore importante per le prestazioni di un cluster Ceph. Il PG di un oggetto è determinato dal nome dell'oggetto.

Questa sezione fornisce un esempio semplificato della gestione dati di Ceph (vedere Figura 1.2, «Esempio di Ceph su piccola scala»). Questo esempio non rappresenta una configurazione consigliata per un cluster Ceph. La configurazione hardware consiste di tre nodi di storage Ceph OSD (Host 1, Host 2, Host 3). Ogni nodo ha tre dischi rigidi utilizzati come OSD (da osd.1 a osd.9). In questo esempio, vengono tralasciati i nodi Ceph Monitor.

Nota: differenza tra Ceph OSD e OSD

Mentre Ceph OSD o daemon Ceph OSD si riferisce a un daemon eseguito su un nodo, il termine OSD si riferisce al disco logico con cui interagisce il daemon.

Il cluster ha due pool, Pool A e Pool B. Mentre il Pool A replica gli oggetti solo due volte, la resilienza per Pool B è più importante e ha tre repliche per ogni oggetto.

Quando un'applicazione mette un oggetto in un pool, ad esempio tramite la API REST, un Gruppo di posizionamento (da PG1 a PG4) viene selezionato in base a pool e nome oggetto. L'algoritmo CRUSH calcola quindi su quali OSD viene memorizzato l'oggetto, in base al Gruppo di posizionamento contenente l'oggetto.

In questo esempio, il dominio di guasto è impostato sull'host. Ciò garantisce che le repliche degli oggetti siano memorizzate su diversi host. In base al livello di replica impostato per un pool, l'oggetto viene memorizzato su due o tre OSD utilizzati dal Gruppo di posizionamento.

Un'applicazione che scrive un oggetto interagisce solo con un Ceph OSD, il Ceph OSD primario. Il Ceph OSD primario si occupa della replica e conferma il completamento del processo di scrittura dopo che tutti gli altri OSD hanno memorizzato l'oggetto.

In caso di errore di osd.5, tutti gli oggetti in PG1 sono ancora disponibili su osd.1. Non appena il cluster riconosce l'errore di un OSD, un altro OSD lo sostituisce. In questo esempio osd.4 viene utilizzato come sostituzione per osd.5. Gli oggetti memorizzati su osd.1 vengono quindi replicati su osd.4 per ripristinare il livello di replica.

Figura 1.2: Esempio di Ceph su piccola scala #

 

Se si aggiunge al cluster un nuovo nodo con nuovi OSD, la mappa del cluster cambia. La funzione CRUSH restituisce quindi diverse ubicazioni per gli oggetti. Gli oggetti che ricevono nuove ubicazioni vengono riposizionati. Questo processo determina un uso bilanciato di tutti gli OSD.