Sicheres Beheben von Speicherplatzproblemen bei SUSE Linux Enterprise LVM Thin Provisioning

Was sollten Sie festlegen, bevor Sie irgendetwas ändern?

Zunächst muss ermittelt werden, ob der Thin Pool nur noch Datenspeicher , Metadatenspeicher oder beides umfasst . Diese Unterscheidung beeinflusst den Wiederherstellungsplan. Ein Thin Pool enthält ein Daten-LV, das die zugewiesenen Blöcke speichert, und ein Metadaten-LV, das diese Zuweisungen verwaltet. Die virtuelle Größe von Thin Logical Volumes kann die physische Kapazität des Pools überschreiten. Dies ist der Sinn von Thin Provisioning, aber auch der Grund, warum Overcommit überwacht werden muss.

Die Dokumentation zu SUSE Linux Enterprise Server 15 SP7 bestätigt, dass Thin Volumes Speicherplatz aus einem Thin Pool bedarfsgesteuert zuweisen und dass die kombinierte virtuelle Größe den verfügbaren physischen Speicher überbuchen kann. Die zugehörige LVM-Thin-Pool-Dokumentation ergänzt eine wichtige Betriebsregel: Der Pool muss erweitert werden, bevor entweder die virtuelle Speicherkapazität Data%oder Meta%die physische Speicherkapazität 100 % erreicht. Weitere Informationen finden Sie im SUSE Linux Enterprise Server 15 SP7 Storage Administration Guide und im LVM Thin Provisioning Manual .

1. Ist der Datenspeicher voll oder sind die Metadaten voll?

Verwenden Sie lvsexplizite Spalten anstelle einer allgemeinen Festplattenspeicherprüfung. Ein Dateisystem kann weiterhin freien virtuellen Speicherplatz melden, obwohl der darunterliegende physische Thin Pool nahezu erschöpft ist.

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

Bildunterschrift: Der Thin Pool muss anhand seiner Data%- und Meta%-Werte identifiziert werden; der freie Speicherplatz im Dateisystem allein zeigt keine physische Erschöpfung des Thin Pools an.

Wenn Data%der Wert bei oder nahe 100 liegt, sind im Datenpool keine Blöcke mehr für neue Schreibvorgänge verfügbar. Die LVM-Dokumentation warnt davor, dass Schreibvorgänge Fehler zurückgeben können, wenn der Datenpool erschöpft ist, was wiederum Dateisysteme beschädigen kann. Erreicht der Meta%Wert 100, ist die Reaktion vorsichtiger, da die Erschöpfung der Metadaten zu Inkonsistenzen sowohl im Thin-Pool-Metadatenpool als auch im Dateisystem führen kann.

2. Verfügt die Volumengruppe noch über freie physikalische Ausdehnungen?

Dies ist der nächste Entscheidungspunkt. Ein Thin Pool kann nur wachsen, wenn seine Volume Group über freie Extents verfügt, es sei denn, Sie fügen dieser Volume Group zuerst mehr physischen Speicher hinzu.

vgs -o vg_name,vg_size,vg_free
vgdisplay VG_NAME

Bildunterschrift: Die Überprüfung des freien Speicherplatzes in der Volume Group (VG) unterscheidet eine einfache Thin-Pool-Erweiterung von einem Fall, in dem zunächst zusätzlicher Speicherplatz benötigt wird.

Wenn die Volume Group (VG) über ausreichend freien Speicherplatz verfügt, kann der Thin Pool in der Regel direkt erweitert werden. VFreeIst der freie Speicherplatz null oder zu gering, sollten keine weiteren Versuche unternommen werden lvextend. Stattdessen sollte entschieden werden, ob nicht benötigte Thin Volumes oder Snapshots entfernt, Blöcke mit `discard` freigegeben oder ein neues physisches Volume hinzugefügt werden können.

3. Sollten Sie die Anwendungen vor der Wiederherstellung stoppen?

Ist der Speicherpool bereits zu 100 % ausgelastet, sollten schreibintensive Anwendungen vor Speicheränderungen gestoppt oder in den Ruhezustand versetzt werden. Dadurch wird die Wahrscheinlichkeit verringert, dass Datenbanken, virtuelle Maschinen, Container oder andere Dienste weiterhin Schreibvorgänge ausführen, während die Speicherschicht ausfällt oder repariert wird.

systemctl stop YOUR_APPLICATION.service
systemctl status YOUR_APPLICATION.service

Bildunterschrift: Anwendungen im Ruhezustand begrenzen zusätzliche Schreibvorgänge, während ein voller oder beschädigter Thin Pool wiederhergestellt wird.

Es gibt keine allgemeingültige Liste von Diensten, die gestoppt werden sollten. Verwenden Sie die für Ihre Workload-Architektur und Wartungsverfahren erforderlichen Methoden. Bei Datenbanken und virtuellen Maschinen sollten Sie die vom Produkt unterstützten Methoden zum Herunterfahren oder in den Ruhezustand (Quiesce) dem abrupten Beenden von Prozessen vorziehen.

4. Wenn der Datenspeicher voll ist und die Volume Group (VG) über freien Speicherplatz verfügt, wie kann der Pool erweitert werden?

Erweitern Sie den Thin Pool selbst, nicht den virtuellen Thin LV, da das Problem in der mangelnden physischen Poolkapazität liegt. Zum Beispiel:

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

Bildunterschrift: Durch die Erweiterung des Thin Pools wird die physische Kapazität erhöht; der resultierende Datenprozentsatz sollte sinken, sobald der neue Speicherplatz verfügbar ist.

Das Handbuch von lvextend beschreibt die direkte Thin-Pool-Erweiterung und die separate --poolmetadatasizeOption für Metadaten. Wählen Sie ein Inkrement basierend auf der tatsächlichen Wachstumsrate und der verfügbaren Speicherkapazität. Ein festes Beispiel ist +20Gkeine Dimensionierungsempfehlung für jedes System.

5. Was passiert, wenn die Volumengruppe keinen freien Speicherplatz mehr hat?

Fügen Sie Speicher erst hinzu, nachdem Sie sichergestellt haben, dass das Zielblockgerät ungenutzt ist und keine benötigten Daten enthält. Beim Erstellen eines physischen LVM-Volumes werden LVM-Metadaten auf das ausgewählte Gerät geschrieben; ein Fehler im Gerätenamen kann daher schwerwiegende Folgen haben.

lsblk
blkid

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

Bildunterschrift: Wenn die VG voll ist, kann neuer physischer Speicher zuerst hinzugefügt werden, nachdem der Administrator das richtige ungenutzte Gerät überprüft hat.

SUSE dokumentiert, dass Volume-Gruppen durch Hinzufügen von Partitionen oder ganzen Festplatten erweitert werden können. Überprüfen Sie die Speichertopologie, bevor Sie dies auf Multipath-, SAN-, RAID-, verschlüsselten, Cluster- oder Cloud-basierten Systemen durchführen, da die korrekte Geräteebene möglicherweise nicht die in einem einfachen Beispiel gezeigte Rohfestplatte ist.

6. Was wäre, wenn Meta% 100% erreichen würde?

Behandeln Sie Metadatenmangel als Offline-Reparaturfall und nicht einfach als Erweiterung der Datenkapazität. Das LVM-Thin-Pool-Handbuch weist ausdrücklich darauf hin, dass Metadatenmangel zu inkonsistenten Thin-Pool-Metadaten und Dateisystemen führen kann. Die dokumentierte Wiederherstellungssequenz sieht vor, den Pool zu deaktivieren, ihn mit `lvm.repair` zu reparieren lvconvert --repair, die Metadaten zu erweitern und anschließend das Dateisystem zu überprüfen.

Nach dem Beenden der Anwendungen sollten die Dateisysteme ausgehängt oder die Thin-LVs mithilfe des Pools anderweitig deaktiviert werden. Anschließend sollte ein kontrolliertes Wartungsverfahren ähnlich dem folgenden durchgeführt werden:

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

Bildunterschrift: Ein Metadaten-voller Zustand erfordert eine Offline-Reparatur des Thin-Pools und zusätzlichen Metadatenspeicher, nicht nur mehr Datenextents.

Die +1GAbbildung dient lediglich als Beispiel. Die Metadatengröße hängt von der Poolgröße, der Chunk-Größe, der Snapshot-Nutzung und dem Zuordnungsverhalten ab. Überprüfen Sie nach der Reparatur die Systemprotokolle und verwenden Sie die dateisystemspezifische, unterstützte Prüf- oder Reparaturprozedur, falls E/A-Fehler aufgetreten sind. Führen Sie kein Dateisystemreparaturtool ohne vorherige Prüfung auf einem eingebundenen Dateisystem aus.

Kann ein kleiner Datenpool durch das Löschen von Dateien sofort wieder freigegeben werden?

Nicht immer. Das Löschen einer Datei gibt zwar Speicherplatz im Dateisystem frei, aber der Thin Pool gibt physische Blöcke erst dann frei, wenn die entsprechenden Daten verworfen werden. Die LVM-Dokumentation weist darauf hin, dass fstrimsolche Blöcke freigegeben werden können, während Snapshots weiterhin auf Blöcke verweisen und deren Freigabe verhindern können. Wenn der Pool so konfiguriert ist, dass verworfene Daten ignoriert werden, gibt Trim die Blöcke nicht frei.

Sofern Dateisystem und Arbeitslast dies zulassen, überprüfen Sie das Verwerfen von Dateien und führen Sie Trim erst durch, nachdem der Pool stabil genug ist, um betriebsbereit zu sein:

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

Das Löschen alter Thin Snapshots kann Speicherplatz freigeben, wenn diese Snapshots die letzten Referenzen auf Blöcke darstellen. Überprüfen Sie die Backup- und Aufbewahrungsanforderungen, bevor Sie Snapshots löschen.

7. Wie kann man verhindern, dass dies erneut passiert?

Aktivieren und überprüfen Sie die LVM-Thin-Pool-Überwachung und konfigurieren Sie die automatische Erweiterung mit ausreichend freier Kapazität in der Volume Group. Upstream-LVM verwendet dmeventdnormalerweise über den lvm2-monitorDienst , um zu reagieren, wenn die Daten- oder Metadatennutzung den konfigurierten Schwellenwert überschreitet.

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

Bildunterschrift: Die automatische Erweiterung hängt von einer aktiven Überwachung, einem geeigneten Schwellenwert und dem Vorhandensein freier Extents in der Volumengruppe ab.

Das LVM-Handbuch gibt an, dass ein Schwellenwert von 100 die automatische Erweiterung deaktiviert und der minimale gültige Schwellenwert 50 beträgt. Ein niedrigerer Schwellenwert gibt LVM mehr Zeit, auf Pools mit sehr hohen Schreibraten zu reagieren. Der Erweiterungsprozentsatz bestimmt, um wie viel der Pool wächst, wenn die Richtlinie ausgelöst wird.

Eine repräsentative Konfiguration /etc/lvm/lvm.confkönnte wie folgt aussehen:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Diese Werte sind Beispiele, keine universellen Standardwerte. Die Sicherheitsmarge sollte anhand der Schreibspitzenrate, des Überwachungsintervalls, der Vorlaufzeit für die Speicherbereitstellung und des verfügbaren freien Speicherplatzes in der Volume Group (VG) dimensioniert werden. Eine automatische Erweiterung hilft nicht, wenn die VG bereits voll ist.

8. Woran erkennen Sie, dass die Wiederherstellung tatsächlich erfolgreich war?

Überprüfen Sie mehrere Signale. Der Pool sollte über ausreichend Spielraum verfügen, die Volume Group (VG) sollte genügend freien Speicherplatz für das erwartete Wachstum bieten, Anwendungen sollten normal schreiben können und die Protokolle sollten keine anhaltenden Thin-Pool-E/A- oder Metadatenfehler aufweisen.

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"

Bildunterschrift: Die Wiederherstellung ist bestätigt, wenn die Poolauslastung Spielraum bietet, die VG über nutzbaren freien Speicherplatz verfügt und die Überwachung keine weiteren E/A-Fehler meldet.

Starten Sie die Anwendungen schrittweise neu und beobachten Sie den Auslastungspool, während die tatsächliche Arbeitslast wieder ansteigt. Sollte Data%die Auslastung erneut ungewöhnlich schnell ansteigen, hat die Erweiterung des Pools möglicherweise den unmittelbaren Ausfall behoben, ohne das Problem der Kapazitätsplanung zu lösen.

Wann sollten Sie abbrechen und einen anderen Wiederherstellungspfad wählen?

Was sollten Sie vermeiden?

• Gehen Sie nicht df -hdavon aus, dass ein dünner Pool über freien physischen Speicherplatz verfügt.
• Initialisieren Sie ein neues Gerät erst pvcreate, wenn Sie sicher sind, dass es unbenutzt ist.
• Behandeln Sie die Erschöpfung von Metadaten nicht als dasselbe Problem wie die Erschöpfung gewöhnlicher Daten.
• Verlassen Sie sich nicht auf die automatische Erweiterung, ohne freie Extents in der Volume Group zu reservieren.
• Führen Sie keine Dateisystemreparaturbefehle auf eingebundenen Dateisystemen aus, es sei denn, der Dateisystemhersteller unterstützt diese Operation ausdrücklich.
• Deaktivieren Sie die Überwachung nicht nur, um Warnungen zu unterdrücken; die Warnung ist oft die letzte Möglichkeit, den Pool zu erweitern, bevor Schreibvorgänge fehlschlagen.

Offizielle und primäre Referenzen

• SUSE Linux Enterprise Server 15 SP7 Speicherverwaltungshandbuch
• SUSE SLES 15 SP7 Expert Partitioner Dokumentation
• LVM Thin Provisioning Handbuch
• LVM lvextend Handbuch