Das Thema Speicherkapazität scheint ziemlich einfach zu sein: Wieviel Speicher wird benötigt? Sollen jedoch mehrere Ebenen von Thin Provisioning und Datenreduktion umgesetzt werden, wird es komplizierter: Funktioniert die Komprimierung gut? Klappt die Deduplizierung? Etc.
Anmerkung: Die Beispiele hierfür werden aus FlashArray-Perspektive aufgeführt und die Rahmenbedingungen variieren je nach Art des Arrays. VMware VMFS (Virtual Machine File System) und die obere Schicht sind jedoch für alle Beispiele gleich. Dies ist der Vorteil von VMFS, es abstrahiert die physische Ebene. Das ist auch der Nachteil, wie in diesem Beitrag beschrieben wird.
Thick Virtual Disks und VMFS
Eager Zero Thick (EZT), was in etwa für „zwingend durchgängige Nullen“ steht, ist die ursprüngliche Form der virtuellen Festplatten. Früher war es die Standardeinstellung und ist immer noch weit verbreitet.
Anmerkung: Dieser Beitrag konzentriert sich auf EZT, nicht auf Zero Thick Virtual Disks, aber für diese Zwecke sind sie im Grunde gleich. Der einzige Unterschied besteht darin, dass zwingend durchgängig Nullen geschrieben werden. Bei einem Zero-Removing-Array ist dieser Unterschied daher irrelevant.
Im Gegensatz zu Thin Virtual Disks sind EZT-Laufwerke nicht besonders flexibel. Aber sie haben einen primären Nutzen: Performance.
Thin Virtual Disks weisen nur dann Speicherplatz zu, wenn er benötigt wird. Wenn ein neuer Schreibvorgang von einer VM eintrifft, wird die VMDK-Datei auf dem VMFS expandiert und dieser Block wird dann auf Null gesetzt (mit WRITE SAME). Dann wird das Schreiben bestätigt. Dies geschieht jedes Mal, wenn ein neuer Block geschrieben wird. Sobald dieser Block in diesen Prozess geschrieben wurde, muss er nicht mehr wiederholt werden.
Eager Zeroed Thick geht hier anders vor: Wenn ein EZT-Laufwerk erstellt wird, wird die gesamte potenzielle Kapazität des virtuellen Laufwerks auf dem VMFS zugewiesen und es wird auch vollständig auf Null gesetzt, bevor es überhaupt von einem Gast verwendet werden kann. Das bedeutet, dass die neue Latenzzeit kein Faktor für EZT ist, obwohl es bedeutet, dass die Erstellung länger dauert.
Dieser Leistungsunterschied ist zwar gering, aber nicht gleich Null. Für Anwendungen, die sehr latenzempfindlich sind, ist EZT die bessere Wahl. Nun geht es jedoch erst einmal um die Kapazität.
Erstellen einer virtuellen EZT-Festplatte
Bevor eine virtuelle Festplatte erstellt wird, gilt es, die Konfiguration zu überprüfen. Der Ausgangspunkt ist ein leeres VMFS (außer einigen VMFS-Metadaten):
Das zugrundeliegende Volume ist ebenfalls leer (mit Ausnahme dieser Metadaten):
Nun wird ein 40-GB-EZT-Laufwerk erstellt.
Einmal erstellt, nimmt es sofort die gesamten 40 GB Speicherplatz auf dem VMFS in Anspruch:
Auf dem Array gibt es keine Veränderung:
Dies liegt daran, dass, obwohl es einen Haufen Nullen schreibt, alle durch Datenreduktion verworfen werden.
Zusätzlich zu diesem EZT VMDK liegt ein leeres NTFS vor:
Zusammengefasst haben wir also 0 GB in der VM, 40 GB in VMFS und 0 GB im FlashArray. Das ist der natürliche Zustand von EZT.
Schreiben auf eine virtuelle EZT-Festplatte
Nun werden einige Daten hinzugefügt, z.B. ca. 20 GB. Dabei kommt VDBench zum Einsatz, um eine 20 GB große Datei mit Daten ungleich Null zu schreiben.
Wie erwartet, gibt es keine Änderung in der Größe des virtuellen Laufwerks. Es werden immer ca. 40 GB sein:
EZT berichtet immer in der Größe, in der es erstellt wurde – ungeachtet der Tatsache, dass es nur halb voll ist.
Das FlashArray meldet jedoch den Platzbedarf:
Dies sind ungefähr 3 GB. Obwohl 20 GB geschrieben wurden, reduzierte das FlashArray diese Daten auf 3 GB. Somit liegen jetzt 20 GB in der VM, 40 GB im VMFS und 3 GB im Array vor.
Bei EZT-Festplatten spielt es keine Rolle, wie viel aus VMFS-Perspektive geschrieben wird. Der Platz ist immer reserviert. Aus der Sicht von FlashArray sieht es nicht anders aus als bei einer Thin Virtual Disk.
Möglicherweise liegt in der Umgebung kein FlashArray oder ein anderes Array vor, das automatisch Nullen entfernt. So gibt es Arrays, die dazu nicht in der Lage sind. Oder es handelt sich um ein Array, das nur bei Bedarf zusammenhängende Nullen entfernen kann. Auf der Array-Seite kann die Laufleistung also variieren. Wenn das Array keine Nullen entfernt, wären die Datenvolumina 40 GB/40 GB/40 GB/40 GB, was es etwas schwieriger macht, herauszufinden, wann etwas geschrieben wurde. Dies unterstreicht einmal mehr, wie wichtig es ist, zu verstehen, wie ein Array Daten speichert.
Löschen von Daten auf einem virtuellen EZT-Laufwerk
Was passiert, wenn Daten in der VM auf einem Dateisystem auf einem virtuellen EZT-Laufwerk gelöscht werden?
Damit ist das NTFS wieder leer:
Aber das VMFS zeigt immer noch an, dass die EZT-Festplatte 40 GB groß ist:
Und das FlashArray meldet immer noch, dass knapp 3 GB verbraucht wurden:
Das NTFS meldet also 0 GB, VMFS 40 GB und das Array 3 GB.
Darüber sollte man kurz nachdenken:
- Das Gastbetriebssystem (in diesem Fall Windows) meldet, wie viel es gerade geschrieben hat. In diesem Fall ist dies jetzt Null. Die Datei wurde gelöscht.
- VMFS meldet, wie viel zugeteilt wurde. Bei EZT entspricht die Zuordnung immer der Größe des virtuellen Laufwerks.
- Das Array meldet den physischen Abdruck dessen, was zuletzt geschrieben wurde. Es bleibt so, bis es überschrieben wird. Wenn etwas einfach gelöscht wird und es kein Überschreiben gibt, ist das dem Array nicht bekannt. Die genaue Größe des Abdrucks hängt davon ab, wie/ob das Array die Datenreduktion nutzt.
Das sind alles unterschiedliche Metriken und bedeuten daher unterschiedliche Dinge.
Wie bringen wir aber VMware und das Array dazu, die tatsächliche Nutzung durch den Gast widerzuspiegeln? Gut gibt es eine Vielzahl von Methoden, aber diese reduzieren sich normalerweise auf zwei Möglichkeiten:
- Nullen schreiben
- In-Guest UNMAP
Im Gegensatz zu Thin Virtual Disks ist UNMAP keine Option. Ein einfacher Weg, dies unter Windows zu beweisen, ist die Verwendung des Tools „Laufwerke optimieren“.
Das Laufwerk E:, das als EZT-Volume dient, wird nicht als „dünn“ bereitgestellt gemeldet. Windows gibt also keine UNMAP aus. Für andere Betriebssysteme lässt sich die VPD-Seite auf logische Blockbereitstellung überprüfen. Wenn die UNMAP-Unterstützung mit 0 angegeben ist, wird UNMAP nicht unterstützt. Also bleibt nur noch der Nullabgleich.
Rückgewinnung von Speicherplatz durch Nullsetzen einer virtuellen EZT-Festplatte
Um den Platz auf dem Array zurückzugewinnen, gilt es VMware im Wesentlichen zu umgehen. Wenn das Array auf Null ist, ist dies die einfachste Option im Falle von EZT-Platten.
Deswegen werden die 20 GB Daten aus dem NTFS gelöscht, und das darunter befindliche Array soll dies auch widerspiegeln. UNMAP funktioniert hier nicht, daher muss aktiv ausgenullt werden. Im Windows-Beispiel erfolgt dies mit sdelete.
Dadurch wird der gesamte freie Speicherplatz auf dem VMDK gelöscht. Es gibt keine Speicherplatzeinbuße durch „Aufblähung“, im Gegensatz zu Thin Virtual Disks, denn die virtuelle Festplatte ist ja bereits auf ihre volle Größe ausgedehnt.
Im VMFS ändert sich nichts, wie erwartet:
Aber auf dem FlashArray wird alles zurückgewonnen:
Wir sind zurück zu unseren ursprünglichen 0 GB auf NTFS, 40 GB auf VMFS und 0 GB auf dem FlashArray.
Löschen einer virtuellen EZT-Festplatte
Die letzte Sache ist das Löschen einer virtuellen EZT-Festplatte. Wenn ein EZT-Laufwerk gelöscht wird, wird es aus der VM und auch aus dem VMFS entfernt.
Die Platte ist nun vom VMFS verschwunden:
Das Array hat noch Daten:
Somit gibt es keine Festplatte in der VM, 0 GB im VMFS und 3 GB „toter Speicherplatz“ auf dem Array.
Dies setzt voraus, dass VMFS UNMAP ausgeführt wird. Wenn eine Datei aus VMFS gelöscht wird, muss UNMAP an das Array ausgegeben werden, um ihm mitzuteilen, dass der Platz frei ist.
- In VMFS-5 ist dies manuell unter Verwendung des Befehls esxcli storage vmfs UNMAP, wie in diesem Beitrag zu VMware Dead Space Reclamation (UNMAP) und Pure Storage beschrieben.
- In VMFS-6 erfolgt es automatisch, wie in diesem Beitrag zu sehen ist: What´s new in ESXi 6.5 Storage Part I: UNMAP
Einmal ausgeführt (egal ob VMFS-6 es automatisch gemacht hat oder ob es für VMFS-5 über ein Skript oder ähnliches ausgeführt wurde), wird der Platz auf dem Array zurückgewonnen.
Teil II – Schlussfolgerung
Die Berechnung der Speicherplatzmenge ist also etwas komplizierter bei Eager Zeroed Thick oder Zeroed Thick Disks, da es schwieriger ist, zu erkennen, ob im Gastsystem selbst toter Speicherplatz vorhanden ist. Da die VMDK-Größe nicht aussagt, was aus VMDK-Sicht geschrieben worden ist, lässt sich nicht vergleichen, was der VM-Gast „weiß“ und was er tatsächlich schreibt. Dies gilt vor allem, wenn sich mehr als ein VMDK im Datenspeicher befindet.
Der nächste Beitrag behandelt das Thema VMFS und Kapazitäts-Reporting.
