Tags: vSphere, Storage
Grundsätzlich tritt das Problem der Speicherplatzrückgewinnung bei Thin Provisioning auf. Dabei muss man zwischen der dünnen Bereitstellung auf der Ebene von vSphere und des Storage-Systems unterscheiden. Insgesamt erweist sich VMFS 6 (ESXi 6.5 und 6.7) hier deutlich flexibler als VMFS 5.
Ganz allgemein gibt es zwei Fälle, bei denen Speicherplatz frei wird:
- Beim Löschen oder Migrieren von VMs bzw. von Snapshots
- Beim Löschen von Dateien innerhalb einer VM, deren virtuelle Disk im Thin-Format bereitgestellt wurde
Bei diesen Vorgängen verbleiben Blöcke mit ungenutztem Speicher im Array. Erkennt dieses jedoch nicht, dass die Daten aus den Blöcken gelöscht wurden, dann bleiben sie so lange zugeteilt, bis sie vom Datenspeicher selbst freigegeben werden.
Rückgewinnung auf VMware-Ebene
Durch das Generieren neuer Daten wachsen die VMDK-Dateien für Thin-Festplatten an, schrumpfen allerdings nicht automatisch, wenn Daten gelöscht werden. Das Problem betrifft auch Backup-Lösungen, die über die vStorage-API kommunizieren und Storage vMotion (svmotion).
Hinzu kommt, dass die meisten Gast-Dateisysteme die Daten nicht wirklich löschen, sondern nur als gelöscht markieren. Daher ist eine virtuelle Festplattendatei permanent im Wachstum begriffen. Nur wenn eine VM über das Gast-OS tatsächlich Daten löscht und den Speicher aktiv als frei markiert, kann dieser zum Beispiel durch ein Storage vMotion zurückgewonnen werden.
Außerhalb des Gastsystems kann VMware nicht erkennen, welche Daten tatsächlich gelöscht wurden. Das gleiche Problem hat man bei der Formatierung, also dem Schreiben mit Nullen.
Aus diesem Grund sollte der Vorgang etwa so ablaufen: Löscht der Nutzer Dateien in einer VM, wird Speicherplatz freigegeben. Das Gastbetriebssystem benachrichtigt dann VMFS über den neu verfügbaren Speicherplatz und sendet dazu einen unmap-Befehl zum Aufheben der Zuordnung. Dadurch wird Speicherplatz im VMFS-Datenspeicher freigegeben, und danach wird der Befehl an die Array-Ebene übergeben.
Neu ab ESXi 6.5 ist, dass ein VMFS6-Datastore den Befehl zur Speicherplatzrückforderung automatisch senden kann, während man sie bei VMFS5 manuell anfordern muss. Dass VMFS6 den Befehl automatisch senden kann, liegt am für thin-provisionierte Disks verwendeten SESparse-Format.
Eine Ausnahme ist in diesem Zusammenhang die Freigabe von Speicher auf VM-Ebene bei thick-provisionierten Disks. Sind die VMware Tools installiert, dann kann man in der Toolbox-GUI unter dem Reiter Verkleinern Platz aktiv zurückgewinnen. Um diese Funktion mit thin-provisionierten Disks zu nutzen, müssten diese also erst im Datastore "inflatet" werden.
Bei thin-provisionierten virtuellen Disks unterstützen vSphere 6.0 und älter das Rückfordern von Speicher aus der VM nur bedingt bzw. teilweise, da hier VMFS5 der begrenzende Faktor ist. Dort kann nämlich das Dateisystem den vom Gast-OS ausgelösten unmap-Befehl nicht direkt an das Array übergeben. Nutzer müssen stattdessen den Befehl
esxcli storage vmfs unmap
ausführen, um Zuordnungsaufhebungen für das Array auszulösen.
Nur unter bestimmten Voraussetzungen unterstützt VMFS5 die Anforderungen zur automatischen Rückgewinnung von Speicher. So muss
- die virtuelle Festplatte per Thin Provisioning bereitgestellt werden
- die VM die vHardware-Version 11 (ESXi 6.0) oder höher haben
- der erweiterte Parameter EnableBlockDelete auf 1 gesetzt sein
Schließlich muss das Gastbetriebssystem noch die virtuelle Festplatte als Thin-Festplatte identifizieren können.
VMFS6 dagegen, und damit nur ESXi 6.5 und 6.7, unterstützt grundsätzlich die vom Gast-OS ausgelöste automatische Speicherplatzrückforderung und leitet diese an das Array weiter.
Heutzutage können zahlreiche Gastbetriebssysteme den unmap-Befehl ohne weitere Konfiguration senden. Aber jene, die keine automatische Aufhebung der Zuordnung unterstützen, erfordern unter Umständen einen Benutzereingriff.
Generell verarbeitet VMFS die Anforderung zum Aufheben der Zuordnung nur, wenn der zurückzufordernde Speicherplatz 1 MB oder ein Vielfaches davon ist. Eine weitere Einschränkung betrifft VMs mit Snapshots im standardmäßigen SESparse-Format. Hier unterstützt VMFS6 die automatische Speicherplatzrückforderung nur für ESXi 6.7.
Rückgewinnung auf Storage-Ebene
Auch beim Löschen von Dateien aus einem VMFS-Datastore wird Platz im Dateisystem frei. Allerdings bleibt er einem Speichergerät zugewiesen, bis er vom Dateisystem freigegeben oder die Zuordnung aufgehoben wird.
Dieser Vorgang ermöglicht dem Speicher-Array, von einer thin-provisionierten LUN nicht verwendeten Speicherplatz zurückzufordern. Nicht zugeordneter Speicherplatz lässt sich dann für anderen Zwecke verwenden.
Auch zur Rückgewinnung auf Speicherebene kommt wieder das scsi-unmap-Kommando zum Einsatz. Hosts können zum Beispiel einen solchen Befehl an den Speicher-Controller senden, um zu signalisieren, dass ein LBA-Bereich auf einer Festplatte freigegeben werden kann. Dies ist beispielsweise beim Formatieren eines neuen Volumes oder beim Löschen von Dateien in einem Dateisystem der Fall.
Erhält ein Speicher-Array einen SCSI-Befehl zum Aufheben der Zuordnung, dann wird der Bereich des Volumes, in dem sich die Daten ohne Zuordnung befinden, überschrieben. Auf diese Weise können Thin-Provisioning-Speicher-Controller physische Kapazität mittels Garbage Collection zurückfordern. Damit verhindert er, dass ihm die freie Kapazität für Schreib-I/O-Anforderungen ausgeht.
Allerdings heben VMFS5 und ältere Dateisysteme die Zuordnung von freiem Speicherplatz nicht automatisch auf. Hier muss der Nutzer in jedem Fall manuell zur Tat schreiten und wieder mit dem Kommando
esxcli storage vmfs unmap
Speicher zurückfordern.
Dabei ist jedoch zu beachten, dass der Befehl unter Umständen zahlreiche Anforderungen zugleich sendet, wodurch im Verlauf des Vorgangs ggf. Ressourcen gesperrt werden. Um festzustellen, ob ein bestimmtes Speichergerät als thin provisioniert wurde, führt man dieses Kommando aus:
esxcli --server=<server_name> storage core device list -d=<device_ID>
Die gewünschte Information findet sich in der Zeile Thin Provisioning Status. Das manuelle Rückfordern des gesamten angesammelten Speicherplatzes könnte dann mit
esxcli storage vmfs unmap
erfolgen, wobei das Kommando entweder das Argument "-l volume-label" oder "-u volume-id" erwartet, zum Beispiel
esxcli storage vmfs unmap -l DS-Syno-iSCSI
Bei VMFS6-Datastores unterstützt ESXi die automatische asynchrone Rückforderung von freiem Speicherplatz, das heißt, VMFS6 führt den unmap-Befehl (Zuordnung aufheben) automatisch aus, um auf Speicher-Arrays freien Speicherplatz freizugeben, der per Thin Provisioning bereitgestellt wurde.
Die asynchrone Aufhebung der Zuordnung hat verschiedene Vorteile. Dabei werden die Anforderungen stets mit einer konstanten Häufigkeit gesendet, was eine sofortige Belastung auf dem Array vermeidet.
Ferner erfolgen das Bündeln freigegebener Regionen und das Aufheben der Zuordnung gemeinsam. Schließlich werden das Aufheben der Zuordnung und das entsprechende "Kürzen" von I/O-Pfaden unabhängig voneinander durchgeführt, um die I/O-Leistung nicht zu beeinträchtigen.
Folgende Tabelle fasst die Optionen zum Thin-Provisioning-Support und zur Speicherrückgewinnung für ESXi 5.5 bis 6.7 zusammen:
Unterstützte Thin-Provisioning-Features | ESXi < 5.5 | ESXi 5.5 und ESXi 6.0 | ESXi 6.5 und ESXi 6.7 |
---|---|---|---|
Thin Provisioning | Ja | Ja | Ja |
unmap-Befehl von VMFS | manuell via vmkfstools -y (deprecated) |
manuell via esxcli storage vmfs unmap |
automatisch bei Verwendung von VMFS6 |
unmap-Befehl vom Gastsystem | Ja für ausgewählte Gastsysteme | Ja für ausgewählte Gastsysteme | automatisch bei Verwendung von VMFS6 |
Voraussetzung ist neben der geeigneten ESXi-Version ein Speicher-Array, das die T10-basierte vSphere Storage APIs - Array Integration (VAAI), einschließlich Thin Provisioning und Rückforderung von Speicherplatz, unterstützt.
Der Befehl
vmkfstools -y
ist zudem seit vSphere 5.5 deprecated. Der neuere Befehl
esxcli storage vmfs unmap
zeigt darüber hinaus direkt den wiedergewinnbaren Speicherplatz in Blockgröße an und kann außerdem mit wesentlich größeren Bereichen umgehen. Das in VMF6 automatisch implementierte Verfahren läuft konstant mit 25 MBps im Hintergrund.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet seit mehr als 20 Jahren selbständig als Redakteur und Autor für viele ehemalige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buchautor und IT-Consultant.
Seit 5 Jahren ist Thomas neben seiner journalistischen Tätigkeit hauptberuflicher, selbständiger IT-Trainer für VMware und Microsoft.
Seine Themenschwerpunkte sind Virtualisierung und Cloud Computing, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zertifizierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas ist außerdem zertifizierter AWS Solutions Architect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Administrator.
Thomas führt aktuell jeden zweiten Montag einen 4-tägigen Grundlagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Informationen und Anmeldung über sein AWS-Blog.
Ähnliche Beiträge
- VMware vSphere 7 Update 3: Neue Features in vSAN 7.2
- Neu in vSphere 7 Update 3: NSX-Integration, NVMe über TCP, Update für DRS, Precision Time
- Neu in VMware vSphere 7 Update 2: Integrierter KMS, ESXi Suspend-to-Memory, vSAN-Zugriff für normale vSphere-Cluster, Load-Balancer für Kubernetes
- Leistung von vSphere-Speicher überprüfen mit VMware Storage Performance Tester
- VMware vSAN 6.x auf 7.0 (Update 1) aktualisieren
Weitere Links