Folosind Ceph ca stocare de rețea în proiecte cu încărcări diferite, este posibil să întâlnim diverse sarcini care la prima vedere nu par simple sau banale. De exemplu:
- migrarea datelor de la vechiul Ceph la unul nou cu utilizarea parțială a serverelor anterioare din noul cluster;
- soluție la problema alocării spațiului pe disc în Ceph.
Confruntându-ne cu astfel de probleme, ne confruntăm cu necesitatea de a elimina corect OSD-ul fără a pierde date, ceea ce este deosebit de important atunci când avem de-a face cu cantități mari de date. Acest lucru va fi discutat în articol.
Metodele descrise mai jos sunt relevante pentru orice versiune de Ceph. În plus, se va ține cont de faptul că Ceph poate stoca o cantitate mare de date: pentru a preveni pierderea datelor și alte probleme, unele acțiuni vor fi „împărțite” în altele.
Prefață despre OSD
Deoarece două dintre cele trei rețete discutate sunt dedicate OSD (), înainte de a te scufunda în partea practică - pe scurt despre ce este în Ceph și de ce este atât de important.
În primul rând, trebuie spus că întregul cluster Ceph este format din multe OSD-uri. Cu cât sunt mai multe, cu atât este mai mare volumul de date gratuite în Ceph. E ușor de înțeles de aici funcția principală OSD: stochează datele obiectului Ceph în sistemele de fișiere ale tuturor nodurilor cluster și oferă acces la rețea la acestea (pentru citire, scriere și alte solicitări).
La același nivel, parametrii de replicare sunt stabiliți prin copierea obiectelor între diferite OSD-uri. Și aici puteți întâlni diverse probleme, ale căror soluții vor fi discutate mai jos.
Cazul nr. 1. Eliminați în siguranță OSD din clusterul Ceph fără a pierde date
Necesitatea de a elimina OSD-ul poate fi cauzată de eliminarea serverului din cluster - de exemplu, pentru a-l înlocui cu un alt server - ceea ce ni s-a întâmplat, dând naștere la scrierea acestui articol. Astfel, scopul final al manipulării este de a extrage toate OSD-urile și monurile de pe un anumit server, astfel încât acesta să poată fi oprit.
Pentru comoditate și pentru a evita o situație în care facem o greșeală în specificarea OSD-ului necesar în timpul executării comenzilor, vom seta o variabilă separată, a cărei valoare va fi numărul OSD-ului de șters. Să o sunăm ${ID} — aici și mai jos, o astfel de variabilă înlocuiește numărul OSD-ului cu care lucrăm.
Să ne uităm la starea înainte de a începe lucrul:
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 trebui să efectuați fără probleme reweight pe ea la zero. În acest fel, reducem cantitatea de date din OSD, echilibrând-o cu alte OSD-uri. Pentru a face acest lucru, executați următoarele comenzi:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... si tot asa pana la zero.
Este necesară o echilibrare linăpentru a nu pierde date. Acest lucru este valabil mai ales dacă OSD-ul conține o cantitate mare de date. Pentru a vă asigura că după executarea comenzilor reweight totul a mers bine, îl poți finaliza ceph -s sau într-o fereastră de terminal separată ceph -w pentru a observa schimbările în timp real.
Când OSD-ul este „golit”, puteți continua cu operația standard pentru a-l elimina. Pentru a face acest lucru, transferați OSD-ul dorit în stare down:
ceph osd down osd.${ID}Să „tragem” OSD-ul din cluster:
ceph osd out osd.${ID}Să oprim serviciul OSD și să-i demontăm partiția în FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Eliminați OSD din :
ceph osd crush remove osd.${ID}Să ștergem utilizatorul OSD:
ceph auth del osd.${ID}Și, în sfârșit, să eliminăm OSD-ul în sine:
ceph osd rm osd.${ID}Nota: Dacă utilizați versiunea Ceph Luminous sau o versiune superioară, atunci pașii de eliminare a OSD de mai sus pot fi reduse la două comenzi:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Dacă, după parcurgerea pașilor descriși mai sus, rulați comanda ceph osd tree, atunci trebuie să fie clar că pe serverul unde s-a efectuat munca nu mai există OSD-uri pentru care s-au efectuat operațiunile de mai sus:
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
Pe parcurs, rețineți că starea clusterului Ceph va ajunge HEALTH_WARN, și vom observa, de asemenea, o scădere a numărului de OSD-uri și a cantității de spațiu disponibil pe disc.
Următoarele vor descrie pașii care vor fi necesari dacă doriți să opriți complet serverul și, în consecință, să îl eliminați din Ceph. În acest caz, este important să rețineți că Înainte de a închide serverul, trebuie să eliminați toate OSD-urile pe acest server.
Dacă nu mai sunt OSD-uri rămase pe acest server, atunci după ce le-ați eliminat, trebuie să excludeți serverul din harta OSD hv-2rulând următoarea comandă:
ceph osd crush rm hv-2
Șterge mon de pe server hv-2rulând comanda de mai jos pe alt server (adică, în acest caz, pe hv-1):
ceph-deploy mon destroy hv-2După aceasta, puteți opri serverul și puteți începe acțiunile ulterioare (re-implementarea acestuia etc.).
Cazul nr. 2. Distribuția spațiului pe disc într-un cluster Ceph deja creat
Voi începe a doua poveste cu o prefață despre PG (). Rolul principal al PG în Ceph este în primul rând de a agrega obiecte Ceph și de a le replica în continuare în OSD. Formula cu care puteți calcula cantitatea necesară de PG este în documentație Ceph. Această problemă este de asemenea discutată acolo cu exemple specifice.
Deci: una dintre problemele frecvente atunci când utilizați Ceph este numărul dezechilibrat de OSD și PG între pool-uri în Ceph.
În primul rând, din această cauză, poate apărea o situație când sunt specificate prea multe PG-uri într-un pool mic, ceea ce este în esență o utilizare irațională a spațiului pe disc din cluster. În al doilea rând, în practică există o problemă mai serioasă: depășirea datelor într-unul dintre OSD-uri. Aceasta implică prima tranziție a clusterului la stat HEALTH_WARN, și apoi HEALTH_ERR. Motivul pentru aceasta este că Ceph, atunci când calculează cantitatea disponibilă de date (o puteți afla prin MAX AVAIL în ieșirea comenzii ceph df pentru fiecare grup separat) se bazează pe cantitatea de date disponibile în OSD. Dacă nu există suficient spațiu în cel puțin un OSD, nu mai pot fi scrise date până când datele sunt distribuite corect între toate OSD-urile.
Merită să lămurim că aceste probleme sunt în mare măsură decise în etapa de configurare a clusterului Ceph. Unul dintre instrumentele pe care le puteți folosi este . Cu ajutorul acestuia, cantitatea necesară de PG este calculată în mod clar. Cu toate acestea, puteți recurge la el și într-o situație în care clusterul Ceph deja configurat incorect. Merită să clarificăm aici că, ca parte a lucrării de remediere, cel mai probabil va trebui să reduceți numărul de PG-uri, iar această caracteristică nu este disponibilă în versiunile mai vechi de Ceph (a apărut doar în versiunea ).
Deci, să ne imaginăm următoarea imagine: clusterul are o stare HEALTH_WARN din cauza unuia dintre OSD rămâne fără spațiu. Acest lucru va fi indicat printr-o eroare HEALTH_WARN: 1 near full osd. Mai jos este un algoritm pentru a ieși din această situație.
În primul rând, trebuie să distribuiți datele disponibile între OSD-urile rămase. Am efectuat deja o operație similară în primul caz, când am „drenat” nodul - cu singura diferență că acum va trebui să reducem ușor reweight. De exemplu, până la 0.95:
ceph osd reweight osd.${ID} 0.95Acest lucru eliberează spațiu pe disc în OSD și remediază eroarea de sănătate ceph. Cu toate acestea, așa cum am menționat deja, această problemă apare în principal din cauza configurării incorecte a Ceph în fazele inițiale: este foarte important să faceți o reconfigurare, astfel încât să nu apară în viitor.
În cazul nostru particular, totul s-a rezumat la:
- valoare prea mare
replication_countîntr-una din piscine, - prea mult PG într-un bazin și prea puțin în altul.
Să folosim calculatorul deja menționat. Arată clar ce trebuie introdus și, în principiu, nu este nimic complicat. După setarea parametrilor necesari, primim următoarele recomandări:
Nota: Dacă configurați un cluster Ceph de la zero, o altă funcție utilă a calculatorului este generarea de comenzi care vor crea pool-uri de la zero cu parametrii specificați în tabel.
Ultima coloană vă ajută să navigați - Număr PG sugerat. În cazul nostru, este util și al doilea, unde este indicat parametrul de replicare, deoarece am decis să schimbăm multiplicatorul de replicare.
Deci, mai întâi trebuie să modificați parametrii de replicare - mai întâi merită să faceți acest lucru, deoarece prin reducerea multiplicatorului, vom elibera spațiu pe disc. Pe măsură ce comanda se execută, veți observa că spațiul disponibil pe disc va crește:
ceph osd pool $pool_name set $replication_size
Și după finalizarea acestuia, schimbăm valorile parametrilor pg_num и pgp_num după cum urmează:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberEste important: trebuie sa schimbam numarul de PG-uri secvential in fiecare pool si sa nu schimbam valorile in alte pool-uri pana cand avertismentele dispar „Redundanță degradată a datelor” и „n-număr de pagini degradate”.
De asemenea, puteți verifica dacă totul a mers bine folosind ieșirile comenzii ceph health detail и ceph -s.
Cazul nr. 3. Migrarea unei mașini virtuale de la LVM la Ceph RBD
Într-o situație în care un proiect utilizează mașini virtuale instalate pe servere bare-metal închiriate, apare adesea problema stocării tolerante la erori. De asemenea, este foarte de dorit să existe suficient spațiu în acest spațiu de stocare... O altă situație comună: există o mașină virtuală cu stocare locală pe server și trebuie să extindeți discul, dar nu există unde să mergeți, deoarece nu există spațiu liber pe disc rămas pe server.
Problema poate fi rezolvată în diferite moduri - de exemplu, migrând pe un alt server (dacă există unul) sau adăugând noi discuri pe server. Dar nu este întotdeauna posibil să faceți acest lucru, așa că migrarea de la LVM la Ceph poate fi o soluție excelentă la această problemă. Alegând această opțiune, simplificăm și procesul ulterioar de migrare între servere, deoarece nu va fi nevoie să mutați stocarea locală de la un hypervisor la altul. Singura captură este că va trebui să opriți VM-ul în timp ce lucrarea se desfășoară.
Următoarea rețetă este luată din , ale căror instrucțiuni au fost testate în acțiune. Apropo, acolo este descrisă și metoda de migrare fără probleme, cu toate acestea, în cazul nostru pur și simplu nu era nevoie, așa că nu l-am verificat. Dacă acest lucru este critic pentru proiectul dvs., vom fi bucuroși să aflăm despre rezultate în comentarii.
Să trecem la partea practică. În exemplu folosim virsh și, în consecință, libvirt. Mai întâi, asigurați-vă că pool-ul Ceph la care vor fi migrate datele este conectat la libvirt:
virsh pool-dumpxml $ceph_poolDescrierea pool-ului trebuie să conțină date de conectare la Ceph cu date de autorizare.
Următorul pas este ca imaginea LVM să fie convertită î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_nameDupă conversie, va rămâne o imagine LVM, care va fi utilă dacă migrarea VM-ului la RBD eșuează și trebuie să anulați modificările. De asemenea, pentru a putea anula rapid modificările, să facem o copie de rezervă a fișierului de configurare a mașinii virtuale:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... și editați originalul (vm_name.xml). Să găsim un bloc cu o descriere a discului (începe cu linia <disk type='file' device='disk'> si se termina cu </disk>) și reduceți-l la următoarea formă:
<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>Să ne uităm la câteva detalii:
- La protocol
sourceeste indicată adresa depozitului din Ceph RBD (aceasta este adresa care indică numele pool-ului Ceph și imaginea RBD, care a fost determinată în prima etapă). - În bloc
secreteste indicat tipulceph, precum și UUID-ul secretului pentru a vă conecta la acesta. Uuid-ul său poate fi găsit folosind comandavirsh secret-list. - În bloc
hostsunt indicate adresele către monitoare Ceph.
După editarea fișierului de configurare și finalizarea conversiei LVM în RBD, puteți aplica fișierul de configurare modificat și porniți mașina virtuală:
virsh define $vm_name.xml
virsh start $vm_name
Este timpul să verificați dacă mașina virtuală a pornit corect: puteți afla, de exemplu, conectându-vă la ea prin SSH sau prin virsh.
Dacă mașina virtuală funcționează corect și nu ați găsit alte probleme, atunci puteți șterge imaginea LVM care nu mai este utilizată:
lvremove main/$vm_image_nameConcluzie
Am întâlnit toate cazurile descrise în practică - sperăm că instrucțiunile vor ajuta alți administratori să rezolve probleme similare. Dacă aveți comentarii sau alte povești similare din experiența dvs. de utilizare a Ceph, vom fi bucuroși să le vedem în comentarii!
PS
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com