VMware-Forum

Hallo zusammen,

ich überlege gerade wie wir in Zukunft am besten mit dem Thema Thin Provisioning und Space Reclaim umgehen. Wir haben ein neues Storage-System das beiden kann (3PAR StoreServ).

Beim Verschieben der VMs mit SvMotion habe ich nun Thick/EgerZeroed ausgewählt damit der freie Speicherplatz in den VMs mit Nullen aufgefüllt wird. Die 3PAR erkennt die Nullen über ihren ASIC, von daher entsteht dadurch auch keine Last.

Aktuell belegt der freie Speicherplatz in den VMs sowie der freie Speicherplatz in den VMFS-Datastores keinen Platz auf dem Storage. Das wird sich aber leider mit der Zeit ändern, da nur die wenigstens Systeme unter Windows Server 2012 laufen und daher kein T10-UNMAP können.

Es gibt ja wohl verschiedensten Möglichkeiten für den Speicherplatz in der VM und auf dem Datastore. sdelete scheidet aus meiner Sicht aus da ich nicht ständig Warnmeldungen wegen des freier Speichers im Monitoring bekommen möchte. Die Optionen die in neueren vSphere-Versionen zur Verfügung stehen habe ich noch nicht getestet (Wir setzen noch vSphere 5.0 ein, ein Upgrade auf 6.0 ist geplant).

Wie geht ihr beim Thema Space Reclaim vor?

Grüße

Sdelete bzw. DD. Etwas anderes wirst du aus Sicht des Gastsystems nicht machen können. Die Hypervisor können damit dank UNMAP ganz gut umgehen.

Hallo,

ich sehe keinen Vorteil darin, eine VM mit svMotion und dem Zielformat "eager zeroed thick" zu migrieren.
Sofern ein VMFS Block bisher noch nicht in Verwendung gewesen ist belegt er ohnehin keinen Platz auf einem Array welches Thin Provisioning unterstützt, unabhängig vom gewählten vmdk Format.
Denn anders als von dir geschrieben überschreibt diese Vorgehensweise nicht den freien Platz innerhalb einer VM mit Nullen, sondern initialisiert bisher noch nicht belegte VMFS Sektoren für die Verwendung durch die vmdk, in dem sie diese Bereiche mit Nullen befüllt.

Erst nach dem Löschen/Verschieben einer VM könnten auf dem Quell VMFS die benutzen Kapazitäten wieder an den Array Thin Pool zurück gegeben werden, sofern im Anschluß daran eine VMFS Space reclaimation Operation durchgeführt wird.
Denn in der Standardeinstellung von vSphere 5 und 6 wird dieser Vorgang nicht automatisch durchgeführt.

Wenn du Daten innerhalb der VM's gelöscht hast, werden diese Bereiche nur im Gast Filesystem wieder als frei markiert, dabei jedoch üblicherweise nicht mit Nullen überschrieben.
Weiterhin verwendet VMFS eine andere Blocksize als Filesysteme eines Gastes, somit muß der dort freie und mit Nullen überschriebene Bereich auch zu einem kompletten VMFS Block passen, damit dein Array diese Kapazität für seinen Thin Pool wieder verwenden kann.

Damit gewinnt das längst in Vergessenheit geratene Defragmentieren wieder an Bedeutung.

Wenn z. B. eine Windows VM mit NTFS in einem 1 MB Bereich auch nur einen 4 KB mit Daten beschrieben hat, belegt dieser Bereich im VMFS 1 MB.
Wie viel Platz es dann in deinem Array belegt hängt dann davon ab, welche Blocksize dieses verwendet und wieviele Blöcke der VMFS Block darin belegt.


Und zum Thema Space Reclaimation von Gast Systemen empfehle ich folgenden Artikel.
vSphere 6.0 Storage Features Part 8: VAAI UNMAP changes

Fazit

1. Nach dem Löschen/Verschieben von VM's muß der VMware Admin noch eine manuelle Space Reclaimation Operation auf dem Quell VMFS durchführen.
2. Space Reclaimation innerhalb von Gast Systemen (erst ab vSphere 6) bringt eigentlich nur in Verbindung mit regelmäßigem Defragmentieren einen Mehrwert.
3. Auf pre vSphere 6 Systemen erfordert Gast Space Reclaimation manuelle Aktivitäten auf dem Array, da das VMFS einen durch sdelete oder dd gelöschten Bereich im VMFS als immer noch in Verwendung deklariert.

Gruß,
Ralf

Defragmentieren von VMs auf Storage mit storagebasierten Snapshots ist ziemlich suboptimal (außer man mag explodierende Snapshotdeltas).

Na ja, man kann eben nicht alles haben.


Aber ohne Defragmentierung bringt Space Reclaimation innerhalb von VM's eben nicht viel.
Dann bliebe nur noch das Löschen von VM's, und darüber beschweren sich deutlich mehr Anwender als es Storage und Backup Admins gibt.

Außerdem leben Storage Hersteller vom Speicherplatz Verkauf.

Gruß,
Ralf

Ja irgendwas is halt immer

Ich wollte nur mal drauf hinweisen - je nach Storagesystem, dessen Features und wie man sie gedenkt zu nutzen hat mal halt die Wahl zwischen Pest und Cholera.

Da es hier schonmal verlinkt wurde http://www.purestorage.com/blog/direct- ... ere-6-0-2/

Ich wuerde das ganze mal als Work in progress betiteln und es kommt sehr drauf an wo man Versionstechnisch gerade ist bzw. welche kleinen Schalterlein betaetigt werden.

Das wo ich drauf hinweisen will ist das "“Enable VMFS block delete when UNMAP is issued from guest OS”.

Gruss
Joerg

Danke für das Feedback. Ich werde mal ein bisschen mit einer vSphere 6.0 Testumgebung und dem neuen Storage rumspielen.