Cunsiglii è trucchi per travaglià cù Ceph in prughjetti impegnati

Utilizendu Ceph cum'è almacenamentu di rete in prughjetti cù carichi diffirenti, pudemu scontru diverse attività chì à u primu sguardu ùn parenu micca simplici o triviali. Per esempiu:

• migrazione di dati da u vechju Ceph à u novu cù usu parziale di servitori precedenti in u novu cluster;
• suluzione à u prublema di l'assignazione di u spaziu di discu in Ceph.

Trattamentu di tali prublemi, avemu affruntatu cù a necessità di sguassà currettamente l'OSD senza perda dati, chì hè particularmente impurtante quandu si tratta di grandi quantità di dati. Questu serà discutitu in l'articulu.

I metudi descritti quì sottu sò pertinenti per qualsiasi versione di Ceph. Inoltre, u fattu chì Ceph pò almacenà una grande quantità di dati serà pigliatu in contu: per prevene a perdita di dati è altri prublemi, certi azzioni seranu "split" in parechji altri.

Prefazione nantu à l'OSD

Siccomu duie di e trè ricette discussate sò dedicate à l'OSD (Daemon di Storage d'Oggetti), prima di immersione in a parte pratica - brevemente ciò chì hè in Ceph è perchè hè cusì impurtante.

Prima di tuttu, deve esse dettu chì tuttu u cluster Ceph hè custituitu da parechji OSD. Più ci sò, più grande u voluminu di dati gratuiti in Ceph. Hè faciule da capisce da quì funzione principale OSD: Guarda i dati di l'ughjettu Ceph in i sistemi di schedari di tutti i nodi di cluster è furnisce l'accessu à a rete (per leghje, scrive è altre dumande).

À u listessu livellu, i paràmetri di replicazione sò stabiliti copiendu oggetti trà e diverse OSD. È quì pudete scontru diversi prublemi, i suluzioni à quale seranu discututi quì sottu.

Casu n ° 1. Eliminate in modu sicuru l'OSD da u cluster Ceph senza perde dati

U bisognu di caccià l'OSD pò esse pruvucatu da sguassà u servitore da u cluster - per esempiu, per rimpiazzà cù un altru servitore - chì hè ciò chì hè accadutu à noi, dendu a scrittura di stu articulu. Cusì, l'ultimu scopu di a manipulazione hè di caccià tutti l'OSD è i mons nantu à un servitore datu in modu chì pò esse firmatu.

Per a cunvenzione è per evità una situazione induve facemu un sbagliu in specificà l'OSD necessariu durante l'esecuzione di cumandamenti, stabiliremu una variabile separata, u valore di quale serà u numeru di l'OSD da esse eliminatu. Chjamemu ${ID} - quì è quì sottu, una tale variabile rimpiazza u numeru di l'OSD cù quale avemu travagliatu.

Fighjemu a cundizione prima di inizià u travagliu:

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 inizià a rimuzione di l'OSD, vi tuccherà à fà lisu reweight nantu à u zero. In questu modu, riducemu a quantità di dati in l'OSD equilibrendu à l'altri OSD. Per fà questu, eseguite i seguenti cumandamenti:

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

... è cusì finu à zero.

Hè necessariu un equilibriu lisuper ùn perde micca dati. Questu hè soprattuttu veru se l'OSD cuntene una grande quantità di dati. Per assicurà chì dopu à eseguisce i cumandamenti reweight tuttu hè andatu bè, pudete cumpletà ceph -s o in una finestra di terminal separata ceph -w per osservà i cambiamenti in tempu reale.

Quandu l'OSD hè "svuotata", pudete cuntinuà cù l'operazione standard per sguassà. Per fà questu, trasfiriu l'OSD desideratu à u statu down:

ceph osd down osd.${ID}

"Tiramu" l'OSD da u cluster:

ceph osd out osd.${ID}

Fermemu u serviziu OSD è smontà a so partizione in u FS:

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

Eliminate l'OSD da mappa CRUSH:

ceph osd crush remove osd.${ID}

Sguassemu l'utilizatore OSD:

ceph auth del osd.${ID}

È infine, sguassemu l'OSD stessu:

ceph osd rm osd.${ID}

Vita: Sè vo aduprate a versione Ceph Luminous o superiore, allora i passi di rimuzione di l'OSD sopra ponu esse ridotti à dui cumandamenti:

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

Sè, dopu à compie i passi descritti sopra, eseguite u cumandamentu ceph osd tree, Tandu deve esse chjaru chì nantu à u servitore induve u travagliu hè statu realizatu ùn ci sò più OSD per quale l'operazioni sopra sò state realizate:

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

In u caminu, nutate chì u statu di u cluster Ceph anderà HEALTH_WARN, è avemu ancu vede una diminuzione in u numeru di OSD è a quantità di spaziu di discu dispunibule.

U seguitu descriverà i passi chì saranu necessarii se vulete fermà completamente u servitore è, per quessa, sguassate da Ceph. In questu casu, hè impurtante di ricurdà chì Prima di chjude u servitore, duvete sguassà tutte l'OSD nant'à stu servore.

Se ùn ci hè più OSD in questu servitore, dopu avè eliminatu, avete bisognu di escludiri u servitore da a mappa OSD. hv-2eseguendu u cumandimu seguente:

ceph osd crush rm hv-2

Elimina mon da u servitore hv-2eseguendu u cumandimu quì sottu in un altru servitore (vale à dì in questu casu, on hv-1):

ceph-deploy mon destroy hv-2

Dopu questu, pudete piantà u servitore è principià l'azzioni successive (re-deploying it, etc.).

Casu n ° 2. Distribuzione di u spaziu di discu in un cluster Ceph digià creatu

Cumincià a seconda storia cù una prefazione nantu à PG (Gruppi di piazzamentu). U rolu principali di PG in Ceph hè principalmente di aggregate l'uggetti Ceph è riplicà in più in OSD. A formula cù quale pudete calculà a quantità necessaria di PG hè in sezione pertinente Documentazione Ceph. Stu prublema hè ancu discututu quì cù esempi specifichi.

Allora: unu di i prublemi cumuni quandu si usa Ceph hè u numeru sbilanciatu di OSD è PG trà e piscine in Ceph.

Prima, per quessa, una situazione pò esse quandu troppu PG sò specificati in una piccula piscina, chì hè essenzialmente un usu irrazionale di u spaziu di discu in u cluster. Siconda, in pratica, ci hè un prublema più seriu: overflow di dati in unu di l'OSD. Questu implica a prima transizione di u cluster à u statu HEALTH_WARN, è dopu HEALTH_ERR. U mutivu di questu hè chì Ceph, quandu calcula a quantità dispunibile di dati (pudete truvà fora da MAX AVAIL in l'output di cumandamentu ceph df per ogni piscina separatamente) hè basatu annantu à a quantità di dati dispunibili in l'OSD. Se ùn ci hè micca abbastanza spaziu in almenu un OSD, ùn ponu micca più dati scritti finu à chì i dati sò distribuiti bè trà tutti l'OSD.

Vale a pena chjarificà chì sti prublemi sò largamente decisu in u stadiu di cunfigurazione di u cluster Ceph. Unu di i strumenti chì pudete aduprà hè Ceph PGCalc. Cù u so aiutu, a quantità necessaria di PG hè chjaramente calculata. In ogni casu, pudete ancu ricorrere à questu in una situazione induve u cluster Ceph digià cunfiguratu incorrectamente. Vale a pena chjarificà quì chì, in parte di u travagliu di riparazione, avete bisognu di riduce u numeru di PG, è sta funzione ùn hè micca dispunibule in versioni più vechje di Ceph (apparsu solu in versione). Nautilus).

Allora, imaginemu a seguente stampa: u cluster hà un statutu HEALTH_WARN duvuta à unu di l 'OSD scappari di u spaziu. Questu serà indicatu da un errore HEALTH_WARN: 1 near full osd. Quì sottu hè un algoritmu per esce da sta situazione.

Prima di tuttu, avete bisognu di distribuisce e dati dispunibili trà l'OSD restante. Avemu digià fattu una operazione simili in u primu casu, quandu avemu "svucatu" u node - cù l'unica diferenza chì avà avemu bisognu di riduce ligeramente. reweight. Per esempiu, finu à 0.95:

ceph osd reweight osd.${ID} 0.95

Questu libera u spaziu di discu in l'OSD è corregge l'errore in a salute di ceph. In ogni casu, cum'è digià citatu, stu prublema si trova principalmente per a cunfigurazione incorrecta di Ceph in i fasi iniziali: hè assai impurtante per fà una ricunfigurazione per ùn esse micca in u futuru.

In u nostru casu particulare, tuttu hè vinutu à:

• valore troppu altu replication_count in una di e piscine,
• troppu PG in una piscina è troppu pocu in un altru.

Utilizemu a calculatrice digià citata. Mostra chjaramente ciò chì deve esse inseritu è, in principiu, ùn ci hè nunda cumplicatu. Dopu avè stabilitu i paràmetri necessarii, avemu i seguenti cunsiglii:

Vita: Sè vo stallate un cluster Ceph da zero, una altra funzione utile di a calculatrice hè a generazione di cumandamenti chì creanu piscine da zero cù i paràmetri specificati in a tavula.

L'ultima colonna vi aiuta à navigà - Conte PG suggeritu. In u nostru casu, u sicondu hè ancu utile, induve u paràmetru di replicazione hè indicatu, postu chì avemu decisu di cambià u multiplicatore di replicazione.

Allora, prima avete bisognu di cambià i paràmetri di replicazione - questu vale a pena fà prima, postu chì riducendu u multiplicatore, liberaremu u spaziu di discu. Quandu u cumandamentu eseguisce, vi vede chì u spaziu di discu dispunibule aumenterà:

ceph osd pool $pool_name set $replication_size

È dopu a so cumpiimentu, cambiamu i valori di i paràmetri pg_num и pgp_num a siguenti:

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

impurtanti: duvemu cambià u numeru di PG in sequenza in ogni piscina è micca cambià i valori in altre piscine finu à chì l'avvertimenti spariscenu "Rundanza di dati degradata" и "n-numeru di pagine degradate".

Pudete ancu verificà chì tuttu hè andatu bè cù l'outputs di cumanda ceph health detail и ceph -s.

Casu n ° 3. Migrazione di una macchina virtuale da LVM à Ceph RBD

In una situazione induve un prughjettu usa macchine virtuale installate nantu à i servitori bare-metal affittati, u prublema di l'almacenamiento tolerante à i difetti spessu sorge. Hè ancu assai desideratu chì ci hè abbastanza spaziu in questu almacenamentu ... Un'altra situazione cumuna: ci hè una macchina virtuale cù almacenamiento locale nantu à u servitore è avete bisognu di espansione u discu, ma ùn ci hè nunda per andà, perchè ùn ci hè micca. spaziu di discu liberu lasciatu nantu à u servitore.

U prublema pò esse risolta in diverse manere - per esempiu, migrandu à un altru servitore (se ci hè unu) o aghjunghjenu novi discu à u servitore. Ma ùn hè micca sempre pussibule di fà questu, cusì a migrazione da LVM à Ceph pò esse una suluzione eccellente à stu prublema. Sceglie sta opzione, simplificà ancu u prucessu ulteriore di migrazione trà i servitori, postu chì ùn ci sarà micca bisognu di trasfurmà l'almacenamiento lucale da un hypervisor à l'altru. L'unicu catch hè chì avete da piantà a VM mentre u travagliu hè realizatu.

A seguente ricetta hè presa da articulu da stu blog, l'istruzzioni di quale sò stati pruvati in azzione. A propositu, lu mètudu di migrazzioni senza hassle hè dinù discrittu ci, in ogni casu, in u nostru casu, era simplicemente micca necessariu, perchè ùn avemu micca verificatu. Se questu hè criticu per u vostru prughjettu, seremu cuntenti di sente i risultati in i cumenti.

Passemu à a parte pratica. In l'esempiu avemu usatu virsh è, per quessa, libvirt. Prima, assicuratevi chì a piscina Ceph à quale i dati seranu migrati hè cunnessu à libvirt:

virsh pool-dumpxml $ceph_pool

A descrizzione di a piscina deve cuntene dati di cunnessione à Ceph cù dati d'autorizazione.

U prossimu passu hè chì l'imagine LVM hè cunvertita in Ceph RBD. U tempu di esecuzione dipende principalmente da a dimensione di l'imaghjini:

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

Dopu a cunversione, una maghjina LVM resta, chì serà utile se a migrazione di a VM à RBD falla è avete da rinvià i cambiamenti. Inoltre, per pudè ritruvà rapidamente i cambiamenti, facemu una copia di salvezza di u schedariu di cunfigurazione di a macchina virtuale:

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

... è edità l'uriginale (vm_name.xml). Truvemu un bloccu cù una descrizzione di u discu (accumincia cù a linea <disk type='file' device='disk'> è finisce cù </disk>) è riducelu à a 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>

Fighjemu qualchi dettagli:

1. À u protocolu source l'indirizzu à l'almacenamiento in Ceph RBD hè indicatu (questu hè l'indirizzu chì indica u nome di a piscina Ceph è l'imaghjina RBD, chì hè stata determinata in u primu stadiu).
2. In u bloccu secret tipu hè indicatu ceph, è ancu l'UUID di u sicretu per cunnette à questu. U so uuid pò esse truvatu cù u cumandimu virsh secret-list.
3. In u bloccu host indirizzi à i monitor Ceph sò indicati.

Dopu avè editatu u schedariu di cunfigurazione è cumpletu a cunversione LVM à RBD, pudete applicà u schedariu di cunfigurazione mudificatu è inizià a macchina virtuale:

virsh define $vm_name.xml
virsh start $vm_name

Hè u tempu di verificà chì a macchina virtuale hà iniziatu currettamente: pudete scopre, per esempiu, cunnettendu cù ella via SSH o via virsh.

Se a macchina virtuale funziona bè è ùn avete micca trovu altri prublemi, pudete sguassà l'imaghjini LVM chì ùn hè più utilizatu:

lvremove main/$vm_image_name

cunchiusioni

Avemu scontru tutti i casi descritti in pratica - speremu chì l'istruzzioni aiutanu à altri amministratori à risolve prublemi simili. Sì avete cumenti o altre storie simili da a vostra sperienza cù Ceph, seremu felici di vedeli in i cumenti!

PS

Leghjite puru nant'à u nostru blog:

• «E nostre mani ùn sò micca per noia: restaurà u cluster Rook in K8s";
• «À Rook o micca à Rook - questa hè a quistione";
• «Rook - magazzinu di dati "self-service" per Kubernetes";
• «Crià un almacenamentu persistente cù a pruvista in Kubernetes basatu in Ceph».

Source: www.habr.com