Remediați în siguranță problema de aprovizionare subțire SUSE Linux Enterprise LVM fără spațiu

Ce ar trebui să stabilești înainte de a schimba ceva?

Mai întâi, determinați dacă pool-ul subțire a epuizat spațiul de date , spațiul de metadate sau ambele. Această distincție modifică planul de recuperare. Un pool subțire conține un LV de date care stochează blocurile alocate și un LV de metadate care urmărește aceste alocări. Dimensiunea virtuală a volumelor logice subțiri poate depăși capacitatea fizică a pool-ului, acesta fiind scopul aprovizionării subțiri, dar și motivul pentru care supraangajarea trebuie monitorizată.

Documentația SUSE Linux Enterprise Server 15 SP7 confirmă faptul că volumele subțiri alocă spațiu dintr-un pool subțire la cerere și că dimensiunea virtuală combinată poate suprasolicita spațiul de stocare fizic disponibil. Documentația pool-ului subțire LVM din amonte adaugă o regulă operațională importantă: extindeți pool-ul înainte ca fie să Data%fie Meta%să atingă 100%. Consultați Ghidul de administrare a stocării SUSE Linux Enterprise Server 15 SP7 și manualul de furnizare subțire LVM .

1. Este spațiul de date plin sau sunt metadatele pline?

Rulează lvscu coloane explicite în loc să te bazezi pe o verificare generică a spațiului pe disc. Un sistem de fișiere poate raporta în continuare spațiu virtual liber în timp ce pool-ul fizic subțire de sub el este aproape epuizat.

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent

Legendă: Pool-ul subțire trebuie identificat prin valorile sale Data% și Meta%; spațiul liber din sistemul de fișiere nu indică în sine epuizarea fizică a pool-ului subțire.

Dacă Data%valoarea este la sau aproape de 100, înseamnă că pool-ul de date nu mai are blocuri pentru scrieri noi. Documentația LVM din amonte avertizează că scrierile pot returna erori atunci când pool-ul de date este epuizat, ceea ce poate deteriora sistemele de fișiere. Dacă Meta%valoarea ajunge la 100, răspunsul este mai conservator, deoarece epuizarea metadatelor poate lăsa atât metadatele pool-ului subțire, cât și sistemele de fișiere inconsistente.

2. Mai are grupul de volume extensii fizice libere?

Acesta este următorul punct de decizie. Un pool subțire poate crește doar dacă grupul său de volume are extensii libere, cu excepția cazului în care adăugați mai întâi mai mult spațiu de stocare fizic la grupul de volume respectiv.

vgs -o vg_name,vg_size,vg_free
vgdisplay VG_NAME

Legendă: Verificarea spațiului liber VG separă o extensie simplă thin-pool de o carcasă care necesită adăugarea mai întâi a spațiului de stocare.

Dacă VG are suficient spațiu liber, de obicei puteți extinde direct thin pool-ul. Dacă VFreeeste zero sau prea mic, nu reîncercați lvextend; decideți dacă puteți elimina volumele thin sau snapshot-urile inutile, recupera blocuri cu discard sau adăuga un volum fizic nou.

3. Ar trebui să opriți aplicațiile înainte de recuperare?

Dacă pool-ul este deja la 100%, opriți sau puneți în inactivitate aplicațiile cu volum mare de scriere înainte de a face modificări la spațiul de stocare. Acest lucru reduce șansa ca bazele de date, mașinile virtuale, containerele sau alte servicii să continue să emită scrieri în timp ce stratul de stocare se defectează sau este reparat.

systemctl stop YOUR_APPLICATION.service
systemctl status YOUR_APPLICATION.service

Legendă: Punerea în repaus a aplicațiilor limitează scrierile suplimentare în timp ce se recuperează un pool subțire plin sau deteriorat.

Nu există o listă universală de servicii care trebuie oprite. Folosește arhitectura sarcinii de lucru și procedurile de întreținere. Pentru bazele de date și mașinile virtuale, preferă metoda de oprire sau suspendare acceptată de produs, în loc să oprești brusc procesele.

4. Dacă Data% este plin și VG are spațiu liber, cum extinzi pool-ul?

Extindeți pool-ul subțire în sine, nu LV-ul subțire virtual, deoarece problema este lipsa capacității pool-ului fizic. De exemplu:

lvextend -L +20G VG_NAME/THIN_POOL
lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent VG_NAME/THIN_POOL

Legendă: Extinderea pool-ului subțire adaugă capacitate fizică; procentul de date rezultat ar trebui să scadă odată ce noul spațiu devine disponibil.

Manualul lvextend documentează extensia directă a pool-ului subțire și --poolmetadatasizeopțiunea separată pentru metadate. Alegeți un increment bazat pe rata reală de creștere și pe capacitatea de stocare pe care o puteți rezerva. Un exemplu fix, cum ar fi +20Gnu este o recomandare de dimensionare pentru fiecare sistem.

5. Ce se întâmplă dacă grupul de volume nu are spațiu liber?

Adăugați spațiu de stocare numai după ce confirmați că dispozitivul bloc țintă este neutilizat și nu conține datele de care aveți nevoie. Crearea unui volum fizic LVM scrie metadatele LVM pe dispozitivul selectat, astfel încât o greșeală de nume a dispozitivului poate fi distructivă.

lsblk
blkid

pvcreate /dev/NEW_DEVICE
vgextend VG_NAME /dev/NEW_DEVICE
vgs -o vg_name,vg_size,vg_free

Legendă: Când VG este plin, se poate adăuga mai întâi spațiu de stocare fizic nou, după ce administratorul verifică dispozitivul corect neutilizat.

SUSE documentează că grupurile de volume pot fi extinse prin adăugarea de partiții sau discuri întregi. Verificați topologia de stocare înainte de a face acest lucru pe sisteme multipath, SAN, RAID, criptate, clusterizate sau bazate pe cloud, deoarece stratul corect de dispozitiv poate să nu fie discul brut prezentat într-un exemplu simplu.

6. Ce se întâmplă dacă Meta% ajunge la 100%?

Tratați epuizarea metadatelor ca pe un caz de reparare offline, mai degrabă decât să adăugați doar capacitate de date. Manualul LVM pentru pool-uri subțiri precizează explicit că epuizarea metadatelor poate cauza metadate și sisteme de fișiere inconsistente pentru pool-urile subțiri. Secvența de recuperare documentată este dezactivarea pool-ului, repararea acestuia cu lvconvert --repair, extinderea metadatelor și apoi verificarea sistemului de fișiere.

După oprirea aplicațiilor, demontați sistemele de fișiere sau dezactivați în alt mod LV-urile subțiri folosind pool-ul. Apoi, urmați o procedură de mentenanță controlată similară cu:

lvchange -an VG_NAME/THIN_LV
lvconvert --repair VG_NAME/THIN_POOL
lvextend --poolmetadatasize +1G VG_NAME/THIN_POOL

Legendă: O condiție de metadate complete necesită repararea pool-ului subțire offline și spațiu suplimentar pentru metadate, nu doar mai multe extensii de date.

Figura +1Geste doar un exemplu. Dimensionarea metadatelor depinde de dimensiunea pool-ului, dimensiunea chunk-ului, utilizarea snapshot-ului și comportamentul de alocare. După reparare, inspectați jurnalele de sistem și utilizați procedura de verificare sau reparare specifică sistemului de fișiere dacă au apărut erori I/O. Nu rulați orbește un instrument de reparare a sistemului de fișiere pe un sistem de fișiere montat.

Poate ștergerea fișierelor elibera imediat un pool subțire?

Nu întotdeauna. Ștergerea unui fișier eliberează spațiu în sistemul de fișiere, dar pool-ul subțire recuperează blocuri fizice doar atunci când informațiile despre eliminare ajung în pool. Documentația LVM menționează că fstrimastfel de blocuri pot fi recuperate, în timp ce snapshot-urile pot continua să facă referire la blocuri și să le împiedice să devină eliberate. Dacă pool-ul este configurat să ignore informațiile eliminate, funcția trim nu va recupera blocurile.

Când sistemul de fișiere și sarcina de lucru o acceptă, verificați comportamentul de eliminare și efectuați decuparea numai după ce pool-ul este suficient de stabil pentru a funcționa:

lvs -o lv_name,discards VG_NAME/THIN_POOL
fstrim -v /mount/point

Ștergerea instantaneelor ​​subțiri vechi poate elibera și spațiu de stocare atunci când aceste instantanee reprezintă referințele rămase la blocuri. Verificați cerințele de backup și păstrare înainte de a șterge instantaneele.

7. Cum previi ca acest lucru să se mai întâmple?

Activați și verificați monitorizarea pool-ului subțire LVM și configurați extensia automată cu suficientă capacitate liberă în VG. LVM în amonte folosește dmeventd, de obicei prin lvm2-monitorserviciu, pentru a reacționa atunci când utilizarea datelor sau metadatelor depășește pragul configurat.

systemctl status lvm2-monitor.service
lvs -o+seg_monitor VG_NAME/THIN_POOL
lvchange --monitor y VG_NAME/THIN_POOL

lvmconfig --type full activation/thin_pool_autoextend_threshold
lvmconfig --type full activation/thin_pool_autoextend_percent

Legendă: Extinderea automată depinde de monitorizarea activă, un prag adecvat și extensiile libere rămase în grupul de volume.

Manualul LVM precizează că un prag de 100 dezactivează extensia automată și că pragul minim valid este de 50. Un prag mai mic oferă LVM mai mult timp pentru a reacționa la pool-urile cu rate de scriere foarte rapide. Procentul de extensie determină cât de mult crește pool-ul atunci când politica este declanșată.

O configurație reprezentativă ar /etc/lvm/lvm.confputea fi:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Aceste valori sunt exemple, nu valori implicite universale. Dimensionați marja de siguranță în funcție de rata de scriere în rafale, intervalul de monitorizare, timpul de așteptare pentru furnizarea spațiului de stocare și spațiul liber disponibil pe VG. Extensia automată nu poate ajuta dacă VG-ul în sine este deja plin.

8. De unde știi că recuperarea a funcționat cu adevărat?

Verificați mai multe semnale. Pool-ul ar trebui să aibă spațiu liber, VG-ul ar trebui să aibă suficient spațiu liber pentru creșterea așteptată, aplicațiile ar trebui să poată scrie normal, iar jurnalele nu ar trebui să afișeze erori continue de I/O sau metadate în pool-ul subțire.

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
vgs -o vg_name,vg_size,vg_free
journalctl -u lvm2-monitor.service --since "30 minutes ago"

Legendă: Recuperarea este confirmată atunci când utilizarea pool-ului are spațiu liber, VG păstrează spațiu liber utilizabil, iar monitorizarea nu raportează erori I/O continue.

Reporniți aplicațiile treptat și urmăriți pool-ul subțire în timp ce volumul de lucru real revine. Dacă Data%crește din nou neobișnuit de rapid, extinderea pool-ului ar fi putut rezolva întreruperea imediată fără a rezolva problema planificării capacității.

Când ar trebui să te oprești și să folosești o altă cale de recuperare?

Ce ar trebui să eviți?

• Nu presupuneți că df -hdovedește că un pool subțire are spațiu de stocare fizic gratuit.
• Nu inițializați un dispozitiv nou pvcreatepână când nu l-ați identificat cu certitudine ca neutilizat.
• Nu tratați epuizarea metadatelor ca pe aceeași problemă ca epuizarea obișnuită a datelor.
• Nu vă bazați pe extensia automată fără a rezerva extensii libere în VG.
• Nu executați comenzi de reparare a sistemului de fișiere împotriva sistemelor de fișiere montate, cu excepția cazului în care furnizorul sistemului de fișiere acceptă în mod explicit această operațiune.
• Nu dezactivați monitorizarea doar pentru a suprima avertismentele; avertismentul este adesea ultima oportunitate de a extinde pool-ul înainte ca scrierile să eșueze.

Referințe oficiale și primare

• Ghid de administrare a stocării SUSE Linux Enterprise Server 15 SP7
• Documentația SUSE SLES 15 SP7 Expert Partitioner
• Manual de furnizare subțire LVM
• Manualul LVM lvextend