Spazio esaurito nel pool Thin SLES: estendere LVM in modo sicuro e ripristinare le scritture

Quando un volume thin provisioned di SUSE Linux Enterprise Server segnala "spazio insufficiente sul dispositivo", verificare prima le Data%dimensioni del thin pool. Se l'area dati è piena e il gruppo di volumi dispone di extent liberi, estendere il thin pool con le dimensioni virtuali, non semplicemente con le dimensioni virtuali del suo volume logico thin. Un'area metadati completamente piena è diversa: potrebbe richiedere una riparazione offline prima che le normali operazioni di scrittura riprendano.Meta%lvextend

La procedura seguente utilizza i comandi LVM2 documentati per Linux e il modello di storage descritto nella Guida all'amministrazione dello storage di SUSE Linux Enterprise Server 15 SP7 . La disponibilità dei comandi e la configurazione del servizio potrebbero differire su un altro service pack di SLES o su un'installazione cluster. Eseguire un backup coerente con l'applicazione e limitare le operazioni di scrittura intensive prima di modificare lo storage di produzione.

1. Verificare se lo spazio dati o i metadati sono esauriti.

Eseguire il seguente comando sull'host proprietario del thin pool attivo, sostituendo vgdatacon il nome del gruppo di volumi:

sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,pool_lv vgdata

Cerca la riga con thin-poolsotto SegType. Data%misura i blocchi di dati allocati; Meta%misura i metadati di mappatura del pool. Questi sono limiti di capacità separati. Se Data%è vicino a 100 ma Meta%è comodamente al di sotto di esso, gli extent di dati aggiuntivi sono il rimedio più diretto. Se Meta%è a 100, usa le precauzioni di ripristino nella sezione 4.

Ad esempio , supponiamo vgdata/pool0che la dimensione sia di 100 GiB con un utilizzo dei dati del 98,12% e un utilizzo dei metadati del 40,26%. Il pool è a rischio immediato anche se df -hsegnala molto spazio libero all'interno di un volume thin montato. La dimensione virtuale di un volume thin può superare la capacità fisica a supporto del pool, come spiegato nella documentazione di Expert Partitioner di SUSE .

Verifica anche gli errori recenti:

sudo journalctl -k --since "-30 min" | grep -Ei 'thin|no space|I/O error'

Non interpretare un risultato vuoto di grep come prova che non si siano verificati errori di scrittura. Controlla anche i log dell'applicazione, soprattutto se un database o una macchina virtuale stavano scrivendo quando il pool si è riempito.

2. Verificare che il gruppo di volumi abbia estensioni fisiche libere

Prima di modificare le dimensioni del pool, accertatevi se il gruppo di volume può finanziare l'ampliamento:

sudo vgs -o vg_name,vg_size,vg_free vgdata

Nell'esempio ipotetico, il gruppo di volumi da 200 GiB ha 40 GiB liberi. Un'estensione del pool di 20 GiB è quindi in linea di principio fattibile, fatte salve le limitazioni di allocazione e la disponibilità di spazio per un'eventuale crescita dei metadati. È consigliabile tenere una parte dello spazio del gruppo di volumi di riserva anziché assegnare ogni extent libero al pool.

Se VG_FREEil valore è zero, lvextendnon è possibile creare capacità fisica. Aggiungere un volume fisico correttamente identificato e preparato al VG, espandere lo storage sottostante e il relativo PV LVM, se necessario, oppure recuperare i blocchi prima di riprovare. La documentazione SUSE descrive come aggiungere volumi fisici durante il ridimensionamento di un gruppo di volumi . Non eseguire mai l'operazione pvcreatesu un disco non verificato: potrebbe distruggere i metadati di storage esistenti.

3. Estendere la piscina sottile piuttosto che il volume sottile

Quando Data%il fattore limitante è esaurito, i metadati non sono esauriti e sono disponibili sufficienti estensioni VG, estendere il pool stesso:

sudo lvextend -L +20G vgdata/pool0

La +20Gsintassi aggiunge 20 GiB alla dimensione corrente del pool; non imposta la dimensione finale a 20 GiB. In questo esempio, il pool di supporto passa da 100 GiB a 120 GiB. Con i dati allocati invariati, 98,12 GiB in uso rappresenterebbero circa l'81,8% del pool ampliato. La percentuale effettiva potrebbe essere diversa se le operazioni di scrittura continuano durante l'operazione.

Non sostituire .lvextend -L +20G vgdata/thin1 L'ampliamento dello spazio degli indirizzi virtuali di un volume thin non aggiunge necessariamente capacità dati fisica al suo pool. Poiché questo comando espande il pool di supporto anziché il dispositivo a blocchi virtuale del filesystem, in genere non è necessario ridimensionare il filesystem per questa specifica operazione. Il manuale ufficiale di thin provisioning LVM documenta il meccanismo di estensione del thin pool e i suoi limiti.

Quando non è possibile estendere la piscina immediatamente

Se i file sono già stati eliminati da un filesystem thin e la funzione di scarto è supportata dall'intero stack, si consiglia di recuperare i blocchi scartati:

sudo fstrim -v /srv/data

Utilizzare il punto di montaggio effettivo di un volume thin, non il dispositivo thin-pool. Un'operazione di trim riuscita può ridurre lo spazio occupato Data%, ma la sola eliminazione dei file in genere non ripristina i blocchi nel pool. Gli snapshot thin possono conservare i blocchi condivisi e un pool impostato per ignorare gli scarti non ne trarrà vantaggio. Non considerare il trim come un sostituto di emergenza affidabile per la capacità fisica, soprattutto se le scritture hanno iniziato a fallire. Rimuovere gli snapshot obsoleti solo dopo averne verificato la proprietà, le dipendenze e i requisiti di conservazione; l'eliminazione degli snapshot è irreversibile.

4. Trattare un'area metadati completa come condizione di ripristino

Se Meta%ha raggiunto il 100%, interrompere le scritture dell'applicazione e pianificare un'interruzione controllata. LVM avverte che l'esaurimento dei metadati può rendere incoerenti i metadati del thin pool e i filesystem. Il semplice aumento delle dimensioni del pool di dati, il ritentamento delle scritture o la forzatura dell'attivazione non risolvono questo rischio.

La sequenza di ripristino documentata prevede la disattivazione offline del pool interessato, la riparazione dei metadati di piccole dimensioni tramite lvconvert --repair VG/ThinPool, l'espansione della capacità dei metadati tramite lvextend --poolmetadatasizee infine il controllo di ciascun filesystem interessato con lo strumento offline appropriato. Ad esempio, un pool il cui volume logico (LV) dei metadati è inferiore a 2 GiB potrebbe richiedere una destinazione revisionata come:

sudo lvextend --poolmetadatasize 2G vgdata/pool0

Questo non è un comando da eseguire alla cieca su un pool attivo e danneggiato. Le sue dimensioni sono un esempio, non un requisito universale. Verificare prima le dimensioni correnti dei metadati, gli extent disponibili, la corretta disattivazione, i supporti di ripristino e i backup. L'operazione lvconvert --repairdeve essere pianificata tenendo conto dei tempi di inattività e delle competenze di ripristino; il manuale di LVM indica che potrebbe fallire e che i dati potrebbero comunque risultare irrecuperabili. Conservare il vecchio volume logico (LV) dei metadati fino a quando il pool e i filesystem non saranno stati verificati. Un backup della configurazione LVM vgcfgbackupnon esegue il backup dei metadati dei thin pool. Per i dati critici per l'azienda, contattare il supporto SUSE o il team di ripristino dello storage prima di tentare la riparazione.

5. Abilita l'estensione automatica, quindi verifica le scritture

Una volta che il sistema è stabile, configura una politica di crescita proattiva nella activationsezione /etc/lvm/lvm.conf. Questo esempio avvia l'estensione con un utilizzo del 70% e richiede una crescita del 20%; ottimizza questi valori in base alla velocità di scrittura e alla capacità VG disponibile:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Assicurarsi che le impostazioni siano applicate all'ambito di configurazione corretto e che il pool sia monitorato:

sudo lvchange --monitor y vgdata/pool0

L'espansione automatica del thin pool dipende dal monitoraggio degli eventi LVM ( dmeventd) e da un numero sufficiente di extent liberi. Controlla il servizio di monitoraggio fornito dalla tua installazione SLES, ad esempio systemctl status lvm2-monitordove si trova tale unità, e rivedi i relativi log. Una soglia non garantisce la protezione se le scritture superano l'estensione o se il VG è già pieno. Consulta la guida all'estensione automatica e le opzioni di monitoraggio lvchange del manuale LVM .

Verifica che la soluzione abbia funzionato.

Leggere sia il tasso di utilizzo della piscina che la capacità residua del VG:

sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vgdata/pool0
sudo vgs -o vg_name,vg_free vgdata

Data%Il valore dovrebbe essere diminuito dopo l'espansione del pool di dati, Meta%deve rimanere al di sotto del livello di esaurimento e il pool dovrebbe essere attivo senza nuovi errori di I/O. Verificare lo stato del filesystem e i log dell'applicazione, quindi eseguire un piccolo test di scrittura e lettura appropriato all'applicazione prima di rilasciare i carichi di lavoro sospesi. Se gli errori persistono anche dopo che lo spazio è disponibile, mantenere il carico di lavoro interessato offline fino a quando non è stata valutata l'integrità del filesystem e dell'applicazione; una maggiore capacità non può annullare scritture già fallite o perse.