🥇Suggerimenti & trucchi per lavorare con Ceph in progetti ad alto carico

Utilizzando Ceph come archiviazione di rete in progetti con carichi di lavoro diversi, possiamo affrontare varie sfide che a prima vista non sembrano semplici o triviali. Ad esempio:

migrazione dei dati da un vecchio Ceph a uno nuovo con utilizzo parziale dei precedenti server nel nuovo cluster;
risoluzione del problema di distribuzione dello spazio su disco in Ceph.

Affrontando tali compiti, ci troviamo nella necessità di estrarre correttamente gli OSD senza perdita di dati, il che è particolarmente importante quando si gestiscono grandi volumi di dati. Di questo parleremo nell'articolo.

Le modalità descritte di seguito sono valide per tutte le versioni di Ceph. Inoltre, si considererà che ce possano essere grandi quantità di dati in Ceph: per prevenire perdite di dati e altri problemi, alcune operazioni saranno 'frantumate' in molte altre.

Prefazione sugli OSD

Poiché due dei tre rimedi trattati sono dedicati agli OSD (Object Storage Daemon), prima di immergerci nella parte pratica – un breve accenno su cosa siano in generale in Ceph e perché siano così importanti.

In primo luogo, va detto che l'intero cluster Ceph è composto da molteplici OSD. Più ce ne sono, maggiore è la capacità di archiviazione libera nel Ceph. Da questo si può facilmente comprendere la funzione principale dell'OSD: salva i dati degli oggetti Ceph nei file system di tutti i nodi del cluster e fornisce accesso di rete a essi (per lettura, scrittura e altre richieste).

A questo livello vengono impostati i parametri di replica attraverso la copia degli oggetti tra diversi OSD. Qui si possono incontrare vari problemi, di cui si parlerà in seguito.

Caso n. 1. Estrazione sicura dell'OSD dal cluster Ceph senza perdita di dati

La necessità di estrarre l'OSD può derivare dalla disattivazione del server dal cluster - ad esempio, per sostituirlo con un altro server - cosa che è accaduta nel nostro caso, dando impulso alla scrittura di questo articolo. Pertanto, l'obiettivo finale delle operazioni è estrarre tutti gli OSD e i mon del server in questione, in modo che possa essere arrestato.

Per comodità e per evitare situazioni in cui potremmo commettere errori nella specificazione dell'OSD richiesto durante l'esecuzione dei comandi, impostiamo una variabile separata, il cui valore sarà il numero dell'OSD da rimuovere. La chiameremo ${ID} — da qui in avanti, una tale variabile sostituisce il numero OSD con cui stiamo lavorando.

Controlliamo lo stato prima dell'inizio dei lavori:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Per avviare la rimozione dell'OSD, sarà necessario ridurre gradualmente il suo peso a zero. In questo modo riduciamo la quantità di dati nell'OSD bilanciando negli altri OSD. Per fare ciò, eseguiamo i seguenti comandi:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

… e così via fino a zero.

La bilanciatura graduale è necessaria, per non perdere dati. Questo è particolarmente importante se nell'OSD sono presenti grandi quantità di dati. Per assicurarsi che, dopo aver eseguito i comandi, il suo peso tutto sia andato a buon fine, è possibile eseguire ceph -s oppure, in una finestra del terminale separata, avviare ceph -w per osservare le modifiche in tempo reale.

Quando l'OSD è "svuotata", possiamo procedere con l'operazione standard di rimozione. Per fare ciò, portiamo l'OSD in stato down:

ceph osd down osd.${ID}

"Estraiamo" l'OSD dal cluster:

ceph osd out osd.${ID}

Fermiamo il servizio OSD e smontiamo la relativa partizione nel filesystem:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Eliminiamo l'OSD da mappa CRUSH:

ceph osd crush remove osd.${ID}

Eliminiamo l'utente OSD:

ceph auth del osd.${ID}

E, infine, eliminiamo l'OSD stesso:

ceph osd rm osd.${ID}

Nota: se stai usando una versione di Ceph Luminous o superiore, le azioni descritte sopra per eliminare l'OSD possono essere ridotte a due comandi:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Se dopo aver eseguito le azioni sopra esegui il comando ceph osd tree, dovrebbe essere visibile che sul server dove sono state effettuate le operazioni non ci sono più OSD per i quali sono state eseguite le operazioni precedenti:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Osserviamo nel frattempo che lo stato del cluster Ceph passerà a HEALTH_WARN, e vedremo anche una diminuzione del numero di OSD e dello spazio disponibile su disco.

Di seguito verranno descritti i passi necessari se desideri spegnere completamente il server e, di conseguenza, rimuoverlo da Ceph. In tal caso, è importante ricordare che prima di scollegare il server devi rimuovere tutti gli OSD su questo server.

Se non ci sono più OSD su questo server, dopo averli rimossi bisogna escludere il server dalla mappa OSD. hv-2, eseguendo il seguente comando:

ceph osd crush rm hv-2

Rimuoviamo mon dal server hv-2, avviando il comando qui sotto su un altro server (ossia, in questo caso — su hv-1):

ceph-deploy mon destroy hv-2

Dopo questo, puoi fermare il server e passare alle azioni successive (la sua reinstallazione, ecc.).

Caso n°2. Distribuzione dello spazio disco in un cluster Ceph già creato.

Inizierò la seconda storia con un'introduzione sui PG (Placement Groups). Il ruolo principale dei PG in Ceph consiste principalmente nell'aggregare oggetti Ceph e nella successiva replica negli OSD. La formula per calcolare il numero necessario di PG si trova nella sezione corrispondente della documentazione Ceph. Qui viene discusso anche questo argomento con esempi concreti.

Così, uno dei problemi più comuni durante l'uso di Ceph è il numero sbilanciato di OSD e PG tra i pool in Ceph.

In primo luogo, può verificarsi una situazione in cui viene specificato un numero eccessivo di PG in un pool di dimensioni ridotte, il che costituisce di fatto un uso inefficiente dello spazio di archiviazione nel cluster. In secondo luogo, si presenta un problema più serio: l’overflow dei dati in uno degli OSD. Questo porta inizialmente il cluster a uno stato HEALTH_WARN, e poi a HEALTH_ERR. La causa è che Ceph, nel calcolare la capacità disponibile (che si può conoscere da MAX AVAIL nell'output del comando ceph df per ogni pool singolarmente) fa affidamento sulla quantità di dati disponibili negli OSD. Se almeno in uno degli OSD non c'è spazio sufficiente, non sarà possibile scrivere più dati finché i dati non saranno distribuiti correttamente tra tutti gli OSD.

È importante specificare che questi problemi sono maggiormente risolvibili nella fase di configurazione del cluster Ceph. Uno degli strumenti da utilizzare è Ceph PGCalc. Esso consente di calcolare in modo visivo il numero necessario di PG. Tuttavia, può essere utilizzato anche in situazioni in cui il cluster Ceph ha già è configurato in modo errato. Qui è importante specificare che, nel contesto dei lavori di correzione, sarà probabile che tu debba ridurre il numero di PG, e questa possibilità non è disponibile nelle vecchie versioni di Ceph (è stata introdotta solo a partire dalla versione Nautilus).

Immagina la seguente situazione: il cluster ha uno stato HEALTH_WARN a causa del fatto che in uno degli OSD sta per esaurirsi lo spazio. Questo sarà indicato dall'errore HEALTH_WARN: 1 near full osd. Di seguito è riportato l'algoritmo per uscire da questa situazione.

In primo luogo, è necessario distribuire i dati esistenti tra gli altri OSD. Un'operazione simile l'abbiamo già eseguita nel primo caso, quando abbiamo "svuotato" un nodo — con l'unica differenza che ora sarà necessario ridurre leggermente il suo peso. Ad esempio, a 0,95:

ceph osd reweight osd.${ID} 0.95

In questo modo viene liberato spazio su disco negli OSD e viene corretto l'errore in ceph health. Tuttavia, come già accennato, questo problema si verifica principalmente a causa di una configurazione errata di Ceph nelle fasi iniziali: è molto importante fare una riconfigurazione affinché non si presenti in futuro.

Nel nostro caso specifico, tutto era legato a:

un valore troppo alto replication_count in uno dei pool,
troppo alto numero di PG in un pool e troppo basso in un altro.

Utilizziamo il già menzionato calcolatore. Esso mostra chiaramente cosa è necessario inserire e, in linea di massima, non c'è niente di complicato. Immettendo i parametri richiesti, otteniamo le seguenti raccomandazioni:

Nota: se si sta impostando un cluster Ceph da zero, un'altra utile funzione del calcolatore sarà la generazione di comandi, che creeranno pool da zero con i parametri indicati nella tabella.

L'ultima colonna aiuta a orientarsi — Suggested PG Count. In questo caso è utile anche la seconda, dove è indicato il parametro di replica, poiché abbiamo deciso di modificare il moltiplicatore di replica.

Quindi, prima di tutto, è necessario cambiare i parametri di replica — è importante farlo in primo luogo, poiché riducendo il moltiplicatore libereremo spazio su disco. Durante l'esecuzione del comando ci si può accorgere che il valore dello spazio disco disponibile aumenterà:

ceph osd pool $pool_name set $replication_size

E dopo il suo completamento — cambiamo i valori dei parametri pg_num e pgp_num nel seguente modo:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Importante: dobbiamo modificare progressivamente il numero di PG in ogni pool senza cambiare i valori negli altri pool finché non scompaiono gli avvisi «Ridondanza dei dati degradata» e «n numero di pgs degradati».

Puoi anche verificare che tutto sia andato a buon fine attraverso l'output dei comandi ceph health detail e ceph -s.

Caso n.3. Migrazione di una macchina virtuale da LVM a Ceph RBD

In situazioni in cui si utilizzano macchine virtuali installate su server bare-metal in affitto, spesso sorge la questione di uno storage ridondante. Inoltre, è molto desiderabile che ci sia spazio sufficiente in questo storage... Un'altra situazione comune è che ci sia una macchina virtuale con storage locale sul server e sia necessario estendere il disco, ma non c'è spazio disponibile poiché il server non ha più spazio libero.

Il problema può essere risolto in diversi modi: ad esempio, migrando su un altro server (se disponibile) o aggiungendo nuovi dischi al server. Tuttavia, non sempre è possibile farlo, quindi la migrazione da LVM a Ceph può essere una soluzione eccellente a questo problema. Scegliendo questa opzione, semplifichiamo anche il futuro processo di migrazione tra server, poiché non sarà necessario spostare lo storage locale da un hypervisor all'altro. L'unico inconveniente è che sarà necessario fermare la VM durante i lavori.

Come ricetta riportata di seguito, abbiamo preso un articolo di questo blog, le cui istruzioni sono state testate in azione. A proposito, è anche descritto un metodo di migrazione senza downtime, ma nel nostro caso non è stato necessario, quindi non lo abbiamo testato. Se è critico per il vostro progetto, saremo felici di conoscere i risultati nei commenti.

Iniziamo la parte pratica. Nell'esempio utilizziamo virsh e, di conseguenza, libvirt. Per prima cosa, assicurati che il pool Ceph in cui verranno migrati i dati sia connesso a libvirt:

virsh pool-dumpxml $ceph_pool

Nella descrizione del pool devono essere presenti i dati di connessione a Ceph con le informazioni di autorizzazione.

La fase successiva consiste nella conversione dell'immagine LVM in Ceph RBD. Il tempo di esecuzione dipende principalmente dalle dimensioni dell'immagine:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Dopo la conversione rimarrà l'immagine LVM, utile nel caso in cui non si riesca a migrare la VM in RBD e sia necessario ripristinare le modifiche. Inoltre, per avere la possibilità di ripristinare rapidamente le modifiche, faremo un backup del file di configurazione della macchina virtuale:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

… e modificheremo l'originale (vm_name.xml). Troveremo il blocco con la descrizione del disco (inizia con la riga <disk type='file' device='disk'> e termina con </disk>) e lo porteremo nella seguente forma:

Analizziamo alcuni dettagli:

Nel protocollo source si specifica l'indirizzo della memoria in Ceph RBD (questo è l'indirizzo che include il nome del pool Ceph e l'immagine RBD definita nella fase iniziale).
Nel blocco segreto si specifica il tipo ceph, insieme all'UUID del segreto per la connessione. Il suo uuid può essere trovato utilizzando il comando virsh secret-list.
Nel blocco host si specificano gli indirizzi dei monitor Ceph.

Dopo aver modificato il file di configurazione e completato la conversione da LVM a RBD, è possibile applicare il file di configurazione modificato e avviare la macchina virtuale:

virsh define $vm_name.xml
virsh start $vm_name

È il momento di verificare che la macchina virtuale si avvii correttamente: questo può essere fatto, ad esempio, collegandosi ad essa tramite SSH o attraverso virsh.

Se la macchina virtuale funziona correttamente e non hai riscontrato altri problemi, puoi eliminare l'immagine LVM che non è più utilizzata:

lvremove main/$vm_image_name

Conclusione

Abbiamo affrontato tutte le situazioni descritte nella pratica — speriamo che queste istruzioni aiutino anche altri amministratori a risolvere problemi simili. Se hai osservazioni o altre storie simili basate sulla tua esperienza con Ceph, saremo felici di vederle nei commenti!