Vai al contenutoNaviga tra le pagine: pagina precedente [tasto di scelta p]/pagina successiva [tasto di scelta n]
documentation.suse.com / Documentazione di SUSE Enterprise Storage 7 / Guida alla distribuzione / Presentazione di SUSE Enterprise Storage (SES) / SES e Ceph
Si applica a SUSE Enterprise Storage 7

1 SES e Ceph

SUSE Enterprise Storage è un sistema di storage distribuito progettato per scalabilità, affidabilità e prestazioni basato sulla tecnologia Ceph. È possibile eseguire un cluster Ceph su server generici in una rete comune come Ethernet. Il cluster può scalare inoltre fino a migliaia di server (più avanti denominati nodi) e nel campo dei petabyte. Rispetto ai sistemi convenzionali che dispongono di tabelle di allocazione per memorizzare e recuperare i dati, Ceph utilizza un algoritmo deterministico per allocare lo storage per i dati e non dispone di alcuna struttura informativa centralizzata. Ceph suppone che nei cluster di storage l'aggiunta o la rimozione dell'hardware sia la normalità, non l'eccezione. Il cluster Ceph automatizza i task di gestione come distribuzione e ridistribuzione dei dati, replica dei dati, rilevamento e ripristino degli errori. Ceph sfrutta capacità di autoregolazione e autogestione, determinando la riduzione delle spese amministrative e sforamenti di bilancio.

Questo capitolo contiene una panoramica di alto livello di SUSE Enterprise Storage 7 e una breve descrizione dei componenti più importanti.

1.1 Funzioni di Ceph

L'ambiente Ceph presenta le seguenti caratteristiche:

Scalabilità

Ceph è in grado di scalare a migliaia di nodi e gestire lo storage nel campo dei petabyte.

Hardware

Per eseguire il cluster Ceph, non sono richiesti hardware speciali. Per i dettagli, vedere Capitolo 2, Requisiti hardware e raccomandazioni

Autogestione

Il cluster Ceph è in grado di autogestirsi. Quando si aggiungono o rimuovono nodi o in caso di guasto, il cluster ridistribuisce automaticamente i dati. È inoltre in grado di riconoscere i dischi sovraccarichi.

Nessun Single point of failure

Nessun nodo in un cluster memorizza da solo dati importanti. È possibile configurare il numero di ridondanze.

Software open source

Ceph è una soluzione software open source e indipendente da hardware o fornitori specifici.

1.2 Componenti di base di Ceph

Per utilizzare pienamente la potenza di Ceph, è necessario comprendere alcuni dei componenti e concetti di base. Questa sezione presenta alcune parti di Ceph a cui si fa spesso riferimento in altri capitoli.

1.2.1 RADOS

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:

Object Gateway

Object Gateway è un gateway HTTP REST per lo store di oggetti RADOS che consente l'accesso diretto agli oggetti memorizzati nel cluster Ceph.

RADOS Block Device

È possibile accedere ai RADOS Block Device (RBD) seguendo la stessa procedura degli altri dispositivi di blocco e utilizzarli ad esempio insieme con libvirt per scopi di virtualizzazione.

CephFS

Il file system di Ceph è di tipo POSIX-compatibile.

librados

librados è una libreria utilizzabile con molti linguaggi di programmazione per creare un'applicazione in grado di interagire direttamente con il cluster di storage.

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

Interfacce con l'archivio dati Ceph
Figura 1.1: Interfacce con l'archivio dati Ceph

1.2.2 CRUSH

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.

1.2.3 Daemon e nodi Ceph

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 collocati con i Ceph Monitor. Per ogni cluster sono necessari almeno i daemon Ceph Monitor, Ceph Manager e Ceph OSD:

Nodo admin

Il nodo admin è un nodo del cluster Ceph da cui si eseguono i comandi per la gestione del cluster. Il nodo admin è un punto centrale del cluster Ceph perché gestisce i nodi residui del cluster tramite interrogazione e istruendo i relativi servizi Salt Minion.

Ceph Monitor

I nodi Ceph Monitor (spesso abbreviato con MON) mantengono le informazioni sullo stato del cluster, una mappa di tutti i nodi e regole di distribuzione dati (vedere Sezione 1.2.2, «CRUSH»).

Se si verificano errori o conflitti, i nodi Ceph Monitor nel cluster decidono a maggioranza quali dati sono corretti. Per formare una maggioranza qualificata, si consiglia un numero dispari di nodi Ceph Monitor e almeno tre.

Se si utilizzano più siti, i nodi Ceph Monitor devono essere distribuiti su un numero dispari di siti. Il numero di nodi Ceph Monitor per sito deve essere tale che oltre il 50% dei nodi Ceph Monitor resti funzionale in caso di errore di un sito.

Ceph Manager

Ceph Manager raccoglie le informazioni di stato dall'intero cluster. Il daemon Ceph Manager viene eseguito insieme con i daemon Ceph Monitor, fornisce ulteriore monitoraggio e si interfaccia con i sistemi di gestione e monitoraggio esterni. Include anche altri servizi. Ad esempio, l'interfaccia utente Web del Ceph Dashboard viene eseguita sullo stesso nodo del Ceph Manager.

Per Ceph Manager non è necessaria una configurazione aggiuntiva; è sufficiente verificare che sia in esecuzione.

Ceph OSD

Ceph OSD è un daemon che gestisce gli Object Storage Device che sono unità di storage logiche o fisiche (dischi rigidi o partizioni). Gli Object Storage Device possono essere dischi fisici/partizioni o volumi logici. Il daemon si occupa inoltre della replica dei dati e del ribilanciamento in caso di nodi aggiunti o rimossi.

I daemon Ceph OSD comunicano con i daemon monitor e forniscono loro lo stato degli altri daemon OSD.

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

Metadata Server (MDS)

I metadati di CephFS vengono archiviati sul relativo pool RADOS (vedere la Sezione 1.3.1, «Pool»). I Metadata Server agiscono come strato di memorizzazione nella cache smart per i metadati e serializzano l'accesso quando necessario. In questo modo, è possibile consentire l'accesso simultaneo da diversi client senza sincronizzazione esplicita.

Object Gateway

Object Gateway è un gateway HTTP REST per l'archivio dati RADOS. È compatibile con OpenStack Swift e Amazon S3 e dispone di propria gestione utente.

NFS Ganesha

NFS Ganesha fornisce un accesso NFS all'Object Gateway o a CephFS. Viene eseguito nell'utente invece che nello spazio kernel e interagisce direttamente con l'Object Gateway o CephFS.

iSCSI Gateway

iSCSI è un protocollo di rete di storage che consente ai client di inviare comandi SCSI ai dispositivi di storage SCSI (destinazioni) su server remoti.

Gateway Samba

Il gateway Samba fornisce accesso Samba ai dati memorizzati su CephFS.

1.3 Struttura di memorizzazione di Ceph

1.3.1 Pool

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.

1.3.2 Gruppi di posizionamento

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.

1.3.3 Esempio

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
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.

Esempio di Ceph su piccola scala
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.

1.4 BlueStore

BlueStore è un nuovo back-end di storage di default per Ceph di SES 5. Offre migliori prestazioni di FileStore, check-sum dei dati completo e compressione integrata.

BlueStore gestisce uno, due o tre dispositivi di storage. Nel caso più semplice, BlueStore consuma un singolo dispositivo di storage primario. Il dispositivo di storage è di solito partizionato in due parti:

  1. Una piccola partizione denominata BlueFS che implementa funzionalità di tipo file system richieste da RocksDB.

  2. Il resto del dispositivo è in genere una grande partizione che occupa tutto lo spazio residuo del dispositivo. È gestito direttamente da BlueStore e contiene tutti i dati effettivi. Tale dispositivo primario è in genere identificato da un collegamento simbolico di blocco nella directory dei dati.

È inoltre possibile distribuire BlueStore su due dispositivi aggiuntivi:

Un dispositivo WAL può essere utilizzato per il giornale di registrazione interno di BlueStore o il log di scrittura. È identificato dal collegamento simbolico block.wal nella directory dei dati e serve solo per utilizzare un dispositivo WAL separato se il dispositivo è più veloce del dispositivo primario o del dispositivo DB, ad esempio quando:

  • il dispositivo WAL è un NVMe e il dispositivo DB è una SSD e il dispositivo dati è un'unità SSD o HDD.

  • Entrambi i dispositivi WAL e DB sono SSD separate e il dispositivo dati è un'unità SSD o HDD.

È possibile utilizzare un dispositivo DB per memorizzare i metadati interni di BlueStore. BlueStore (o piuttosto il RocksDB integrato) trasferisce tutti i metadati possibili sul dispositivo DB per migliorare le prestazioni. Di nuovo, è utile solo per il provisioning di un dispositivo DB condiviso se è più veloce del dispositivo primario.

Suggerimento
Suggerimento: pianificazione della dimensione del DB

Pianificarla attentamente per assicurarsi che il dispositivo DB sia delle dimensioni sufficienti. Se il dispositivo DB è pieno, i metadati si riverseranno sul dispositivo primario che degraderà notevolmente le prestazioni dell'OSD.

È possibile verificare se una partizione WAL/DB si sta riempiendo e trasferendo i dati con il comando ceph daemon osd.ID perf dump. Il valore slow_used_bytes mostra la quantità di dati in uscita:

cephuser@adm > ceph daemon osd.ID perf dump | jq '.bluefs'
"db_total_bytes": 1073741824,
"db_used_bytes": 33554432,
"wal_total_bytes": 0,
"wal_used_bytes": 0,
"slow_total_bytes": 554432,
"slow_used_bytes": 554432,

1.5 Informazioni aggiuntive

  • Ceph è un progetto di community che dispone di una propria documentazione completa online. Per argomenti non trovati nel presente manuale, consultare https://docs.ceph.com/en/octopus/.

  • La pubblicazione originale CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data di S.A. Weil, S.A. Brandt, E.L. Miller, C. Maltzahn fornisce spunti utili nelle opere interne di Ceph. Se ne consiglia la lettura soprattutto per la distribuzione di cluster in grande scala. La pubblicazione è disponibile al seguente collegamento http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf.

  • SUSE Enterprise Storage può essere utilizzato con le distribuzioni OpenStack non SUSE. I client Ceph devono trovarsi a un livello compatibile con SUSE Enterprise Storage.

    Nota
    Nota

    SUSE supporta il componente server della distribuzione Ceph, mentre il client è supportato dal fornitore della distribuzione OpenStack.