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. Es stellen sich Fragen wie etwa: Funktioniert die Komprimierung gut? Klappt die Deduplizierung?
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.
Es gibt eine ganze Reihe von Vorteilen von Thin Virtual Disks – und dabei geht vor allem um deren Flexibilität. Einer der Hauptvorteile ist der UNMAP-Befehl, worüber dieser Blog berichtet:
Was ist eine Thin Virtual Disk? Es ist ein Laufwerk, dem eine logische Größe zugewiesen wird und das einer virtuellen Maschine präsentiert wird. Wird also eine 50 GB große Thin Virtual Disk erstellt, sieht die virtuelle Maschine eine 50-GB-„Platte“, die für jedes beliebige Dateisystem verwendet werden kann. Auf dem VMFS wird eine VMDK-Datei erzeugt, in die Daten geschrieben werden können. Das grundlegende Merkmal einer Thin Virtual Disk ist, dass die Datei, die die virtuelle Platte „ist“, nicht 50 GB auf dem VMFS einnimmt. Sie nimmt nur dann Platz ein, wenn die VM darauf schreibt. Wenn die VM also 5 GB Daten schreibt, nimmt diese virtuelle Platte 5 GB Daten auf dem VMFS auf.
Es gibt natürlich auch einige Performance-Fragen rund um „Thin“. Weitere Informationen hierzu finden sich hier:
Pure Storage FlashArray and Re-Examining VMware Virtual Disk Types
Erstellen einer Thin Virtual Disk
Hier ist ein leeres VMFS:
„Leer“ bedeutet, abgesehen von den VMFS-Metadaten, die hier 1,47 GB ausmachen. Schauen wir uns nun das Array selbst an:
Werden 1,47 GB auf 2 MB reduziert? Nein, das Array meldet ein Datenreduktionsverhältnis von 21,3:1. So werden tatsächlich nur etwa 40 MB geschrieben. Es gibt viele VMFS-Datenspeicher auf diesem Array, so dass die überwiegende Mehrheit dieser VMFS-Metadaten dedupliziert ist.
Der Punkt ist, dass es drei Dinge gibt, die diese Diskrepanz verursachen:
- Zugeteilt vs. geschrieben. ESXi verteilt aus vielen Gründen Speicherplatz auf dem Dateisystem, wobei virtuelle Festplatten die primären Festplatten sind, aber oft nicht sofort etwas schreiben. Dem Array ist diese Zuordnung also nicht bekannt. Eine virtuelle Plattenzuordnung ist eine METADATA-Änderung auf VMFS. Es werden keine Daten auf das Array geschrieben, daher die Diskrepanz.
- Datenreduktion. Was tatsächlich von ESXi (oder seinen VMs) geschrieben wird, wird durch das Array zumindest etwas reduziert. Der Array-Footprint ist also kleiner, daher auch hier die Diskrepanz.
- Zero Removal. Pure Storage nimmt Dinge wie das Auslassen von Nullen nicht in das Datenreduktionsverhältnis auf. Wenn also die Daten, die geschrieben werden, tatsächlich ein Haufen Nullen sind, werden sie nicht wirklich auf dem FlashArray reflektiert. Ein Großteil des VMFS-Metadatenbereichs wird bei der Erstellung auf Null gesetzt, woher ebenfalls die Diskrepanz herrührt.
Legen wir also eine 40 GB große Thin Virtual Disk auf das VMFS.
Wie funktioniert eine Thin Virtual Disk? Sie wird nur bei Bedarf zugeteilt. Da die Daten schließlich vom Gast geschrieben werden, dehnt sie sich blockweise aus, setzt diese Blöcke dann auf Null und überträgt die Daten.
Hier ist das VMFS, nachdem eine Thin Virtual Disk hinzugefügt wurde:
Es befinden sich immer noch nur 1,47 GB auf dem VMFS, also gab es keine Änderung.
Es befinden sich immer noch 2,31 MB auf dem FlashArray.
Wenn wir uns die VMDK-Datei ansehen, sehen wir, dass sie tatsächlich 0 KB groß ist:
„Auf Null stellen“ einer Thin Virtual Disk
Um das „Auf Null stellen“-Verhalten zu verdeutlichen, schreiben wir zuerst Nullen. Bei einer Windows-Maschine, wie in diesem Fall, wird sdelete benutzt, um Nullen zu schreiben, was die einfachste Option ist.
Dadurch werden Nullen auf die Gesamtheit des Laufwerks E: geschrieben, also alle 40 GB. Nachdem der Prozess abgeschlossen ist, meldet Windows immer noch das NTFS auf der Thin Virtual Disk als leer:
Aber was ist mit dem VMDK selbst?
Über 40 MB werden angezeigt. VMware weiß nicht, was geschrieben wurde und weiß nicht, dass alles nutzlose Nullen waren. ESXi hat natürlich Schreibzugriffe auf Blöcke erfasst, diese Blöcke zugewiesen – und damit die Thin Virtual Disk (die VMDK-Datei) vergrößert. Die Daten wurden dann an das Array gesendet.
11,57 MB werden angezeigt. Dies liegt daran, dass das FlashArray alle Nullen verwirft. Da keine Nullen in das Datenreduktionsverhältnis aufgenommen werden, ändert es sich auch nicht.
Das vorläufige Ergebnis: Windows sieht null GB. VMFS sieht 40 GB. Das FlashArray sieht im Wesentlichen null GB. Wenn wir also drei Beteiligte haben (Windows-Admin, VMware-Admin und Storage-Admin), sind zwei glücklich (Windows/Storage) und einer nicht (VMware).
Ist es möglich, die virtuelle Festplatte zu verkleinern? Ja. VMware hat in vmkfstools eine Funktion namens „punchzero“, die verwendet werden kann, um eine virtuelle Festplatte zu lesen und Blöcke zu entfernen, die alle Null sind, wodurch die virtuelle Festplatte effektiv verkleinert wird. Hierbei handelt es sich jedoch um ein Offline-Verfahren. Die virtuelle Platte muss entweder aus der VM entfernt oder die VM heruntergefahren werden, wie hier beschrieben:
https://kb.vmware.com/s/article/2004155
Schreiben auf eine Thin Virtual Disk
Lassen Sie uns nun das virtuelle Laufwerk neu starten, löschen und neu erstellen.
Hierbei wird vdbench genutzt, um eine Datei ungleich Null zu erstellen und das Laufwerk E: (das sich auf der Thin Virtual Disk befindet) aufzufüllen.
Wenn wir uns das VMFS ansehen, sehen wir, dass das VMDK wieder auf 40 GB angewachsen ist:
Wenn wir uns das FlashArray ansehen:
Es werden 5,6 GB gemeldet. So hat die FlashArray-Datenreduktion die von der VM (vdbench) geschriebenen 40 GB Daten physisch auf 5,6 GB reduziert. Windows meldet also 40 GB, VMFS erfasst 40 GB und das FlashArray 5,6 GB. In diesem Fall ist die Diskrepanz auf die Reduzierung der FlashArray-Daten zurückzuführen.
Löschen von Daten auf einer Thin Virtual Disk
Was passiert, wenn wir diese von VDBench erstellte Datei aus dem NTFS auf der Thin Virtual Disk löschen?
Nun ist NTFS auf dem VMDK leer:
Das VMFS meldet die VMDK-Datei jedoch immer noch mit 40 GB:
Und auch das FlashArray ändert seine Berichterstattung nicht:
Jetzt meldet Windows 0 GB. VMFS meldet 40 GB. Das FlashArray meldet 5,6 GB.
- Das Gastbetriebssystem (in diesem Fall Windows) meldet, wie viel es gerade geschrieben hat. Dies ist jetzt Null. Die Datei wurde gelöscht.
- VMFS meldet, wie viel zugeteilt wurde. Wenn das Geschriebene weg ist, wird die Allokation nicht aufgehoben, da dies zwei verschiedene Dinge sind. VMFS weiß nicht, dass die Datei in der VM gelöscht wurde, so dass die zugewiesene Größe der virtuellen Festplatte bei 40 GB bleibt.
- 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 Array nicht bekannt. Die genaue Größe des Footprints hängt davon ab, wie/ob das Array die Datenreduktion nutzt.
Das sind alles unterschiedliche Metriken und bedeuten daher unterschiedliche Dinge.
Wie bringen wir VMware und das Array dazu, die tatsächliche Nutzung durch den Gast widerzuspiegeln? Es gibt es mehrere Methoden, die sich normalerweise auf zwei Möglichkeiten reduzieren:
- Nullen schreiben
- In-Guest-UNMAP
Das Schreiben von Nullen wird von allen Versionen von ESXi in allen Konfigurationen unterstützt, also sehen wir uns das zuerst an.
Rückgewinnung von Speicherplatz durch Nullsetzen einer Thin Virtual Disk
Mittels sdelete lässt sich auf Windows (oder dd von /dev/zero für Linux) der freie Speicherplatz im Dateisystem auf Null setzen. Die meisten Arrays haben heutzutage die Möglichkeit, Nullen automatisch zu entfernen (wie das FlashArray) oder ein Verfahren zur Rückgewinnung von Null Speicherplatz, das nachträglich ausgeführt werden kann.
Wird sdelete gestartet, ändert sich die VMDK-Größe nicht, sie beträgt immer noch 40 GB.
Das liegt daran, dass ESXi nur schreibt. Die Belegung des VMDK ist bereits voll, so dass keine Änderungen erforderlich sind.
Das FlashArray reagiert jedoch.
Das FlashArray sieht, dass die neuen Daten geschrieben werden, also verwirft es die vorherigen Daten. Da die neuen Daten alle Nullen sind, werden diese ebenfalls verworfen.
Die virtuelle Festplatte meldet aber immer noch 40 GB. Dies liegt daran, dass niemand VMFS mitgeteilt hat, dass die Daten nicht benötigt werden.
Um das VMDK zu verkleinern, muss man VMware sagen, dass es die Nullen zurückfordern soll. Dies kann durch Entfernen des VMDK von der VM geschehen oder durch Herunterfahren der VM und Ausführen von vmkfstools punchzero:
Der Nachteil ist natürlich, dass dies offline erfolgt.
Wenn das Entfernen der Nullen beendet ist, ist das VMDK verkleinert, von 40 GB bis auf ca. knapp MB.
Die bessere Möglichkeit ist UNMAP, was online erfolgt, jedoch gibt es auch hier Einschränkungen.
Rückgewinnung von Speicherplatz mit UNMAP in einer Thin Virtual Disk
In-Guest-UNMAP erlaubt es dem Gastbetriebssystem, UNMAP-SCSI-Befehle an das Dateisystem auf einem VMDK an Blöcke auszugeben, die nicht verwendet werden, was wiederum von ESXi abgefangen wird. ESXi verkleinert dann das virtuelle Laufwerk und entfernt das VMDK, an das die UNMAP-Operationen gesendet wurden. Je nach Konfiguration gibt ESXi dann UNMAP an das zugrundeliegende Volume auf dem Array aus. Das Array empfängt UNMAP und entfernt einfach die Speicherzuweisungen, die es für diese Blöcke hat. Somit erfolgen alle Nullstellungsschritte in einem integrierten Online-Verfahren.
Wie das geht, erfahren Sie in den folgenden Blog-Einträgen:
In-Guest UNMAP Fix in ESXi 6.5 Part I: Windows
What´s new in ESXi 6.5 Storage Part I: UNMAP
Es gelten folgende Einschränkungen:
- Die virtuelle Platte muss eine Thin Virtual Disk sein.
- Damit Windows funktioniert, muss mindestens ESXi 6.0 vorliegen.
- Damit Linux funktioniert, muss ESXi 6.5 vorliegen.
- Wenn Change Block Tracking auf dieser VM aktiviert ist, muss die ESXi-Version 6.5+ sein.
- Wenn das VMDK einen VMware-Snapshot hat, funktioniert es nicht.
- Bei VMFS-5 muss die ESXi-Option EnableBlockDelete aktiviert sein, damit UNMAP an das Array gesendet wird.
- Für VMFS-6 muss die automatische Reklamation aktiviert sein, damit UNMAP an das Array gesendet werden kann.
Ein Beispiel ist eine Thin Virtual Disk mit NTFS, worauf 40 GB Daten geschrieben wurden:
Das bedeutet, dass das VMFS die VMDK-Datei mit 40 GB anzeigt:
Und schließlich sind es 5,67 GB auf dem FlashArray (wegen der Datenreduktion):
Die Datei wird jetzt gelöscht. Anstelle der Nullstellung kann man die UNMAP-Route wählen, da die Voraussetzungen dafür sind.
Windows kann dies automatisch tun (was standardmäßig aktiviert ist, oder manuell über das Tool „Disk Optimizer“ oder „optimize-drive“ von PowerShell erfolgen kann).
Windows gibt UNMAP aus (zuvor gilt es sicherzustellen, dass DisableDeleteNotify in Windows auf 0 gesetzt ist, dies sollte der Standard sein). UNMAP wird an das VMDK gesendet und ESXi schrumpft das VMDK um die Anzahl der Blöcke, die in der VM zurückgefordert wurden. Das VMDK ist also wieder auf ca. 80 MB – von ursprünglich 40 GB.
Wenn wir uns das FlashArray ansehen, wird auch der Platz zurückgewonnen.
Und mit der Zeit sieht es so aus:
UNMAP im Gastmodus ist es also, womit sich die Anwendung und die VMware-Schicht genau aufeinander abstimmen lassen. Dies wird durch die Verwendung von Thin Virtual Disks ermöglicht.
Löschen einer Thin Virtual Disk
Was passiert, wenn wir die virtuelle Festplatte löschen? Dann wäre sie aus der VM und dem VMFS entfernt. Aber woher weiß das Array das? Nun, das tut es nicht von Haus aus. Das Löschen eines VMDKs ist dem Löschen einer Datei in einer VM sehr ähnlich, denn die darunterliegende Ebene weiß nichts davon.
Das VMDK wurde wieder aufgefüllt:
Dann wurde es gelöscht:
Das VMFS wird wieder auf 1,47 GB zurückgesetzt:
Aber das Array-Volumen meldet immer noch den belegten Speicherplatz:
Wie lässt sich dieser Speicherplatz zurückfordern? Nun, das nennt man VMFS UNMAP. 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 möglich unter Verwendung des Befehls esxcli storage vmfs UNMAP, wie in diesem Beitrag zu VMware Dead Space Reclamation (UNMAP) and Pure Storage beschrieben.
- In VMFS-6 erfolgt es automatisch, wie in diesem Beitrag dargestellt: 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 I – Schlussfolgerung
Am Ende ist die Koordination zwischen den verschiedenen Schichten schwierig, obwohl die Flexibilität von Thin Disks es ein wenig einfacher macht. Es gibt zwei Kommunikationsrichtungen im Storage-Stack, nämlich von unten nach oben und von oben nach unten.
Der Prozess beginnt mit dem Array, das angibt, wie viel Kapazität ein Volume bieten kann. ESXi nimmt diese Zahl und erstellt ein Dateisystem. Der VMware-Benutzer nimmt dann einen Teil davon und stellt ihn der VM als Volume zur Verfügung, dies ist eine virtuelle Festplatte. Das VM-Betriebssystem legt daraufhin ein Dateisystem an, um diesen Speicherplatz für Anwendungen darzustellen und zu verfolgen. Das ist wirklich die einzige Kommunikation von unten nach oben. Der Rest geht von oben nach unten. Es gibt keinen Mechanismus für das Array, um zu sagen: „Hey, nein, du hast schon so viel geschrieben“. Denn am Ende ist die oberste Ebene der wahre Schiedsrichter.
Der größte Teil der Kommunikation geht von oben nach unten. Ein VM OS schreibt Daten. Dadurch werden die Metadaten des Dateisystems geändert und einige Daten übertragen. Diese Daten werden dann auf die virtuelle Platte geschrieben. In der Thin-Welt, wird damit dem VMDK mitgeteilt, dass es wachsen soll. Es darf so lange wachsen, bis sein beschriebener Inhalt der erstellten Größe entspricht. Diese geschriebene Größe wird in VMFS als die zugewiesene Größe der Festplatte wiedergegeben.
Diese Daten werden dann in den Speicher geschrieben und der Speicher wird bei Bedarf reduziert (oder erweitert). Wenn es keine Datenreduktion gibt, kann es tatsächlich mehr Platz beanspruchen, wegen RAID-Overheads etc.
Thin Provisioning ist ein Konzept, das es erlaubt, dass die darunterliegende Schicht nur das wiedergibt, was geschrieben wurde – durch die Zuweisung eines Blocks. Aber wenn etwas einmal geschrieben ist, bleibt es so. Auch wenn sich das Geschriebene ändert, bleibt die Zuordnung bestehen.
Um diese Diskrepanz zu beheben, wird UNMAP verwendet. UNMAP sagt der Ebene unten: „Ja, ich weiß, dass ich das einmal geschrieben habe, aber ich brauche es nicht mehr“. Dies wird übersetzt vom Gast ins VMDK in Form einer VMDK-Verkleinerung. Das VMFS übersetzt es in das Array als die physischen Blöcke, die ausgelagert und freigegeben werden.
Mit anderen Worten, UNMAP teilt der darunterliegenden Schicht mit, dass sich etwas geändert hat und Daten nicht mehr benötigt werden. Dies wird vom Gast und in ESXi benötigt. Durch die UNMAP-Ausführung wird die Größe der virtuellen Festplatte an das Dateisystem des VM-Betriebssystems angepasst. Und dann richtet sich das Speichervolumen nach dem, was VMFS als verwendet betrachtet.
Daher ist es wichtig zu verstehen, wie ein Array Daten ausgibt. Die VMFS-Schicht und die VM-Schicht sind konsistent. Arrays funktionieren anders. Dies ist ein Hauptgrund, warum VMFS nicht die Datenreduktion erfassen kann. Es gibt zu viel Variation und keinen Override-Mechanismus.
Der nächste Beitrag behandelt das Thema Speicherkapazitätserfassung unter VMware.
