ThinProvisioning mit Windows Server 2012

Immer wieder bekomme ich Fragen zum Thema „Thin Provisioning mit Windows Server 2012“.

Im Rahmen meines heutigen Blogs möchte ich das Thema kurz erläutern, wie es funktioniert und welche Einstellung dazu nötig ist.

 

Windows Server 2012 hat den T10 SCSI Block Command 3 Standard (kurz SBC3) zur Erkennung von „Thin Provisioned LUN“ eingeführt. Während der Initialisierungsphase erhält der Windows Server vom Storage System entsprechende Informationen, beispielsweise ob das Storage System Thin Provisioning sowie UNMAP und TRIM unterstützt.

Mehr zu den ThinProvisioning Funktionen in Server 2012 sind hier beschrieben: https://msdn.microsoft.com/en-us/library/windows/hardware/dn265487%28v=vs.85%29.aspx

 

Beginnend mit DataONTAP 8.2 kann man die LUN Option „Space-Allocation enabled“ nutzen um den Windows Server darüber zu informieren, dass es sich um eine „ThinProvisioned LUN“ handelt. Dazu möchte ich ein kurzes Beispiel geben. In meiner Umgebung habe ich vier LUNs an einen Hyper-V 2012R2 Cluster angebunden:

 

1.png

 

Bei der LUN namens „lun_csv03“ wurde die Space Allocation disabled, bei der LUN „lun_csv04“ ist die Space Allocation enabled.

 

2.png

 

Im Windows Server werden nun die LUNs entsprechend unterschiedlich erkannt, d.h. nur CSV04 wird als "Thin Provisioned“ Disk gekennzeichnet.

 

3.png 

 

SpaceReclamation

Eine Funktion des Thin Provisioning im Windows Server ist das Thema SpaceReclamation. D.h. wird beispielsweise eine Datei im Filesystem gelöscht, sendet der Storage Port Driver im Windows Server einen UNMAP Request an das Speichersystem um den Platz auch auf dem Speichersystem wieder freizugeben.

 

SpaceReclamation bis ins Gast OS

Mit Server 2012 hat Microsoft die „Space Reclamation Fähigkeit“ bis ins Gast Betriebssystem möglich gemacht. Bedeutet, wird auch innerhalb des Gast-Betriebssystems eine Datei gelöscht, so wird über das Dateisystem des Hyper-V Servers der UNMAP Request an das Storage System weitergeleitet.

 

Wie es funktioniert, möchte ich kurz darstellen. Dazu habe ich in meiner Umgebung eine VM namens aktestvm01 mit zwei zusätzlichen Disken (VHDX) erstellt:

- VHDX 1 ist eine Dynamic VHDX mit einer Größe von 30GB und wird als Laufwerk E:\ in der VM bereitgestellt.

 

5.png

 

- VHDX 2 ist eine Fixed Size VHDX mit einer Größe von 25GB und wird als Laufwerk F:\ angebunden.

 

 6.png

 

Beide VHDX Files befinden sich auf dem Clustered Shared Volume mit dem Namen CSV04.

 

7.png

 

Auf dem Storage System (Volume vol_csv4) sind aktuell nur ca. 630MB an Speicherplatz belegt.

 

4.png

 

Als nächstes werden zwei Dateien auf die Disk F:\ der VM kopiert. In Summe belegen diese Dateien ca. 7.2GB.

 

8.png

 

Betrachtet man das Speichersystem, ist der Speicherplatz ebenfalls auf ~7.6GB angewachsen.

 

9.png

 

Im nächsten Schritt wird eine der beiden Dateien gelöscht.

 

10.png  

 

Somit befinden sich lediglich noch ~ 3.6GB auf dem Laufwerk F:\.

 

11.png

 

Betrachtet man erneut das Speichersystem, erkennt man, dass auch hier der Speicherplatz auf rund 4.1GB gesunken ist.

 

12.png

 

Dieser Space Reclamation Prozess erfolgt automatisch (i.d.R. alle 5 Minuten). Will man beispielsweise in einer Testumgebung nicht so lange warten, kann man das ganze mittels dem Kommando „Optimize-Volume –DriveLetter F – Retrim“ auch beschleunigen.

 

13.png

 

Dynamic Disk und Thin Provisioning – Wie funktioniert das ?

Antwort: genauso…

 

Auch dies möchte ich im Rahmen eines kurzen Beispiels darstellen. Dazu werden in der VM auf die Disk E: (ist ein Dynamic VHDX) zwei Dateien mit rund 7.2GB kopiert.

 

14.png 

 

Das Dynamic Disk File namens vhdx1 wächst auf rund 7.4GB an.

 

15.png

 

Auch auf dem Speichersystem sind ~ 7.7GB belegt.

 

16.png

 

Als nächstes wird eine der beiden Dateien gelöscht.

 

17.png

 

Somit wird nur noch rund 3.6GB an Speicherplatz benötigt.

 

18.png

 

Dies ist auch auf dem Speichersystem sichtbar, d.h. durch die gelöschte Datei sinkt auch hier der Speicherbedarf von 7.7GB auf 4.2GB.

 

20.png

 

Betrachtet man allerdings das eigentliche Dynamic VHDX File (vhdx1), so bleibt dies bei der Größe von 7.4GB. D.h. das Dynamic VHDX File wird nicht kleiner.

 

19.png

 

Werden nun weitere Dateien auf das Laufwerk E:\ kopiert. In diesem Falle zwei weitere ISO Images mit rund 1.2GB...

 

21.png

 

... so bleibt auch das Dynamic VHDX File bei selbiger Größe.

 

22.png

 

Erst, wenn die Summe aller Dateien auf dem Laufwerk E:\ die Größe des aktuellen Dynamic VHDX File übersteigt, wird dies auch entsprechend wieder anwachsen.

 

Ich hoffe, der heutige Blog konnte helfen, das Thema Thin Provisioning mit Server 2012 etwas besser zu verstehen.

 

Abschließend möchte ich an dieser Stelle auf die Microsoft TechNet Seite bzgl. dem Thema eines möglichen „Performance Impact“ in Bezug auf Space Reclamation verweisen:

https://technet.microsoft.com/en-us/library/jj674351.aspx