Folgende Erläuterungen beziehen sich zwar speziell auf VMware vSphere, lassen sich im Prinzip aber auf andere Virtualisierer übertragen.

ESXI kennt die drei Provisionierungsarten „Thin-Provisioning“, „Thick Provisioning Eager Zeroed“ und „Thick Provisioning Lazy Zeroed“. Bei den beiden Erstgenannten ist die Sache eigentlich klar. In beide Fällen „sieht“ das Gastsystem die angegebene Speichermenge, bzw. Volume-Größe in der Datenträgerverwaltung. Thin-Provisioning reserviert allerdings beim Erstellen der virtuellen Festplatte keinen Speicherplatz im Datastore, sondern wächst dynamisch mit der im Gastsystem beanspruchten Datenmenge. Soweit so gut.

Thick Provisioning Eager Zereod hingegen (eager heißt so viel wie „fleißig“) reserviert beim Erstellen den gewünschten Speicherplatz im Datastore nicht nur komplett, sondern überschreibt auch gleich sämtliche Blöcke mit Nullen. Das dauert zwar seine Zeit, der Benutzer wird aber mit der performantesten virtuellen Disk belohnt.

Hintergründiges

Um die dritte Provisionierungsart „Thick Provisioning Lazy Zeroed“ zu verstehen, muss man wissen, dass das Feature unterschiedlicher Provisionierungsarten auf Hypervisor-Ebene von der Storage-Welt inspiriert ist. So beherrschen z. B. höherwertige SAN-Systemen Thin- und Thick-Provisioning auf Storage/LUN-Ebene. Hier wie dort geht es um eine effiziente Speicherplatznutzung.
Insbesondere in Virtualisierungsumgebungen, deren Sinn und Zweck ja in der Ressourcen-Konsolidierung liegt, welche im gewissen Umfang immer eine Überbuchungsoption vorsieht, sind Features wie Thin-provisionierbare virtuelle Disks essentiell. So können Anwendungen stets nur so viel Storage konsumieren, wie sie auch tatsächlich benötigen. Möglich ist das, weil viele Anwendungen bei der Erstinstallation eine bestimmte Größe an Plattenplatz erwarten, im laufenden Betrieb aber weniger brauchen. Noch mehr Einsparpotenzial bei der Konsolidierung ergibt sich, wenn die betreffenden VM ausgeschaltet oder eingeschaltet ist, die zugehörige Anwendung aber gerade nicht läuft.

Wann man Thin Provisioning einsetzt

Dass ein Hypervisor wie ESXi (oder Hyper-V, KVM etc.) Thin-provisionierbare virtuelle Disks erlaubt, ist daher vor allem dann nützlich, wenn das unterliegende Storage-Systemen von sich aus KEIN Thin Provisioning kann, etwa ganz normale lokale Festplatten (SAS, SATA). Windows Server unterstützt zwar ab der Version 2012R2 mit Storage Pools und auf dem VHDX-Format basierenden „Storage Spaces“ zwar neuerdings „mit-wachsende“ virtuelle Disks, einem ESXi-Server lässt sich Storage dieser Art aber nur auf Umwegen unterschieben, etwa in Form des iSCSI-Target-Features oder der Rolle „Server für NFS“ in Windows. Lokale Disks im ESXi-Hosts bieten kein Thin-Provisioning, sollten als Basis für Datastores aber ohnehin nur in Ausnahmefällen zum Einsatz kommen, weil erweiterte ESXi-Features Shared Storage benötigen.

Der Nachteil bei intensiven Gebrauch von Thin-provisionierten VMDKs ist allerdings, dass der vSphere-Admin den Ressourcenverbrauch laufend überwachen muss, um ein Overcommitment zu verhindern.

Lässiges Thick-Provisioning

Ein ausgewachsenes SAN-Array als Shared-Storage in ESXi-Umgebungen unterstützt hingegen heute von sich aus Thin-Provisioning auf Disk-/LUN-Ebene. Hier macht es wenig Sinn, auf Hypervisor-Ebene ebenfalls mit Thin-Provisioning zu arbeiten, ohne davon einen Vorteil zu haben. Für diesen Zweck nun bietet sich das Feature „Thick-Provisioning Lazy Zeroed“ an, das unter dieser Voraussetzung das Beste aus beiden Welten vereint.

Die Funktionsweise gleicht in Etwa der „Schnellformatierung“ unter Windows. Der Nutzer profitiert nach wie vor von der effizienteren Speicherplatznutzung, da sich das Storage-System mittels Thin-Provioning um die Reservierung kümmert. Zudem ist die virtuelle Disk wie eine auf ESXi-Ebene Thin-provisionierte Disk sofort verfügbar. Insofern ist Thick Provisioning Lazy Zeroed ein Thin-Provisioning-Feature. Der Nutzer muss aber keine Überbuchung fürchten, weil Thick-Provisioning Lazy Zeroed den ganzen Speicherplatz auf dem VMFS-Volumes reserviert. Gegenüber dem Storage-Array verhält sich Thick-Provisioning Lazy Zeroed (sofern dieses auf Storage-Ebene Thin-Provisioning unterstützt), wie eine Thin-provisionierte VMDK. Blöcke werden also erst beansprucht (und genullt), wenn das Gastsystem Daten speichern möchte.

Nachteile von Thick Lazy

Einen Nachteil hat das Ganze aber, obwohl es sich bei Thick Provisioning Lazy Zeroed inzwischen um die Default-Einstellung handelt. Die resultierende Performance ist schlechter, als bei Thick Provisioning Eager-Zeroed. Dass Letzteres zwar am Performantesten ist, aber beim Erstellen (theoretisch) am längsten dauert, bügeln Enterprise-SAN-Arrays mit VAAI-Support dadurch aus, dass der Storage diese Arbeit dem Hypervisor abnimmt und dieser doch sofort Vollzug melden kann.

Bis vSphere 5.0 bestand im Zusammenhang mit VAAI noch das Problem, dass vSphere das Storage-System nicht informierte, wenn der Nutzer etwa eine VMDK via Storage vMotion auf ein anderes Speichersystem verschoben hatte und der Platz eigentlich nicht mehr gebraucht wurde. Das Problem der so genannte http://blogs.vmware.com/vsphere/2012/04/vaai-thin-provisioning-block-reclaimunmap-in-action.html Dead Space Reclamation ist aber in neueren VAAI-Implementation ab vShere 5.0 behoben und der von der VMDK ehemals belegte Platz wird automatisch wieder freigeben.

Fazit

Unterstützt das Storage-System selbst kein Thin Provisioning, muss man eine effizientere Speichernutzung sofern gewünscht vom Hypervisor erledigen lassen. Bei Thick Provisioning kann sich der Nutzer zwischen schnellerer Bereitstellung (Lazy Zeroed) oder höherer Performance (Eager Zeroed) entscheiden, wobei Ersteres dem Thin-Provisioning vorzuziehen ist, wenn der Storage selbst Thin-Provisioning kann. Die scheinbare Komplexität in der Abwägung rührt daher, dass man es in Virtualisierungsumgebungen im Prinzip mit drei Ebenen zu tun hat, dem Hypervisor, dem Datastore.-Objekt auf ESXi-Ebene und dem physischen Storage-Array.