Utilizzando Ceph come spazio di archiviazione di rete in progetti con carichi diversi, potremmo incontrare diversi compiti che a prima vista non sembrano semplici o banali. Per esempio:
- migrazione dati dal vecchio Ceph al nuovo con utilizzo parziale dei server precedenti nel nuovo cluster;
- soluzione al problema dell'allocazione dello spazio su disco in Ceph.
Quando si affrontano tali problemi, ci troviamo di fronte alla necessità di rimuovere correttamente l'OSD senza perdere dati, il che è particolarmente importante quando si tratta di grandi quantità di dati. Questo sarà discusso nell'articolo.
I metodi descritti di seguito sono rilevanti per qualsiasi versione di Ceph. Inoltre, verrà tenuto conto del fatto che Ceph può archiviare una grande quantità di dati: per evitare perdite di dati e altri problemi, alcune azioni verranno “suddivise” in molte altre.
Prefazione sull'OSD
Poiché due delle tre ricette discusse sono dedicate all'OSD (), prima di tuffarci nella parte pratica - brevemente su cosa è Ceph e perché è così importante.
Innanzitutto va detto che l’intero cluster Ceph è composto da numerosi OSD. Più ce ne sono, maggiore è il volume di dati gratuiti in Ceph. Da qui è facile capirlo funzione principale dell'OSD: memorizza i dati degli oggetti Ceph sui file system di tutti i nodi del cluster e fornisce l'accesso alla rete (per lettura, scrittura e altre richieste).
Allo stesso livello, i parametri di replica vengono impostati copiando gli oggetti tra diversi OSD. E qui puoi incontrare vari problemi, le cui soluzioni verranno discusse di seguito.
Caso n. 1. Rimuovi in modo sicuro l'OSD dal cluster Ceph senza perdere dati
La necessità di rimuovere l'OSD può essere causata dalla rimozione del server dal cluster, ad esempio per sostituirlo con un altro server, come è successo a noi, dando origine alla stesura di questo articolo. Pertanto, l'obiettivo finale della manipolazione è estrarre tutti gli OSD e i mons su un dato server in modo che possa essere fermato.
Per comodità e per evitare una situazione in cui, durante l'esecuzione dei comandi, si commette un errore nell'indicazione dell'OSD richiesto, imposteremo una variabile separata, il cui valore sarà il numero dell'OSD da eliminare. Chiamiamola ${ID} — qui e sotto tale variabile sostituisce il numero dell'OSD con cui stiamo lavorando.
Diamo un'occhiata alle condizioni prima di iniziare il lavoro:
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, dovrai eseguirla senza problemi reweight su di esso a zero. In questo modo riduciamo la quantità di dati nell'OSD bilanciandola con altri OSD. Per fare ciò, esegui 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 allo zero.
È necessario un buon bilanciamentoper non perdere i dati. Ciò è particolarmente vero se l'OSD contiene una grande quantità di dati. Per assicurarti che dopo aver eseguito i comandi reweight è andato tutto bene, puoi completarlo ceph -s o in una finestra di terminale separata eseguita ceph -w per osservare i cambiamenti in tempo reale.
Quando l'OSD risulta “svuotato”, si può procedere con l'operazione standard per rimuoverlo. Per fare ciò, trasferire l'OSD desiderato allo 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 FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Rimuovi l'OSD da :
ceph osd crush remove osd.${ID}Eliminiamo l'utente OSD:
ceph auth del osd.${ID}E infine, rimuoviamo l'OSD stesso:
ceph osd rm osd.${ID}Nota: Se stai utilizzando la versione di Ceph Luminous o successiva, i passaggi di rimozione dell'OSD sopra riportati possono essere ridotti a due comandi:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Se, dopo aver completato i passaggi sopra descritti, esegui il comando ceph osd tree, allora dovrebbe essere chiaro che sul server dove è stato eseguito il lavoro non sono più presenti OSD per i quali sono state eseguite le operazioni sopra indicate:
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
Lungo il percorso, nota che lo stato dell'ammasso Ceph andrà a HEALTH_WARNe vedremo anche una diminuzione del numero di OSD e della quantità di spazio su disco disponibile.
Di seguito verranno descritti i passaggi che saranno necessari se si desidera arrestare completamente il server e, di conseguenza, rimuoverlo da Ceph. In questo caso è importante ricordarlo Prima di spegnere il server, è necessario rimuovere tutti gli OSD su questo server.
Se non sono rimasti più OSD su questo server, dopo averli rimossi è necessario escludere il server dalla mappa OSD hv-2eseguendo il seguente comando:
ceph osd crush rm hv-2
Elimina mon dal server hv-2eseguendo il comando seguente su un altro server (ovvero, in questo caso, su hv-1):
ceph-deploy mon destroy hv-2Successivamente è possibile arrestare il server e iniziare le azioni successive (ridistribuirlo, ecc.).
Caso n. 2. Distribuzione dello spazio su disco in un cluster Ceph già creato
Inizierò la seconda storia con una prefazione su PG (). Il ruolo principale di PG in Ceph è principalmente quello di aggregare oggetti Ceph e replicarli ulteriormente nell'OSD. La formula con la quale è possibile calcolare la quantità necessaria di PG è in Documentazione Ceph. Anche questo problema viene discusso lì con esempi specifici.
Quindi: uno dei problemi più comuni quando si utilizza Ceph è il numero sbilanciato di OSD e PG tra i pool in Ceph.
In primo luogo, a causa di ciò, può verificarsi una situazione in cui vengono specificati troppi PG in un piccolo pool, il che è essenzialmente un utilizzo irrazionale dello spazio su disco nel cluster. In secondo luogo, in pratica si presenta un problema più serio: l'overflow dei dati in uno degli OSD. Ciò comporta la prima transizione del cluster allo stato HEALTH_WARN, poi HEALTH_ERR. Il motivo è che Ceph, quando calcola la quantità di dati disponibili (puoi scoprirlo tramite MAX AVAIL nell'output del comando ceph df per ciascun pool separatamente) si basa sulla quantità di dati disponibili nell'OSD. Se non c'è spazio sufficiente in almeno un OSD, non è possibile scrivere altri dati finché i dati non vengono distribuiti correttamente tra tutti gli OSD.
Vale la pena chiarire che questi problemi vengono in gran parte decisi nella fase di configurazione del cluster Ceph. Uno degli strumenti che puoi utilizzare è . Con il suo aiuto, la quantità richiesta di PG viene calcolata chiaramente. Tuttavia, puoi anche ricorrere ad esso in una situazione in cui il cluster Ceph già configurato in modo errato. Vale la pena chiarire qui che come parte del lavoro di correzione molto probabilmente sarà necessario ridurre il numero di PG e questa funzionalità non è disponibile nelle versioni precedenti di Ceph (appariva solo nella versione ).
Quindi, immaginiamo la seguente immagine: il cluster ha uno stato HEALTH_WARN a causa di uno spazio esaurito sull'OSD. Ciò verrà indicato da un errore HEALTH_WARN: 1 near full osd. Di seguito è riportato un algoritmo per uscire da questa situazione.
Prima di tutto è necessario distribuire i dati disponibili tra i restanti OSD. Abbiamo già eseguito un'operazione simile nel primo caso, quando abbiamo “drenato” il nodo, con l'unica differenza che ora dovremo ridurre leggermente reweight. Ad esempio, fino a 0.95:
ceph osd reweight osd.${ID} 0.95Ciò libera spazio su disco nell'OSD e corregge l'errore nell'integrità di Ceph. Tuttavia, come già accennato, questo problema si verifica principalmente a causa di un'errata configurazione di Ceph nelle fasi iniziali: è molto importante effettuare una riconfigurazione affinché non si presenti in futuro.
Nel nostro caso particolare, tutto si riduceva a:
- valore troppo alto
replication_countin una delle piscine, - troppo PG in un pool e troppo poco in un altro.
Usiamo la calcolatrice già menzionata. Mostra chiaramente cosa deve essere inserito e, in linea di principio, non c'è nulla di complicato. Dopo aver impostato i parametri necessari, otteniamo i seguenti consigli:
Nota: Se stai configurando un cluster Ceph da zero, un'altra funzione utile della calcolatrice è la generazione di comandi che creeranno pool da zero con i parametri specificati nella tabella.
L'ultima colonna ti aiuta a navigare: Conteggio PG suggerito. Nel nostro caso è utile anche il secondo, dove è indicato il parametro di replica, poiché abbiamo deciso di modificare il moltiplicatore di replica.
Quindi, prima devi modificare i parametri di replica: vale la pena farlo prima, poiché riducendo il moltiplicatore libereremo spazio su disco. Durante l'esecuzione del comando, noterai che lo spazio disponibile su disco aumenterà:
ceph osd pool $pool_name set $replication_size
E dopo il suo completamento, modifichiamo i valori dei parametri pg_num и pgp_num следующим обрахом:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberÈ importante: dobbiamo modificare il numero di PG in sequenza in ogni pool e non modificare i valori negli altri pool finché gli avvisi non scompaiono "Ridondanza dei dati ridotta" и "numero n di pg degradati".
Puoi anche verificare che tutto sia andato bene utilizzando gli output del comando ceph health detail и ceph -s.
Caso n. 3. Migrazione di una macchina virtuale da LVM a Ceph RBD
In una situazione in cui un progetto utilizza macchine virtuali installate su server bare metal noleggiati, spesso si pone il problema dello storage tollerante ai guasti. È anche molto auspicabile che ci sia abbastanza spazio in questo spazio di archiviazione... Un'altra situazione comune: c'è una macchina virtuale con archiviazione locale sul server ed è necessario espandere il disco, ma non c'è nessun posto dove andare, perché non c'è spazio libero su disco rimasto sul server.
Il problema può essere risolto in diversi modi, ad esempio migrando su un altro server (se presente) o aggiungendo nuovi dischi al server. Ma non è sempre possibile farlo, quindi la migrazione da LVM a Ceph può essere un’ottima soluzione a questo problema. Scegliendo questa opzione, semplifichiamo anche l'ulteriore processo di migrazione tra i server, poiché non sarà necessario spostare lo storage locale da un hypervisor all'altro. L'unico problema è che dovrai fermare la VM mentre il lavoro viene eseguito.
La seguente ricetta è tratta da , le cui istruzioni sono state testate in azione. A proposito, lì viene descritto anche il metodo di migrazione senza problemi, tuttavia, nel nostro caso semplicemente non era necessario, quindi non l'abbiamo controllato. Se questo è fondamentale per il tuo progetto, saremo lieti di conoscere i risultati nei commenti.
Passiamo alla parte pratica. Nell'esempio utilizziamo virsh e, di conseguenza, libvirt. Innanzitutto, assicurati che il pool Ceph su cui verranno migrati i dati sia connesso a libvirt:
virsh pool-dumpxml $ceph_poolLa descrizione del pool deve contenere i dati di connessione a Ceph con i dati di autorizzazione.
Il passaggio successivo è che l'immagine LVM viene convertita 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_nameDopo la conversione, rimarrà un'immagine LVM, che sarà utile se la migrazione della VM a RBD fallisce e devi ripristinare le modifiche. Inoltre, per poter ripristinare rapidamente le modifiche, eseguiamo 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 modifica l'originale (vm_name.xml). Troviamo un blocco con una descrizione del disco (inizia con la riga <disk type='file' device='disk'> e termina con </disk>) e ridurlo alla forma seguente:
<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>Vediamo alcuni dettagli:
- Al protocollo
sourceè indicato l'indirizzo dell'archiviazione in Ceph RBD (questo è l'indirizzo che indica il nome del pool Ceph e l'immagine RBD, che è stata determinata nella prima fase). - Nel blocco
secretè indicato il tipoceph, nonché l'UUID del segreto per connettersi ad esso. Il suo uuid può essere trovato usando il comandovirsh secret-list. - Nel blocco
hostsono indicati gli indirizzi ai monitor Ceph.
Dopo aver modificato il file di configurazione e completato la conversione da LVM a RBD, puoi 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 sia avviata correttamente: potrai scoprirlo, ad esempio, collegandoti ad essa tramite SSH oppure tramite virsh.
Se la macchina virtuale funziona correttamente e non hai riscontrato altri problemi, allora puoi eliminare l'immagine LVM che non viene più utilizzata:
lvremove main/$vm_image_nameconclusione
Abbiamo riscontrato nella pratica tutti i casi descritti: speriamo che le istruzioni aiutino altri amministratori a risolvere problemi simili. Se hai commenti o altre storie simili relative alla tua esperienza con Ceph, saremo lieti di vederli nei commenti!
PS
Leggi anche sul nostro blog:
- «";
- «";
- «";
- «'.
Fonte: habr.com