🥇 Sfaturi și trucuri în utilizarea Ceph în proiecte aglomerate

Folosind Ceph ca stocare în rețea în diferite proiecte cu nivele de încărcare variate, ne putem confrunta cu diverse provocări care, la prima vedere, nu par simple sau triviale. De exemplu:

migrarea datelor din Ceph vechi în noul Ceph cu utilizarea parțială a serverelor anterioare în noul cluster;
rezolvarea problemei distribuției spațiului pe disc în Ceph.

Când ne confruntăm cu astfel de provocări, întâlnim necesitatea de a extrage corect OSD fără pierderi de date, ceea ce este deosebit de important în cazul unor volume mari de date. Despre aceasta va fi vorba în articol.

Metodele descrise mai jos sunt relevante pentru toate versiunile Ceph. În plus, se va lua în considerare faptul că Ceph poate stoca o cantitate mare de date: pentru a preveni pierderile de date și alte probleme, unele acțiuni vor fi „fragmentate” în mai multe altele.

Introducere despre OSD

Având în vedere că două din cele trei rețete discutate se concentrează pe OSD (Object Storage Daemon), înainte de a intra în partea practică — o scurtă prezentare a ceea ce reprezintă acest element în Ceph și de ce este atât de important.

În primul rând, trebuie să spunem că întregul cluster Ceph este format din numeroase OSD-uri. Cu cât sunt mai multe, cu atât mai mult spațiu liber pentru date în Ceph. De aici este ușor de înțeles funcția principală a OSD: el stochează datele obiectelor Ceph pe sistemele de fișiere ale tuturor nodurilor din cluster și oferă acces în rețea la acestea (pentru citire, scriere și alte cereri).

La acest nivel se stabilesc și parametrii de replicare prin copierea obiectelor între diferitele OSD-uri. Aici pot apărea diverse probleme, despre soluționarea cărora vom discuta mai departe.

Cazul nr. 1. Extracția sigură a OSD din clusterul Ceph fără pierderi de date

Necesitatea de a extrage un OSD poate fi generată de scoaterea serverului din cluster — de exemplu, pentru a-l înlocui cu un alt server — ceea ce s-a întâmplat și în cazul nostru, motiv pentru care am redactat acest articol. Astfel, scopul final al acțiunilor este de a extrage toate OSD-urile și mon-urile de pe acest server, astfel încât să poată fi oprit.

Pentru a ușura lucrul și a evita o situație în care, în timpul executării comenzilor, am greșit cu specificarea OSD-ului dorit, vom defini o variabilă separată, a cărei valoare va fi numărul OSD-ului care urmează să fie eliminat. O vom numi ${ID} — aici și mai departe, această variabilă va înlocui numărul OSD-ului cu care lucrăm.

Să vedem starea înainte de a începe lucrările:

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

Pentru a iniția eliminarea OSD, va fi necesar să executăm treptat reweight pe acesta până la zero. Astfel, reducem cantitatea de date din OSD prin balansarea în alte OSD. Pentru aceasta se execută comenzile următoare:

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

… și așa mai departe, până la zero.

Balansarea treptată este necesară, pentru a nu pierde date. Acest lucru este deosebit de important dacă OSD conține un volum mare de date. Pentru a ne asigura că, după executarea comenzilor reweight totul a decurs cu succes, putem executa ceph -s sau putem lansa într-o fereastră separată de terminal ceph -w pentru a observa schimbările în timp real.

Când OSD este „golit”, putem începe operația standard de eliminare a acestuia. Pentru aceasta, vom schimba OSD-ul dorit în starea down:

ceph osd down osd.${ID}

„Scoatem” OSD-ul din cluster:

ceph osd out osd.${ID}

Oprind serviciul OSD și demontăm partiția sa din FS:

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

Eliminăm OSD din CRUSH map:

ceph osd crush remove osd.${ID}

Eliminăm utilizatorul OSD:

ceph auth del osd.${ID}

Și, în final, eliminăm însăși OSD-ul:

ceph osd rm osd.${ID}

Notă: dacă folosiți versiunea Ceph Luminous sau o versiune superioară, atunci acțiunile descrise mai sus pentru eliminarea OSD pot fi reduse la două comenzi:

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

Dacă după executarea acțiunilor menționate anterior executați comanda ceph osd tree, ar trebui să fie vizibil că pe serverul pe care s-au efectuat lucrările nu mai există OSD-uri pentru care s-au executat operațiunile anterioare:

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

Între timp, să observăm că starea clusterului Ceph va trece în HEALTH_WARN, de asemenea, vom observa o reducere a numărului de OSD-uri și a volumului de spațiu de stocare disponibil.

Următoarele vor fi descrise acțiunile necesare dacă doriți să opriți complet serverul și, prin urmare, să-l eliminați din Ceph. În acest caz, este important să ne amintim că înainte de a opri serverul este necesar să scoateți toate OSD-urile de pe acest server.

Dacă pe acest server nu au mai rămas OSD-uri, atunci după eliminarea lor trebuie să excluzi din harta OSD serverul hv-2, executând următoarea comandă:

ceph osd crush rm hv-2

Ștergem mon de pe server hv-2, rulând comanda de mai jos pe un alt server (adică, în acest caz — pe hv-1):

ceph-deploy mon destroy hv-2

După aceasta, se poate opri serverul și se pot începe următoarele acțiuni (redistribuirea sa etc.).

Cazul nr. 2. Distribuția spațiului pe disc în clusterul Ceph deja creat

A doua poveste o voi începe cu o introducere despre PG (Placement Groups). Rolul principal al PG-ului în Ceph constă în agregarea obiectelor Ceph și replicația ulterioară în OSD. Formula prin care se poate calcula numărul necesar de PG-uri se află în secțiunea corespunzătoare din documentația Ceph. Acolo aceeași problemă este analizată și cu exemple concrete.

Așadar, una dintre problemele frecvente în timpul exploatării Ceph este numărul dezechilibrat de OSD și PG între pulle în Ceph.

În primul rând, din cauza aceasta, ar putea apărea o situație în care se specifică un număr prea mare de PG-uri într-un pool mic, ceea ce este o utilizare irațională a spațiului pe disc în cluster. În al doilea rând, în practică se dovedește o problemă mai serioasă: umplerea datelor într-unul dintre OSD-uri. Aceasta duce, mai întâi, la trecerea clusterului în starea HEALTH_WARN, și apoi la HEALTH_ERR. Totul se datorează faptului că Ceph, în calculul volumului de date disponibile (care poate fi aflat folosind MAX AVAIL în ieșirea comenzii ceph df pentru fiecare pool în parte) se bazează pe volumul de date disponibile în OSD. Dacă în cel puțin un OSD nu va fi suficient spațiu, atunci nu se vor putea scrie mai multe date, până nu vor fi redistribuite corect între toate OSD.

Este important de precizat că aceste probleme sunt, în mare parte, rezolvate în etapa de configurare a clusterului Ceph. Unul dintre instrumentele pe care le puteți utiliza este Ceph PGCalc. Acesta permite calcularea vizuală a numărului necesar de PG-uri. Cu toate acestea, poate fi folosit și în situația în care clusterul Ceph este deja configurat greșit. Aici trebuie menționat că, în cadrul lucrărilor de corectare, cel mai probabil va trebui să reduceți numărul de PG-uri, iar această posibilitate nu este disponibilă în versiunile mai vechi de Ceph (a apărut doar odată cu versiunea Nautilus).

Așadar, să ne imaginăm următoarea situație: clusterul are un statut HEALTH_WARN din cauza că în unul dintre OSD-uri se termină spațiul. Acest lucru va fi indicat de o eroare. AVERTIZARE_SĂNĂTATE: 1 aproape plin osd. Iată un algoritm pentru a ieși din această situație.

În primul rând, este necesară redistribuirea datelor existente între celelalte OSD-uri. O astfel de operațiune a fost deja efectuată în primul caz, când am „uscata” nodul — cu mențiunea că acum va fi nevoie să diminuăm ușor reweight. De exemplu, la 0.95:

ceph osd reweight osd.${ID} 0.95

Astfel, se eliberează spațiu pe disc în OSD și se corectează eroarea în ceph health. Totuși, așa cum s-a menționat anterior, această problemă apare în principal din cauza unei configurări incorecte a Ceph la început: este foarte important să facem reconstrucția pentru a nu se mai manifesta în viitor.

În cazul nostru specific, totul se reduce la:

o valoare prea mare replication_count în unul dintre pool-uri,
un număr prea mare de PG într-un pool și prea mic în altul.

Vom folosi deja menționat calculatorul. Acesta ilustrează clar ce trebuie introdus și, în principiu, nu este nimic complicat. Introducând parametrii necesari, obținem următoarele recomandări:

Notă: dacă configurați un cluster Ceph de la zero, o altă funcție utilă a calculatorului va fi generarea comenzilor care vor crea pool-uri de la zero cu parametrii specificați în tabel.

Ultima coloană ajută la orientare — Suggested PG Count. În cazul nostru, este utilă și a doua, care indică parametrul de replicare, deoarece am decis să schimbăm și faktorul de replicare.

Așadar, mai întâi va trebui să modificăm parametrii de replicare - acest lucru trebuie făcut în primul rând, deoarece, reducând factorul, vom elibera spațiu pe disc. În timpul execuției comenzii, se poate observa că valoarea spațiului pe disc disponibil va crește:

ceph osd pool $pool_name set $replication_size

Iar după finalizarea acesteia - modificăm valorile parametrilor pg_num și pgp_num în următorul mod:

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

Este important: trebuie să modificăm în mod consecutiv numărul de PG în fiecare pool și să nu schimbăm valorile din celelalte pool-uri până la dispariția avertismentelor «Degraded data redundancy» și «n-number of pgs degraded».

Verificarea că totul a decurs cu succes poate fi, de asemenea, realizată prin rezultatele comenzilor ceph health detail și ceph -s.

Caz Nr. 3. Migrarea unei mașini virtuale de la LVM la Ceph RBD

În situații în care un proiect utilizează mașini virtuale instalate pe servere bare-metal închiriate, apare adesea întrebarea legată de stocarea redundantă. De asemenea, este foarte de dorit ca acest spațiu de stocare să fie suficient… O altă situație frecvent întâlnită: există o mașină virtuală cu stocare locală pe server și trebuie extins discul, dar nu există spațiu liber pe server.

Problema poate fi rezolvată în diferite moduri — de exemplu, prin migrarea pe un alt server (dacă există) sau prin adăugarea de noi discuri pe server. Dar nu întotdeauna reușim să facem acest lucru, de aceea migrarea din LVM în Ceph poate fi o soluție excelentă. Alegând această opțiune, simplificăm și procesul viitor de migrare între servere, deoarece nu va fi nevoie să mutăm stocarea locală de pe un hypervizor pe altul. Singura problemă este că va trebui să oprim VM-ul pe durata lucrărilor.

Ca rețetă propusă mai departe, un articol de pe acest blog, ale cărui instrucțiuni au fost testate în practică. Apropo, acolo este descris și un mod de migrare fără întreruperi, dar în cazul nostru nu a fost necesar, așa că nu l-am verificat. Dacă aceasta este critică pentru proiectul dumneavoastră — am fi bucuroși să aflăm rezultatele în comentarii.

Să trecem la partea practică. În exemplu, folosim virsh și, în consecință, libvirt. Pentru început, asigurați-vă că pool-ul Ceph, în care vor fi migrate datele, este conectat la libvirt:

virsh pool-dumpxml $ceph_pool

În descrierea pool-ului ar trebui să existe datele de conectare la Ceph cu informații pentru autorizare.

Următoarea etapă constă în conversia imaginii LVM în Ceph RBD. Timpul de execuție depinde în primul rând de dimensiunea imaginii:

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

După conversie, va rămâne o imagine LVM, care va fi utilă în cazul în care migrarea VM-ului în RBD nu va reuși și va fi nevoie să revenim la starea anterioară. De asemenea, pentru a avea posibilitatea de a reveni rapid la modificări, vom face un backup al fișierului de configurație al mașinii virtuale:

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

… și vom edita originalul (vm_name.xml). Vom găsi blocul cu descrierea discului (începe cu linia <disk type='file' device='disk'> și se termină cu </disk>) și îl vom aduce la următoarea formă:

Să analizăm câteva detalii:

În protocolul source se specifică adresa către stocarea din Ceph RBD (aceasta este adresa care include numele pool-ului Ceph și imaginea RBD, care au fost definite în prima etapă).
În blocul secret se indică tipul ceph, precum și UUID-ul secretului pentru conectare la acesta. UUID-ul său poate fi obținut folosind comanda virsh secret-list.
În blocul host se specifică adresele monitorilor Ceph.

După editarea fișierului de configurație și finalizarea conversiei LVM în RBD, se poate aplica fișierul de configurație modificat și se poate porni mașina virtuală:

virsh define $vm_name.xml
virsh start $vm_name

Este momentul să verificăm dacă mașina virtuală a pornit corect: acest lucru poate fi verificat, de exemplu, conectându-se la ea prin SSH sau prin virsh.

Dacă mașina virtuală funcționează corect și nu ați descoperit alte probleme, atunci puteți șterge imaginea LVM, care nu mai este utilizată:

lvremove main/$vm_image_name

Concluzie

Cu toate cazurile descrise, ne-am confruntat în practică — sperăm că instrucțiunile vor ajuta și alți administratori să rezolve probleme similare. Dacă aveți observații sau alte povești similare din experiența utilizării Ceph — ne-ar face plăcere să le vedem în comentarii!