{"id":52428,"date":"2018-10-17T18:03:45","date_gmt":"2018-10-17T09:03:45","guid":{"rendered":"https:\/\/blog.everpuredata.com\/?p=52428"},"modified":"2025-03-17T03:26:13","modified_gmt":"2025-03-17T10:26:13","slug":"speicherkapazitaetserfassung-unter-vmware-teil-i-vmfs-und-thin-virtual-disks","status":"publish","type":"post","link":"https:\/\/blog.everpuredata.com\/de\/purely-technical\/speicherkapazitaetserfassung-unter-vmware-teil-i-vmfs-und-thin-virtual-disks\/","title":{"rendered":"Speicherkapazit\u00e4tserfassung unter VMware \u2013 Teil I: VMFS und Thin Virtual Disks"},"content":{"rendered":"

Das Thema Speicherkapazit\u00e4t scheint ziemlich einfach zu sein: Wieviel Speicher wird ben\u00f6tigt? Sollen jedoch mehrere Ebenen von Thin Provisioning und<\/em> Datenreduktion umgesetzt werden, wird es komplizierter. Es stellen sich Fragen wie etwa: Funktioniert die Komprimierung gut? Klappt die Deduplizierung?<\/p>\n

Anmerkung: Die Beispiele hierf\u00fcr werden aus FlashArray-Perspektive aufgef\u00fchrt und die Rahmenbedingungen variieren je nach Art des Arrays. VMware VMFS (Virtual Machine File System) und die obere Schicht sind jedoch f\u00fcr 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.<\/em><\/p>\n

Es gibt eine ganze Reihe von Vorteilen von Thin Virtual Disks \u2013 und dabei geht vor allem um deren Flexibilit\u00e4t. Einer der Hauptvorteile ist der UNMAP-Befehl, wor\u00fcber dieser Blog berichtet:<\/p>\n

Space Reclamation\/UNMAP<\/a><\/p>\n

Was ist eine Thin Virtual Disk? Es ist ein Laufwerk, dem eine logische Gr\u00f6\u00dfe zugewiesen wird und das einer virtuellen Maschine pr\u00e4sentiert wird. Wird also eine 50 GB gro\u00dfe Thin Virtual Disk erstellt, sieht die virtuelle Maschine eine 50-GB-\u201ePlatte\u201c, die f\u00fcr jedes beliebige Dateisystem verwendet werden kann. Auf dem VMFS wird eine VMDK-Datei erzeugt, in die Daten geschrieben werden k\u00f6nnen. Das grundlegende Merkmal einer Thin Virtual Disk ist, dass die Datei, die die virtuelle Platte \u201eist\u201c, 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.<\/p>\n

Es gibt nat\u00fcrlich auch einige Performance-Fragen rund um \u201eThin\u201c. Weitere Informationen hierzu finden sich hier:<\/p>\n

Pure Storage FlashArray and Re-Examining VMware Virtual Disk Types<\/a><\/p>\n

Erstellen einer Thin Virtual Disk<\/h3>\n

Hier ist ein leeres VMFS:<\/p>\n

\"\"<\/p>\n

\u201eLeer\u201c bedeutet, abgesehen von den VMFS-Metadaten, die hier 1,47 GB ausmachen. Schauen wir uns nun das Array selbst an:<\/p>\n

\"\"<\/p>\n

Werden 1,47 GB auf 2 MB reduziert? Nein, das Array meldet ein Datenreduktionsverh\u00e4ltnis von 21,3:1. So werden tats\u00e4chlich nur etwa 40 MB geschrieben. Es gibt viele VMFS-Datenspeicher auf diesem Array, so dass die \u00fcberwiegende Mehrheit dieser VMFS-Metadaten dedupliziert ist.<\/p>\n

Der Punkt ist, dass es drei Dinge gibt, die diese Diskrepanz verursachen:<\/p>\n

    \n
  1. Zugeteilt vs. geschrieben.<\/strong> ESXi verteilt aus vielen Gr\u00fcnden Speicherplatz auf dem Dateisystem, wobei virtuelle Festplatten die prim\u00e4ren Festplatten sind, aber oft nicht sofort etwas schreiben. Dem Array ist diese Zuordnung also nicht bekannt. Eine virtuelle Plattenzuordnung ist eine METADATA-\u00c4nderung auf VMFS. Es werden keine Daten auf das Array geschrieben, daher die Diskrepanz.<\/li>\n
  2. Datenreduktion.<\/strong> Was tats\u00e4chlich 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.<\/li>\n
  3. Zero Removal.<\/strong> Pure Storage nimmt Dinge wie das Auslassen von Nullen nicht in das Datenreduktionsverh\u00e4ltnis auf. Wenn also die Daten, die geschrieben werden, tats\u00e4chlich ein Haufen Nullen sind, werden sie nicht wirklich auf dem FlashArray reflektiert. Ein Gro\u00dfteil des VMFS-Metadatenbereichs wird bei der Erstellung auf Null gesetzt, woher ebenfalls die Diskrepanz herr\u00fchrt.<\/li>\n<\/ol>\n

    Legen wir also eine 40 GB gro\u00dfe Thin Virtual Disk auf das VMFS.<\/p>\n

    \"\"<\/p>\n

    Wie funktioniert eine Thin Virtual Disk? Sie wird nur bei Bedarf zugeteilt. Da die Daten schlie\u00dflich vom Gast geschrieben werden, dehnt sie sich blockweise aus, setzt diese Bl\u00f6cke dann auf Null und \u00fcbertr\u00e4gt die Daten.<\/p>\n

    Hier ist das VMFS, nachdem eine Thin Virtual Disk hinzugef\u00fcgt wurde:<\/p>\n

    \"\"<\/p>\n

    Es befinden sich immer noch nur 1,47 GB auf dem VMFS, also gab es keine \u00c4nderung.<\/p>\n

    \"\"<\/p>\n

    Es befinden sich immer noch 2,31 MB auf dem FlashArray.
    \nWenn wir uns die VMDK-Datei ansehen, sehen wir, dass sie tats\u00e4chlich 0 KB gro\u00df ist:<\/p>\n

    \"\"<\/p>\n

    \u201eAuf Null stellen\u201c einer Thin Virtual Disk<\/h3>\n

    Um das \u201eAuf Null stellen\u201c-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.<\/p>\n

    \"\"<\/p>\n

    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:<\/p>\n

    \"\"<\/p>\n

    Aber was ist mit dem VMDK selbst?<\/p>\n

    \"\"<\/p>\n

    \u00dcber 40 MB werden angezeigt. VMware wei\u00df nicht, was geschrieben wurde und wei\u00df nicht, dass alles nutzlose Nullen waren. ESXi hat nat\u00fcrlich Schreibzugriffe auf Bl\u00f6cke erfasst, diese Bl\u00f6cke zugewiesen \u2013 und damit die Thin Virtual Disk (die VMDK-Datei) vergr\u00f6\u00dfert. Die Daten wurden dann an das Array gesendet.<\/p>\n

    \"\"<\/p>\n

    11,57 MB werden angezeigt. Dies liegt daran, dass das FlashArray alle Nullen verwirft. Da keine Nullen in das Datenreduktionsverh\u00e4ltnis aufgenommen werden, \u00e4ndert es sich auch nicht.<\/p>\n

    Das vorl\u00e4ufige 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\u00fccklich (Windows\/Storage) und einer nicht (VMware).<\/p>\n

    Ist es m\u00f6glich, die virtuelle Festplatte zu verkleinern? Ja. VMware hat in vmkfstools eine Funktion namens \u201epunchzero\u201c, die verwendet werden kann, um eine virtuelle Festplatte zu lesen und Bl\u00f6cke 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:<\/p>\n

    https:\/\/kb.vmware.com\/s\/article\/2004155 <\/a><\/p>\n

    Schreiben auf eine Thin Virtual Disk<\/h3>\n

    Lassen Sie uns nun das virtuelle Laufwerk neu starten, l\u00f6schen und neu erstellen.<\/p>\n

    \"\"<\/p>\n

    Hierbei wird vdbench genutzt, um eine Datei ungleich Null zu erstellen und das Laufwerk E: (das sich auf der Thin Virtual Disk befindet) aufzuf\u00fcllen.<\/p>\n

    \"\"<\/p>\n

    Wenn wir uns das VMFS ansehen, sehen wir, dass das VMDK wieder auf 40 GB angewachsen ist:<\/p>\n

    \"\"<\/p>\n

    Wenn wir uns das FlashArray ansehen:<\/p>\n

    \"\"<\/p>\n

    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\u00fcckzuf\u00fchren.<\/p>\n

    L\u00f6schen von Daten auf einer Thin Virtual Disk<\/h3>\n

    Was passiert, wenn wir diese von VDBench erstellte Datei aus dem NTFS auf der Thin Virtual Disk l\u00f6schen?<\/p>\n

    \"\"<\/p>\n

    Nun ist NTFS auf dem VMDK leer:<\/p>\n

    \"\"<\/p>\n

    Das VMFS meldet die VMDK-Datei jedoch immer noch mit 40 GB:<\/p>\n

    \"\"<\/p>\n

    Und auch das FlashArray \u00e4ndert seine Berichterstattung nicht:<\/p>\n

    \"\"<\/p>\n

    Jetzt meldet Windows 0 GB. VMFS meldet 40 GB. Das FlashArray meldet 5,6 GB.<\/p>\n

      \n
    1. Das Gastbetriebssystem (in diesem Fall Windows) meldet, wie viel es gerade geschrieben hat<\/strong>. Dies ist jetzt Null. Die Datei wurde gel\u00f6scht.<\/li>\n
    2. VMFS meldet, wie viel zugeteilt wurde<\/strong>. Wenn das Geschriebene weg ist, wird die Allokation nicht aufgehoben, da dies zwei verschiedene Dinge sind. VMFS wei\u00df nicht, dass die Datei in der VM gel\u00f6scht wurde, so dass die zugewiesene Gr\u00f6\u00dfe der virtuellen Festplatte bei 40 GB bleibt.<\/li>\n
    3. Das Array meldet den physischen Abdruck dessen, was zuletzt geschrieben wurde<\/strong>. Es bleibt so, bis es \u00fcberschrieben wird. Wenn etwas einfach gel\u00f6scht wird und es kein \u00dcberschreiben gibt, ist das Array nicht bekannt. Die genaue Gr\u00f6\u00dfe des Footprints<\/strong> h\u00e4ngt davon ab, wie\/ob das Array die Datenreduktion nutzt.<\/li>\n<\/ol>\n

      Das sind alles unterschiedliche Metriken und bedeuten daher unterschiedliche Dinge.<\/p>\n

      Wie bringen wir VMware und das Array dazu, die tats\u00e4chliche Nutzung durch den Gast widerzuspiegeln? Es gibt es mehrere Methoden, die sich normalerweise auf zwei M\u00f6glichkeiten reduzieren:<\/p>\n

        \n
      1. Nullen schreiben<\/li>\n
      2. In-Guest-UNMAP<\/li>\n<\/ol>\n

        Das Schreiben von Nullen wird von allen Versionen von ESXi in allen Konfigurationen unterst\u00fctzt, also sehen wir uns das zuerst an.<\/p>\n

        R\u00fcckgewinnung von Speicherplatz durch Nullsetzen einer Thin Virtual Disk<\/h3>\n

        Mittels sdelete l\u00e4sst sich auf Windows (oder dd von \/dev\/zero f\u00fcr Linux) der freie Speicherplatz im Dateisystem auf Null setzen. Die meisten Arrays haben heutzutage die M\u00f6glichkeit, Nullen automatisch zu entfernen (wie das FlashArray) oder ein Verfahren zur R\u00fcckgewinnung von Null Speicherplatz, das nachtr\u00e4glich ausgef\u00fchrt werden kann.<\/p>\n

        Wird sdelete gestartet, \u00e4ndert sich die VMDK-Gr\u00f6\u00dfe nicht, sie betr\u00e4gt immer noch 40 GB.<\/p>\n

        \"\"<\/p>\n

        Das liegt daran, dass ESXi nur schreibt. Die Belegung des VMDK ist bereits voll, so dass keine \u00c4nderungen erforderlich sind.<\/p>\n

        Das FlashArray reagiert jedoch.<\/p>\n

        \"\"<\/p>\n

        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.<\/p>\n

        \"\"<\/p>\n

        Die virtuelle Festplatte meldet aber immer noch 40 GB. Dies liegt daran, dass niemand VMFS mitgeteilt hat, dass die Daten nicht ben\u00f6tigt werden.<\/p>\n

        Um das VMDK zu verkleinern, muss man VMware sagen, dass es die Nullen zur\u00fcckfordern soll. Dies kann durch Entfernen des VMDK von der VM geschehen oder durch Herunterfahren der VM und Ausf\u00fchren von vmkfstools punchzero:<\/p>\n

        \"\"<\/p>\n

        Der Nachteil ist nat\u00fcrlich, dass dies offline erfolgt.<\/p>\n

        \"\"<\/p>\n

        Wenn das Entfernen der Nullen beendet ist, ist das VMDK verkleinert, von 40 GB bis auf ca. knapp MB.<\/p>\n

        Die bessere M\u00f6glichkeit ist UNMAP, was online erfolgt, jedoch gibt es auch hier Einschr\u00e4nkungen.<\/p>\n

        R\u00fcckgewinnung von Speicherplatz mit UNMAP in einer Thin Virtual Disk<\/h3>\n

        In-Guest-UNMAP erlaubt es dem Gastbetriebssystem, UNMAP-SCSI-Befehle an das Dateisystem auf einem VMDK an Bl\u00f6cke 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\u00e4ngt UNMAP und entfernt einfach die Speicherzuweisungen, die es f\u00fcr diese Bl\u00f6cke hat. Somit erfolgen alle Nullstellungsschritte in einem integrierten Online-Verfahren.<\/p>\n

        Wie das geht, erfahren Sie in den folgenden Blog-Eintr\u00e4gen:<\/p>\n

        In-Guest UNMAP Fix in ESXi 6.5 Part I: Windows<\/a><\/p>\n

        What\u00b4s new in ESXi 6.5 Storage Part I: UNMAP<\/a><\/p>\n

        Es gelten folgende Einschr\u00e4nkungen:<\/p>\n