Speicherplatz in der VMware Cloud on AWS durch TRIM/UNMAP gewinnen?
Hintergründe
Der Speicher in der VMware Cloud on AWS basiert zu großen Teilen auf vSAN. Virtuelle Maschinen sollten auf vSAN eigentlich so gut wie immer thin provisioniert werden. Thick-Provisionierung ist in den meisten Fällen einzig eine Erleichterung für das Storage-Management, welche an dieser Stelle besser durch ein gutes Speicherplatzmanagement und Monitoring gelöst werden sollte. Zumal die Verwendung von thick-Disks in vSAN, anders als bei der Verwendung von thick Disks mit Eager Zeroed Disks auf VMFS, keine Performance-Vorteile mit sich bringt. Die Blöcke von Disks (unabhängig thin/thick) werden bei vSAN erst geschrieben, wenn sie benötigt werden. Darüber hinaus verhindern thick-provisionierte Disks im vSAN die Anwendung von Features wie Deduplication und Compression.
Was machen die thin provisionierten virtuellen Disks auf vSAN mit dem Speicherplatz?
Wenn die thin provisionierten Disks im VMware Cloud on AWS auf vSAN liegen, laufen sie zwangsläufig in ein Problem. Die Daten, welche von einer virtuellen Maschine in eine Disk geschrieben werden, „blähen“ die Disk auf und geben freigewordenen Speicherplatz nicht mehr frei. Sie reservieren quasi immer den maximal genutzten Teil der Festplatte auf dem Datastore.
Nehmen wir als Beispiel einen einfachen vSAN Datastore mit einer thin provisionierten vmdk:
Die vmdk nimmt den Platz ein, den sie benötigt und der auch im Gastbetriebssystem als Füllstand der Festplatte angezeigt wird.
In dieser vmdk wird nun eine Datei erstellt und mit Daten gefüllt:
Die vmdk wächst entsprechend. Der im Gastbetriebssystem gezeigte Füllstand entspricht immer noch der Größe der vmdk-Datei auf dem Datastore.
Wird die Datei nun anschließend gelöscht, verhält es sich wie folgt:
Obwohl die Datei im Gastbetriebssystem gelöscht ist und auch der Füllstand der Festplatte im Gastbetriebssystem schrumpft, bleibt der genutzte Speicherplatz der vmdk weiterhin auf dem ursprünglichen Stand mit Datei. Die vmdk schrumpft also NICHT analog zum Füllstand der Festplatte im Gastbetriebssystem, obwohl der Speicherplatz nicht mehr benötigt wird.
Zwei Schritte, um den Speicherplatz durch TRIM/UNMAP zu gewinnen:
Die gute Nachricht ist, es gibt Abhilfe. Die meisten modernen Gastbetriebssysteme senden schon von Haus aus beim Löschen einer Datei Befehle mit, welche dem Hypervisor signalisieren, dass der Speicherplatz auf dem Datastore wieder freigegeben werden kann. Dieser Mechanismus erforderte in der On-Premise-Welt mit VMFS5 noch einige Handarbeit, erfolgt aber ab der Verwendung von VMFS6 (VAAI vorausgesetzt) so gut wie von allein.
Um nun auch in der VMware Cloud on AWS in den Genuss von TRIM/UNMAP zu kommen bedarf es zwei Schritte:
1. TRIM/UNMAP muss pro Cluster im SDDC aktiviert werden. Dies kann nur durch VMware selbst geschehen. Der Kontakt funktioniert an dieser Stelle relativ einfach über den VMware vSphere Client. Stellen Sie vorher sicher, dass Sie die dazu benötigten Informationen haben. Auch wenn der Support direkt über den vSphere Client geschieht, müssen Sie dem Support-Engineer bei jeder Anfrage Ihre Org ID, sowie die SDDC ID mitteilen. Diese IDs finden Sie im VMware Cloud Portal im Bereich des jeweiligen SDDS unter dem Reiter „Support“. Mit diesen IDs können Sie nun im vSphere Client den Support-Chat (rechts unten im vSphere Client) öffnen und den Support-Engineer bitten, den TRIM/UNMAP Support für den jeweiligen Cluster freizuschalten.
2. Die Aktivierung von TRIM/UNMAP erfolgt anschließend pro virtueller Maschine mit einem Reboot.
Mit dem abschließenden Reboot der virtuellen Maschine geben Sie nun in Zukunft den hier hellgrau markierten Speicherplatz frei, der im Gast gelöschten Datei, an den Hypervisor weiter. Der Hypervisor gibt Ihn in Form einer geschrumpften vmdk-Datei über das Storage-System wieder frei:
Somit landen wir mit TRIM/UNMAP beim gewünschten Ergebnis und gewinnen Speicherplatz auf den Datastore zurück!
Fazit
Der zurückgewonnene Speicherplatz kann stark variieren. Je nach Betriebssystem und eingesetzter Anwendung können mehrere Giga- oder Terabyte auf der Strecke bleiben.
Gerade im Umfeld von VMware Cloud on AWS, wo Speicherplatz häufig DER limitierende Faktor beim dynamischen Herunterskalieren eines Cluster via Elastic DRS (kurz: eDRS) ist (mehr im Blogbeitrag Speicherprobleme in der VMware Cloud on AWS?), kann dieses Feature aber häufig den entscheidenden Vorteil bringen, um einen oder mehrere Hosts in einem Cluster sparen zu können.