cd ~/

Home of Daniel Graf

Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

cd ~/

Home of Daniel Graf

Seiten

Suche

Blog Meta

Dynamo Dresden

Galerie

blog:vmware_-_dead_space_reclamation_bei_thin_provisioned_vdisks

VMware - Dead Space Reclamation bei Thin Provisioned vDisks

Bei der Bereitstellung von VMs, bzw. auch dem nachträglichen Einfügen von vDisks, bietet VMware die Möglichkeit, die neue Festplatte Thin oder Thick Provisioned anzulegen. Thin Provisioned vDisks haben den Vorteil, dass sie beim Anlegen auf dem Datastore keinen/kaum Speicherplatz belegen, und dynamisch bis zum konfigurierten Limit wachsen, sobald im Dateisystem der vDisk Daten geschrieben werden. Im Gegensatz zu Thick Provisioned vDisks, die beim Anlegen das VMDK File in der vollen Größe erstellen, lässt sich somit der Speicherplatz für andere VMs nutzen, wenn der eigentliche Speicherbedarf nicht ausgeschöpft wird.

Allerdings ergeben sich auch Nachteile, oder zumindest Einschränkungen! So ist es unabdingbar, sehr früh auf einen stetig wachsenden Speicherbedarf zu reagieren. Im schlimmsten Fall läuft der komplette Datastore zu, bevor man überhaupt eine Erweiterung oder ein größeres Storage bereitstellen kann. Weiterhin "funktionieren" Thin Provisioned vDisks nur "in eine Richtung". Sprich, das VMDK File wächst, wenn Daten im Dateisystem geschrieben werden, schrumpft aber nicht automatisch, wenn Daten wieder gelöscht werden. Dies ist ein manueller Schritt den man ausführen muss, wenn man den nicht mehr genutzten Speicherplatz wieder freigeben möchte. Und um genau dieses Thema handelt es sich in diesem Beitrag, um die Dead Space Reclamation bei Thin Provisioned vDisks.

Da weder VMFS3, noch VMFS5 eine automatisierten Möglichkeit bieten, Thin Provisioned vDisks auf ihre eigentlich Größe zu schrumpfen muss der Administrator selbst tätig werden. Dazu gibt es 3 Möglichkeiten:

  • ungenutzte Blöcke mit Nullen füllen, und anschließende Deallokierung von genullten Blöcken mit vmkfstools (Punch Zeros - erfordert, dass die VM nicht läuft)
  • Storage vMotion zwischen 2 Datastores unterschiedlicher Blockgrößen (funktioniert nur zwischen VMFS3 und VMFS5, sowie von einem VMFS3 zu einem anderen)
  • ungenutzte Blöcke mit Nullen füllen, und anschließendes Storage vMotion mit Änderung des vDisk Provisioning Formats (funktioniert auch, wenn die VM läuft)

1. Punch Zeros mit vmkfstools

Hier die Kurzfassung (ohne zu sehr ins Detail gehen zu wollen) was passiert, wenn man innerhalb einer VM eine Datei im Dateisystem anlegt und wieder löscht. Es wird angenommen, dass dazu eine 1MB große Datei aus dem Internet geladen wird, und auf einem Dateisystem gespeichert wird, welches über eine 1K-Blockung verfügt.

Das Betriebssystem erkennt, dass eine 1MB große Datei nicht in einen 1K Block passt. Die Datei muss also fragmentiert werden. Die Fragmente werden in (im Idealfall in aufeinanderfolgende) Blöcke geschrieben, zusätzlich werden noch Metadaten geschrieben und auch die Information in welchen Blöcken sich die Datei befindet. Anschließend wird durch den Nutzer die Datei wieder gelöscht. Dabei werden aber nicht die Blöcke (in denen sich ja die fragmentierte Datei befindet) gelöscht, sondern nur die Information, in welchen Blöcken die Datei zu finden ist. Damit wurden diese Blöcke freigegeben, um wieder neu beschrieben zu werden.

Für eine Thin Provisioned VMDK bedeutet dies, dass sich die Größe der vDisk nach dem herunterladen und dem löschen der Datei nicht geändert hat. Aus Sicht von VMware handelt es sich um Dead Space, der zwar allokiert ist, aber nicht genutzt wird.

Nun ist die Größe von 1MB nicht tragisch. Ärgerlich wird es erst, wenn das Dateisystem mal 2TB groß war, und nun nur noch 500GB groß ist. Also ~1,5TB toter Speicher vorhanden ist.

Um diesen Speicher für VMware wieder freizugeben, müssen nicht-allokierte Blöcke innerhalb der VM mit nullen gefüllt werden. Unter Linux sieht das so aus, dass man einfach eine Datei „mit Nullen füllt“ und diese Datei dann wieder löscht:

dd if=/dev/zero of=/home/zeroes bs=4096 ; rm -f /home/zeroes

dd schreibt hier alles, was aus /dev/zero kommt (0x00 Sequenzen), in die Datei /home/zeroes, bis das Dateisystem von /home/ voll ist. Anschließend wird die Datei wieder gelöscht. Damit werden alle ungenutzten Blöcke gefüllt. Aber Achtung: Aus Sicht von VMware wächst die Thin Provisioned vDisk! Ist das konfigurierte Limit z.B. 2TB, ist nach dem Löschen der Datei (in der VM) auch die vDisk 2TB groß.

Da das „punchen“ von Nullen mit vmkfstools leider nicht im laufenden VM-Betrieb funktioniert, muss das virtuelle System heruntergefahren werden. Anschließend meldet ihr euch per SSH auf dem ESXi Host an und wechselt in das Verzeichnis, in dem euer Datastore eingebunden ist:

cd /vmfs/volumes/datastore/VM/

Dort findet ihr nun mindestens 2 Dateien mit der Endung .vmdk. Hier ein Beispiel:

-rw------- 1 root root 20.0G Feb 24 18:52 virtuelleMaschine01-flat.vmdk
-rw------- 1 root root   530 Feb 20 15:00 virtuelleMaschine01.vmdk

Die Datei virtuelleMaschine01-flat.vmdk ist die vDisk, die eure Daten enthält, virtuelleMaschine01.vmdk ist das Meta-File, welches die Beschreibung dazu enthält, also die Konfiguration. Mittels cat könnt ihr euch auch den Inhalt des Meta-Files ansehen.

Um aus der vDisk den toten Speicher zu entfernen, führt ihr folgenden vmkfstools-Befehl aus:

vmkfstools -K virtuelleMaschine01.vmdk

Beachtet, dass ihr nicht mit der vDisk selbst arbeitet, sondern mit dem Meta-File! Abhängig von der Größe der vDisk, und dem Zugriff auf den Datastore (lokale HDDs, NFS, iSCSI, FC) dauert der Prozess Minuten oder Stunden. So oder so, die abschließende Ausgabe sieht etwa wie folgt aus:

# vmkfstools -K virtuelleMaschine01.vmdk
vmfsDisk: 1, rdmDisk: 0, blockSize: 1048576
Hole Punching: 100% done.

Die VM kann nun wieder gestartet werden. Die vDisk sollte mit dem kleinstmöglichen Speicherbedarf laufen.

2. Datastores mit unterschiedlichen Blockgrößen

Die 2. Möglichkeit besteht darin, dass eine VM im laufenden Zustand via Storage vMotion von einem Datastore zu einem anderen verschoben wird. Wichtig ist hierbei, dass sich die Blockungen der Datastores unterscheiden, was die Migration auf folgende Wege einschränkt:

  • Migration von VMFS3 (2, 4 oder 8MB Blockung - aber nicht 1MB) zu VMFS5 (1MB Blockung)
  • Migration von VMFS5 (1MB Blockung) zu VMFS3 (2, 4 oder 8MB Blockung - aber nicht 1MB)
  • Migration von VMFS3 (1, 2, 4 oder 8MB Blockung) zu VMFS3 (jede Blockung, außer der des Quell-Datastores)

Die Blockung ist in diesem Falle deshalb so wichtig, da davon abhängt, welche Methode zum klonen des VMDKs verwendet wird. Bei einer geänderten Blockung wird die vDisk mittels Disk based cloning auf den neuen Datastore übertragen. Dabei werden alle Blöcke übertragen, die nicht genullt sind, egal ob die Quell Disk Thin Provisioned ist oder nicht - Hauptsache die Ziel Disk ist es.

Auch hier muss vorab der freie Speicher mit Null-Blöcken beschrieben werden:

dd if=/dev/zero of=/home/zeroes bs=4096
rm -f /home/zeroes

Der Vorteil dieser Methode ist, dass die Rückgewinnung des toten Speichers im laufenden Betrieb der VM erfolgen kann. Allerdings gibt es bei der Verwendung von VMFS3, abhängig von der Blockung, Limitierungen bei der Größe von Dateien innerhalb von VMFS3:

  • 1MB Blockung - max. 256GB pro Datei
  • 2MB Blockung - max. 512GB pro Datei
  • 4MB Blockung - max. 1TB pro Datei
  • 8MB Blockung - max. 2TB pro Datei

3. Storage vMotion mit Änderung des vDisk Provisioning Formats

Die letzte Möglichkeit (mit VMware Board-Mitteln zumindest) besteht darin, dass 2 Storage vMotion-Operationen gestartet werden, bei denen die vDisk vom Datastore A zum Datastore B verschoben werden, und abschließend wieder zurück zu Datastore A. Mit jeder Migration ändert sich das vDisk Provisioning Format:

  • Migration: Thin Provisioned auf Datastore A –> Thick Provisioned auf Datastore B
  • Migration: Thick Provisioned auf Datastore B –> Thin Provisioned auf Datastore A

Dabei ist es unerheblich, ob bei der Thick Provisionierung die vDisk Lazy- oder Eager-Zeroed ist. Wichtig ist nur, dass sich das Format ändert.

Auch hier ist es wieder so, dass vor der 2. Migration zur Thin Provisioned vDisk die ungenutzen Blöcke mit Nullen beschrieben werden müssen:

dd if=/dev/zero of=/home/zeroes bs=4096
rm -f /home/zeroes

Aber auch hier ergibt sich ein Nachteil, so muss auf dem Datastore B, auf den die voll provisionierte vDisk kopiert wird, auch diese Größe vorweisen können.

Dieser Weg der Rückgewinnung von Dead Space wird die wohl am weitesten verbreitete Variante sein, da es sicherlich kaum VMware Cluster gibt, bei denen Projekte über Stunden hinweg offline sein dürfen, oder bei denen Mischumgebungen in der VMFS Version zum Einsatz kommen. Zudem ist sie auch für den Admin die Bequemste ;-)

VMware VAAI Thin Provisioning Block UNMAP

Seit vSphere 5.0 gibt es noch VAAI Thin Provisioning Block UNMAP, welches ich an dieser Stelle noch erwähnen möchte, um mögliche Irrtümer zu vermeiden.

Beim VAAI Thin Provisioning, was die SAN unterstützen muss, lassen sich iSCSI LUNs Thin Provisioned anlegen. Wenn meine SAN also 20TB groß ist, kann ich z.B. 2 LUNs erstellen, die beide 15TB groß sind. Wie auch bei einer Thin Provisioned vDisk wächst hier der Speicherbedarf der LUN. Eine (kontrollierte) Überbuchung ist somit also ebenso möglich. Wird eine VM von einem Thin Provisioned LUN auf ein anderes verschoben, kann ein Block UNMAP den allokierten Speicherbereich in der LUN wieder freigeben. Damit lassen sich das Monitoring, Reporting und auch die Planung für zukünftige Speicher Anforderungen wesentlich genauer spezifizieren.

Einen wirklich tollen Artikel zu der ganzen Thematik findet man auch auf blogs.vmware.com.

Diskussion

Geben Sie Ihren Kommentar ein. Wiki-Syntax ist zugelassen:
 
blog/vmware_-_dead_space_reclamation_bei_thin_provisioned_vdisks.txt · Zuletzt geändert: 2016/03/08 13:43 von Daniel Graf