🥇Tips & tricks per lavorare con Ceph in progetti ad alta intensità

Utilizzando Ceph come archivio di rete in progetti con carichi diversi, possiamo affrontare varie sfide che, a prima vista, non sembrano semplici o banali. Per esempio:

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

Affrontando tali sfide, ci troviamo nella necessità di estrarre correttamente l'OSD senza perdere dati, un aspetto particolarmente rilevante quando si gestiscono grandi volumi di dati. Di questo parleremo nell'articolo.

I metodi descritti di seguito sono rilevanti per tutte le versioni di Ceph. Inoltre, sarà considerato il fatto che Ceph può contenere grandi volumi di dati: per prevenire perdite di dati e altri problemi, alcune azioni saranno 'suddivise' in diverse altre.

Prefazione sugli OSD

Poiché due dei tre ricette analizzate sono dedicate agli OSD (Object Storage Daemon), prima di tuffarci nella parte pratica, facciamo un breve accenno a cosa siano effettivamente in Ceph e perché siano così importanti.

Innanzitutto, si deve dire che l'intero cluster Ceph è composto da numerosi OSD. Più OSD abbiamo, maggiore sarà lo spazio di archiviazione disponibile in Ceph. Da qui, è facile capire la funzione principale degli OSD: essi memorizzano i dati degli oggetti Ceph sui file system di tutti i nodi del cluster e offrono accesso di rete a questi dati (per lettura, scrittura e altre richieste).

A questo stesso livello vengono impostati i parametri di replica tramite la copia degli oggetti tra i diversi OSD. Qui si possono presentare varie problematiche, le cui soluzioni saranno trattate in seguito.

Caso n. 1. Estrarre in sicurezza un OSD dal cluster Ceph senza perdere dati

La necessità di estrarre un OSD può derivare dall'uscita di un server dal cluster, ad esempio, per sostituirlo con un altro server, ed è proprio ciò che ci è accaduto, spingendoci a scrivere questo articolo. Pertanto, l'obiettivo finale delle manovre è estrarre tutti gli OSD e i mon su questo server, affinché possa essere spento.

Per comodità e per escludere situazioni in cui potremmo commettere errori nell'indicazione del giusto OSD durante l'esecuzione dei comandi, imposteremo una variabile separata, il cui valore sarà il numero dell'OSD da rimuovere. La chiameremo ${ID} — qui e in seguito, tale variabile sostituisce il numero dell'OSD con cui stiamo lavorando.

Diamo un'occhiata allo stato prima di iniziare i 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 di un OSD, è necessario eseguire un riaggiustamento graduale fino a zero. In questo modo riduciamo la quantità di dati nell'OSD bilanciando verso altri OSD. A tal fine, si eseguono 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.

Il bilanciamento graduale è necessario, per non perdere dati. Questo è particolarmente importante se l'OSD contiene un grande volume di dati. Per assicurarci che dopo l'esecuzione dei comandi riaggiustamento tutto sia andato a buon fine, possiamo eseguire ceph -s oppure in una finestra separata del terminale eseguire ceph -w per osservare le modifiche in tempo reale.

Quando l'OSD è "svuotato", possiamo procedere con l'operazione standard di rimozione. A tal fine, mettiamo l'OSD desiderato nello stato down:

ceph osd down osd.${ID}

"Tiriamo fuori" l'OSD dal cluster:

ceph osd out osd.${ID}

Arrestiamo il servizio OSD e smontiamo la sua partizione nel file system:

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

Rimuoviamo l'OSD dalla mappa CRUSH:

ceph osd crush remove osd.${ID}

Rimuoviamo l'utente OSD:

ceph auth del osd.${ID}

E, infine, rimuoviamo l'OSD stesso:

ceph osd rm osd.${ID}

Nota: se stai utilizzando una versione di Ceph Luminous o superiore, le azioni descritte sopra per rimuovere l'OSD possono essere riassunte in due comandi:

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

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

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

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

Successivamente verranno descritti i passaggi necessari se si desidera fermare completamente il server e, di conseguenza, rimuoverlo da Ceph. In tal caso, è importante ricordare che prima di spegnere il server è necessario estrarre tutti gli OSD su questo server.

Se su questo server non ci sono più OSD, dopo la loro rimozione è necessario escludere dalla mappa OSD il server hv-2, eseguendo il seguente comando:

ceph osd crush rm hv-2

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

ceph-deploy mon destroy hv-2

Dopo di ciò, puoi spegnere il server e procedere con le azioni successive (la sua ridistribuzione, ecc.).

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

Inizierò la seconda storia con un preambolo sui PG (Placement Groups). Il ruolo principale dei PG in Ceph è, prima di tutto, quello di aggregare gli oggetti Ceph e di replicarli nei OSD. La formula per calcolare il numero necessario di PG si trova nella sezione corrispondente documentazione di Ceph. Qui la questione è trattata anche con esempi concreti.

Dunque, uno dei problemi più comuni nell'uso di Ceph è un numero sbilanciato di OSD e PG tra i pool in Ceph.

In primo luogo, potrebbe sorgere una situazione in cui viene indicato un numero eccessivo di PG in un pool di piccole dimensioni, il che in sostanza rappresenta un utilizzo irrazionale dello spazio su disco nel cluster. In secondo luogo, nella pratica si presenta un problema più grave: l'overflow dei dati in uno dei OSD. Questo comporta il passaggio del cluster prima in uno stato HEALTH_WARN, e poi anche HEALTH_ERR. Il colpevole è che Ceph, nel calcolare il volume di dati disponibile (che puoi conoscere da MAX AVAIL nell'output del comando ceph df per ogni pool separatamente) si basa sul volume di dati disponibili negli OSD. Se anche solo in uno degli OSD non c'è spazio sufficiente, non sarà possibile scrivere ulteriori dati finché i dati non saranno distribuiti correttamente tra tutti gli OSD.

Va notato che questi problemi vengono risolti in maggiore misura nella fase di configurazione del cluster Ceph. Uno degli strumenti che puoi utilizzare è Ceph PGCalc. Con esso, si calcola chiaramente il numero necessario di PG. Tuttavia, puoi ricorrervi anche in situazioni in cui il cluster Ceph ha già è configurato in modo errato. Qui è importante chiarire che nel corso dei lavori di correzione, probabilmente dovrai ridurre il numero di PG, e questa possibilità non è accessibile nelle vecchie versioni di Ceph (è stata introdotta solo a partire dalla versione Nautilus).

Immaginiamo dunque la seguente situazione: il cluster ha uno stato HEALTH_WARN a causa del fatto che in uno degli OSD sta finendo lo spazio. Questo sarà indicato da un errore HEALTH_WARN: 1 near full osd. Di seguito è presentato un algoritmo per uscire da tale situazione.

In primo luogo, è necessario distribuire i dati esistenti tra gli altri OSD. Un'operazione simile è stata già eseguita nel primo caso, quando abbiamo "disidratato" un nodo — con l'unica differenza che ora sarà necessario ridurre leggermente riaggiustamento. Ad esempio, fino a 0.95:

ceph osd reweight osd.${ID} 0.95

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

Nel nostro caso specifico, tutto dipendeva da:

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

Utilizziamo il calcolatore già menzionato. Esso mostra chiaramente cosa è necessario inserire e, in linea di principio, non c'è nulla di complicato. Impostando i parametri necessari, otteniamo le seguenti raccomandazioni:

Nota: se stai configurando un cluster Ceph da zero, un'altra funzionalità utile del calcolatore sarà la generazione di comandi che creeranno pool da zero con i parametri specificati nella tabella.

L'ultimo colonna aiuta a orientarsi — Suggested PG Count. Nel nostro caso, utile è anche il secondo, dove è indicato il parametro di replica, poiché abbiamo deciso di modificare anche il fattore di replica.

Quindi, per prima cosa, sarà necessario modificare i parametri di replica: è consigliabile farlo prima di tutto, poiché riducendo il fattore libereremo spazio su disco. Durante l'esecuzione del comando, si può notare che il valore dello spazio disponibile aumenterà:

ceph osd pool $pool_name set $replication_size

E dopo il suo completamento, modificare 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 sequentially il numero di PG in ogni pool e non cambiare i valori in altri pool finché non scompaiono gli avvisi "Degraded data redundancy" e "n-number of pgs degraded".

Verificare che tutto sia andato a buon fine può essere fatto anche dai risultati dei comandi ceph health detail e ceph -s.

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

Nella situazione in cui nel progetto vengono utilizzate macchine virtuali installate su server bare-metal a noleggio, spesso si pone la questione di uno storage altamente disponibile. È inoltre molto desiderabile che ci sia abbastanza spazio in questo storage... Un'altra situazione comune: c'è una macchina virtuale con storage locale sul server e è necessario espandere il disco, ma non c'è spazio disponibile, poiché non è rimasto spazio libero sul server.

Il problema può essere risolto in vari modi — ad esempio, migrando su un altro server (se ne esiste uno) o aggiungendo nuovi dischi al server. Ma non sempre è possibile farlo, quindi la migrazione da LVM a Ceph può essere una ottima soluzione a questo problema. Scegliendo questa opzione, semplifichiamo anche il processo di migrazione tra i server, poiché non sarà necessario spostare lo storage locale da un hypervisor all'altro. L'unico inconveniente è che dovrà essere fermata la VM per il tempo necessario ai lavori.

Come ricetta riportata di seguito è presa un articolo di questo blog, le cui istruzioni sono state testate in azione. A proposito, lì viene descritto anche un modo di migrazione senza difficoltà, ma nel nostro caso non ci è stato necessario, quindi non l'abbiamo verificato. Se questo è critico per il tuo progetto, saremo lieti di conoscere i risultati nei commenti.

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

virsh pool-dumpxml $ceph_pool

Nella descrizione del pool dovrebbero esserci i dati di connessione a Ceph con i dati per l'autenticazione.

La fase successiva consiste nel convertire l'immagine LVM in Ceph RBD. Il tempo di esecuzione dipende principalmente dalla dimensione 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, che sarà utile nel caso in cui la migrazione della VM in RBD non vada a buon fine 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 (che 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 indica l'indirizzo dello storage in Ceph RBD (questo è l'indirizzo con il nome del ceph-pool e dell'immagine RBD definita nella prima fase).
Nella sezione secret si indica il tipo ceph, così come l'UUID del segreto per la connessione. Il suo uuid può essere ottenuto con il comando virsh secret-list.
Nella sezione host si indicano 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 controllare che la macchina virtuale sia avviata correttamente: è possibile verificarlo, ad esempio, collegandosi via SSH o tramite virsh.

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

lvremove main/$vm_image_name

Conclusione

Abbiamo affrontato tutti i casi descritti nella pratica — speriamo che queste istruzioni possano aiutare anche altri amministratori a risolvere problemi simili. Se hai osservazioni o altre esperienze simili con l'utilizzo di Ceph — ci farebbe piacere vederle nei commenti!