Risolvere in modo sicuro il problema di spazio esaurito nel thin provisioning LVM di SUSE Linux Enterprise

Cosa bisogna valutare prima di apportare qualsiasi modifica?

Innanzitutto, bisogna determinare se il thin pool ha esaurito lo spazio dati , lo spazio metadati o entrambi. Questa distinzione modifica il piano di ripristino. Un thin pool contiene un volume logico (LV) dati che memorizza i blocchi allocati e un volume logico metadati che tiene traccia di tali allocazioni. La dimensione virtuale dei volumi logici thin può superare la capacità fisica del pool, che è lo scopo del thin provisioning ma anche il motivo per cui è necessario monitorare l'overcommit.

La documentazione di SUSE Linux Enterprise Server 15 SP7 conferma che i volumi thin allocano spazio da un thin pool su richiesta e che la dimensione virtuale combinata può superare la capacità di archiviazione fisica disponibile. La documentazione LVM thin-pool a monte aggiunge un'importante regola operativa: estendere il pool prima Data%che uno dei due valori Meta%raggiunga il 100%. Consultare la Guida all'amministrazione dello storage di SUSE Linux Enterprise Server 15 SP7 e il manuale di thin provisioning LVM .

1. Lo spazio dedicato ai dati è esaurito o lo spazio dedicato ai metadati è esaurito?

Esegui l'esecuzione lvscon colonne esplicite anziché affidarti a un controllo generico dello spazio su disco. Un filesystem può comunque segnalare spazio virtuale libero anche se il thin pool fisico sottostante è quasi esaurito.

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

Didascalia: Il thin pool deve essere identificato dai suoi valori Data% e Meta%; il solo spazio libero del filesystem non indica l'esaurimento fisico del thin pool.

Se Data%il valore è pari o vicino a 100, il pool ha esaurito i blocchi disponibili per nuove scritture. La documentazione LVM ufficiale avverte che le scritture possono generare errori quando il pool di dati è esaurito, il che a sua volta può danneggiare i filesystem. Se Meta%il valore raggiunge 100, la risposta è più prudente perché l'esaurimento dei metadati può rendere incoerenti sia i metadati del thin pool che i filesystem.

2. Il gruppo di volumi possiede ancora estensioni fisiche libere?

Questo è il prossimo punto decisionale. Un thin pool può espandersi solo se il suo gruppo di volumi dispone di extent liberi, a meno che non si aggiunga prima ulteriore spazio di archiviazione fisico a tale gruppo di volumi.

vgs -o vg_name,vg_size,vg_free
vgdisplay VG_NAME

Didascalia: Verificare lo spazio libero nel VG distingue una semplice estensione thin-pool da un caso che richiede prima l'aggiunta di memoria.

Se il VG ha spazio libero a sufficienza, di solito è possibile estendere direttamente il thin pool. Se lo spazio libero VFreeè pari a zero o troppo piccolo, non continuare a riprovare lvextend; decidi se puoi rimuovere i thin volumi o gli snapshot non necessari, recuperare i blocchi con l'operazione di scarto o aggiungere un nuovo volume fisico.

3. È consigliabile interrompere le applicazioni prima del ripristino?

Se il pool è già al 100%, arrestare o sospendere le applicazioni che effettuano molte operazioni di scrittura prima di apportare modifiche allo storage. Ciò riduce la probabilità che database, macchine virtuali, container o altri servizi continuino a eseguire operazioni di scrittura mentre il livello di storage è in fase di guasto o riparazione.

systemctl stop YOUR_APPLICATION.service
systemctl status YOUR_APPLICATION.service

Didascalia: La sospensione delle applicazioni limita le scritture aggiuntive durante il ripristino di un thin pool pieno o danneggiato.

Non esiste un elenco universale di servizi da arrestare. Utilizzate l'architettura del vostro carico di lavoro e le procedure di manutenzione. Per i database e le macchine virtuali, preferite il metodo di arresto o di quiescenza supportato dal prodotto piuttosto che terminare bruscamente i processi.

4. Se Data% è pieno e il VG ha spazio libero, come si estende il pool?

Estendere il thin pool stesso, non il thin LV virtuale, perché il problema è la mancanza di capacità del pool fisico. Ad esempio:

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

Didascalia: L'estensione del thin pool aumenta la capacità fisica; la percentuale di dati risultante dovrebbe diminuire una volta che il nuovo spazio sarà disponibile.

Il manuale di lvextend documenta l'estensione diretta del thin pool e l' --poolmetadatasizeopzione separata per i metadati. Scegli un incremento in base al tasso di crescita effettivo e alla capacità di archiviazione che puoi riservare. Un esempio fisso come questo +20Gnon rappresenta una raccomandazione di dimensionamento valida per ogni sistema.

5. Cosa succede se il gruppo di volumi non ha spazio libero?

Aggiungi spazio di archiviazione solo dopo aver verificato che il dispositivo a blocchi di destinazione non sia utilizzato e non contenga dati necessari. La creazione di un volume fisico LVM scrive i metadati LVM sul dispositivo selezionato, pertanto un errore nel nome del dispositivo può essere irreversibile.

lsblk
blkid

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

Didascalia: Quando il gruppo di volumi (VG) è pieno, è possibile aggiungere nuova memoria fisica solo dopo che l'amministratore ha verificato la presenza del dispositivo non utilizzato corretto.

La documentazione SUSE indica che i gruppi di volumi possono essere espansi aggiungendo partizioni o dischi interi. Prima di procedere, è necessario esaminare la topologia di archiviazione su sistemi multipath, SAN, RAID, crittografati, clusterizzati o basati su cloud, poiché il livello di dispositivo corretto potrebbe non essere il disco raw mostrato in un semplice esempio.

6. Cosa succederebbe se Meta% raggiungesse il 100%?

Trattare l'esaurimento dei metadati come un caso di riparazione offline piuttosto che come una semplice aggiunta di capacità dati. Il manuale di LVM thin-pool afferma esplicitamente che l'esaurimento dei metadati può causare incoerenze nei metadati e nei filesystem del thin-pool. La sequenza di ripristino documentata prevede la disattivazione del pool, la sua riparazione lvconvert --repair, l'estensione dei metadati e infine il controllo del filesystem.

Dopo aver arrestato le applicazioni, smontare i filesystem o disattivare in altro modo i thin LV utilizzando il pool. Quindi seguire una procedura di manutenzione controllata simile a questa:

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

Didascalia: Una condizione di metadati pieni richiede la riparazione offline del thin pool e spazio aggiuntivo per i metadati, non solo un maggior numero di extent di dati.

La +1Gfigura è solo un esempio. Il dimensionamento dei metadati dipende dalla dimensione del pool, dalla dimensione dei blocchi, dall'utilizzo degli snapshot e dal comportamento di allocazione. Dopo la riparazione, esaminare i log di sistema e utilizzare la procedura di verifica o riparazione supportata specifica per il filesystem in caso di errori di I/O. Non eseguire uno strumento di riparazione del filesystem alla cieca su un filesystem montato.

L'eliminazione dei file può liberare immediatamente un pool di memoria thin provisioning?

Non sempre. L'eliminazione di un file libera spazio all'interno del filesystem, ma il thin pool recupera i blocchi fisici solo quando le informazioni di scarto raggiungono il pool. La documentazione di LVM indica che fstrimè possibile recuperare tali blocchi, mentre gli snapshot possono continuare a fare riferimento ai blocchi e impedirne la liberazione. Se il pool è configurato per ignorare gli scarti, il trim non recupererà i blocchi.

Quando il filesystem e il carico di lavoro lo consentono, verifica il comportamento di scarto ed esegui il trim solo dopo che il pool è sufficientemente stabile per funzionare:

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

L'eliminazione di snapshot thin obsoleti può liberare spazio di archiviazione anche quando tali snapshot rappresentano gli unici riferimenti rimanenti ai blocchi. Prima di eliminare gli snapshot, verificare i requisiti di backup e conservazione.

7. Come si può evitare che ciò accada di nuovo?

Abilitare e verificare il monitoraggio del thin pool LVM e configurare l'estensione automatica con sufficiente capacità libera nel VG. LVM upstream utilizza dmeventd, normalmente tramite il lvm2-monitorservizio, per reagire quando l'utilizzo dei dati o dei metadati supera la soglia configurata.

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

Didascalia: L'estensione automatica dipende dal monitoraggio attivo, da una soglia appropriata e dalla disponibilità di volume libero nel gruppo di volume.

Il manuale di LVM afferma che una soglia di 100 disabilita l'estensione automatica e che la soglia minima valida è 50. Una soglia inferiore concede a LVM più tempo per reagire ai pool con velocità di scrittura molto elevate. La percentuale di estensione determina di quanto cresce il pool quando viene attivata la policy.

Una configurazione rappresentativa /etc/lvm/lvm.confpotrebbe essere:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Questi valori sono esempi, non impostazioni predefinite universali. Dimensionare il margine di sicurezza in base alla velocità di scrittura a raffica, all'intervallo di monitoraggio, al tempo di provisioning dello storage e allo spazio libero disponibile nel VG. L'estensione automatica non è d'aiuto se il VG è già pieno.

8. Come fai a sapere se il recupero ha funzionato davvero?

Verificare più di un segnale. Il pool dovrebbe avere margine di manovra, il gruppo di volumi (VG) dovrebbe avere spazio libero sufficiente per la crescita prevista, le applicazioni dovrebbero essere in grado di scrivere normalmente e i log non dovrebbero mostrare errori persistenti di I/O del thin pool o errori di metadati.

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"

Didascalia: Il ripristino è confermato quando l'utilizzo del pool ha margine, il VG mantiene spazio libero utilizzabile e il monitoraggio non segnala errori di I/O persistenti.

Riavvia le applicazioni gradualmente e monitora il pool di risorse fino al ritorno del carico di lavoro effettivo. Se Data%il carico aumenta di nuovo in modo insolitamente rapido, l'estensione del pool potrebbe aver risolto l'interruzione immediata senza però aver corretto il problema di pianificazione della capacità.

Quando è opportuno fermarsi e intraprendere un percorso di recupero diverso?

Cosa bisogna evitare?

• Non dare df -hper scontato che una piscina sottile abbia spazio di archiviazione fisico libero.
• Non inizializzare un nuovo dispositivo pvcreatefinché non hai verificato con certezza che non è mai stato utilizzato.
• Non bisogna considerare l'esaurimento dei metadati come un problema analogo all'esaurimento dei dati ordinari.
• Non affidarti all'estensione automatica senza riservare estensioni libere nel VG.
• Non eseguire comandi di riparazione del filesystem su filesystem montati a meno che il fornitore del filesystem non supporti esplicitamente tale operazione.
• Non disabilitare il monitoraggio solo per sopprimere gli avvisi; l'avviso è spesso l'ultima opportunità per estendere il pool prima che le operazioni di scrittura falliscano.

Riferimenti ufficiali e primari

• Guida all'amministrazione dello storage di SUSE Linux Enterprise Server 15 SP7
• Documentazione di SUSE SLES 15 SP7 Expert Partitioner
• Manuale di thin provisioning LVM
• Manuale LVM lvextend