Speicherkapazitätserfassung unter VMware – Teil III: Überlegungen zum VMFS-Kapazitäts-Reporting

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.

Wir haben über Thin Disks gesprochen, wir haben über Thick Disks gesprochen. Kurz gesagt, „dünne“ Datenträger haben den großen Vorteil, dass sie einen Einblick in das haben, was der Host geschrieben hat, und natürlich auch, dass sie Fehlanpassungen durch In-Guest-UNMAP korrigieren. „Dicke“ Laufwerke haben diese Fähigkeit nicht. Diese Eigenheiten können dazu führen, dass das Reporting und die Verwaltung des Speicherplatzes zu einem Problem wird.

Dies wirft also die Frage auf: Kann das VMFS-Kapazitäts-Reporting geändert werden? Kann VMFS die Vorteile der Array-basierten Datenreduktion nutzen? Sollte es das? Dies ist eine interessante Frage. Die Antwort auf die erste Frage lautet: Nein. Das VMFS-Reporting ist das, was es ist.

Die nächsten beiden Fragen sind unterschiedlich. VMFS unterscheidet sich im Konzept nicht von anderen Dateisystemen. Lassen Sie uns also die Tatsache ignorieren, dass sich das VMFS-Reporting vorerst nicht außer Kraft setzen lässt. Nehmen wir an, dass wir das können. Sollten wir das auch?

Nun, der Sinn von VMFS ist es, einer VM abstrahierten Speicher zur Verfügung zu stellen, so dass sie unabhängig von der physischen Ebene verschoben und identisch behandelt werden kann.
Wenn überschrieben wird, wie groß oder klein eine Datei auf VMFS ist, woher wissen wir dann, wie groß oder klein sie sein wird, wenn sie auf dasselbe oder ein anderes VMFS kopiert wird? Wenn sich eine VMFS auf einem Array mit Datenreduktion befindet und die andere nicht, könnte letztere viel größer sein. Wenn es verschiedene Anbieter sind, aber beide eine Datenreduktion anbieten, könnte der Unterschied trotzdem erheblich sein, da nicht alle Datenreduktionen gleich sind. Daraus resultiert folglich ein großes Fragezeichen.

Außerdem beziehen sich die VMFS-Semantik und das Sperren auf Blöcke auf dem physisch dargestellten Gerät. Wenn eine VMDK-Größe überschrieben wird, wo tritt diese Übersetzungsschicht auf? In VMFS? In der Reihe? Wer kontrolliert, wie es gemacht wird? Was ist mit Dateisperren? Was ist mit UNMAP?

Wie sieht es mit verschiedenen Arten von virtuellen Festplatten aus? Ist dies für Thick und nicht Thin aktiviert? Es gibt auch verschiedene Arten von Thick Virtual Disks, was ist damit?
Werden in VMFS Large File Blocks (LFBs) und Small File Blacks (SFBs) zerstört? Wahrscheinlich. Vieles davon müsste neu geschrieben werden, und wie es funktionieren würde, würde von Anbieter zu Anbieter sehr unterschiedlich sein.

VMFS ist ein Dateisystem. Das Accounting-Overriding würde weitaus mehr Probleme verursachen, als es löst. Wenn wir nur die Gesamtzahl überschreiben, welchen Nutzen bringt uns das wirklich gegenüber dem, was wir bereits haben?

Unabhängig davon hat VMware dies auf drei Wegen gelöst:

• Erstellen neuer Dateitechniken, die effizienter sind. Verlinkte Klone. Thin Virtual Disks. SE Sparse. Instant-Klone. Verschiedene Dateifunktionen, die es VMFS ermöglichen, eine eigene Art der Datenreduktion durchzuführen.
• VSAN. Dies gibt VMware die Kontrolle über den gesamten Storage-Stack, so dass mehr Flexibilität bei der Kontrolle gewährleistet ist.
• Virtuelle Volumes. Anstatt dass VMware mehr Kontrolle übernimmt, kann der Hersteller die volle Kontrolle über das Kapazitäts-Reporting und das Datenmanagement übernehmen (mehr dazu im nächsten Blogbeitrag).

Kurz gesagt, die Lösung besteht nicht darin, VMFS komplett neu zu schreiben, das ist bereits erfolgt, indem sie es entfernt wurde und VVols eingeführt wurde. VVol-Datenspeicher sind nur logische Abstraktionen, die es dem Speicher-Array erlauben, zu berichten, was es will (mehr dazu im nächsten Beitrag).

Fazit

Bevor wir zu VVols übergehen, stellt sich noch die Frage, wie VMFS verwaltet wird. Ein paar Empfehlungen hierzu:

Überwachen Sie zunächst Ihre VMFS-Auslastung.

Wenn das Array voll ist, ist es voll, und es ist egal, wie gut das Array den Footprint reduziert hat. VMFS weiß nichts über Datenreduktion.

Versuchen Sie zunächst, Ineffizienzen zu korrigieren:

• Verwenden Sie möglichst Thin Virtual Disks. Die meisten Anwendungen können den geringen Unterschied in der Leistung nicht erkennen und die Vorteile werden diesen Nachteil bei weitem überwiegen. Ein großer Vorteil ist:
• Aktivieren Sie In-Guest UNMAP. Dies funktioniert mit Windows 2012 R2 und höher in ESXi 6.0 und mit Linux in 6.5 und höher. Es funktioniert nicht gut bis 6.5 Patch 1 (für beide Betriebssysteme). Wechseln Sie zu dieser ESXi-Version.
• Wenn Sie Thick Virtual Disks verwenden, ist UNMAP keine Option und Sie können nur noch den Speicherplatz durch aktives Ausnullen zurückgewinnen. Das macht die Erfassung der richtigen Kapazität auf dem Array eher zu einem gezielten, reaktiven Ansatz: „Ich vermute, dass ich toten Platz in der VM habe, deshalb werde ich den freien Platz jetzt auf Null setzen.“ Dies steht im Gegensatz zu In-Guest-UNMAP, dass sich automatisch und kontinuierlich um sich selbst kümmert.

Wenn das alles schon geschehen ist, ist es an der Zeit für Folgendes:

• Erweitern Sie Ihr VMFS.
• Fügen Sie ein neues VMFS hinzu.
• Verwenden Sie Storage vMotion oder Storage DRS, um die Kapazität auszugleichen.

Über die Überwachung Ihrer VMFS-Volumes hinaus überwachen Sie die Gesamtnutzung Ihres Arrays. Nun kann dies etwas vom Hersteller abweichen (vielleicht müssen Sie stattdessen einen Pool oder ähnliches überwachen).

Die Überwachung Ihres VMFS ist alles, was auf der Volume-Ebene benötigt wird. Der einzige Fall, in dem sich Administratoren die Volume-Nutzung auf dem Array ansehen können, ist die Identifizierung von totem Speicherplatz oder der Bericht über Speicherplatzrückbuchungen zum Beispiel.

Was zu tun ist, wenn das Array fast voll ist – oder, um genau das zu verhindern:

• Wenn Sie VMFS-5 verwenden, nutzen Sie eine Vorgehensweise basierend auf UNMAP. Führen Sie dies nach einem Zeitplan aus, wenn Ihr Array fast voll ist oder wenn die Nutzung eines Volumes mit VMFS aus dem Ruder läuft.
• Wenn Sie VMFS-6 verwenden, halten Sie einfach die automatische UNMAP-Funktion aktiviert.

Wenn Sie die UNMAP-Option ausgeschöpft haben und das Array immer noch zu voll ist:

• Gleichen Sie die Kapazität aus bei mehreren Arrays.
• Stellen Sie mehr physische Kapazität für das Array zur Verfügung.

Der nächste Beitrag befasst sich mit der Funktionsweise des VVol-Kapazitäts-Reportings speziell auf dem FlashArray.