Thin-Provisioning – also die schrittweise Zuteilung von Speicherressourcen – gibt es nicht nur in Form von VMDK Diskfiles, sondern auch auf Storage-Ebene. Hier werden Volumes nicht 1:1 als LUN an den Host übergeben, sondern das (reale) Speichervolume ist von der (virtuellen) LUN entkoppelt. Man kann so Datenspeicher effizienter ausnutzen und dynamisch zuteilen. Da der ESX Host nun keinen physischen Zugriff auf das Speichervolume mehr hat, sondern nur auf die virtuelle LUN, muss es eine Möglichkeit geben, mit welcher der Host der Storage Rückmeldung über gelöschte oder verschobene Speicherbereiche geben kann. Um diese Funktion wurde die “vStorage APIs for Array Integration” (VAAI) unter vSphere 5.0 erweitert. Die VAAI Funktionen heissen “primitives” und jene, die für die Rückgabe von Speicher verantwortlich ist nennt sich UNMAP.
Leider gab es damit einige Probleme in Verbindung mit Storage Geräten, weswegen diese Funktion von VMware schnell wieder zurückgezogen wurde. Bis zum Stand 5.5 wurde sie nicht wieder aktiviert. Man kann sie aber dennoch nutzen – wenn auch nicht komfortabel.
Kein UNMAP und mögliche Folgen
Wenn ein ESXi Server eine VM von LUN1 nach LUN2 verschiebt, dann erfährt das darunter liegende Storagesystem nur, dass jetzt neue Bereiche auf LUN2 belegt wurden. Die Freisetzung auf LUN1 bleibt unerkannt. Mit anderen Worten: die Storage füllt sich mit nicht mehr gebrauchtem Datenmüll und produziert ab einem gewissen Füllgrad Warnungen oder gar Alarme. Solange alle virtuellen LUNs mit physischem Speicher in der Storage gedeckt sind, ist dies kein Problem. Wird jedoch mehr Speicher präsentiert, als physisch vorhanden ist (Überprovisionierung), so kann die vermeintliche Füllung unangenehme Folgen für die konsumierenden Hosts haben.
Um dies zu verdeutlichen, kann man sich folgendes Szenario vorstellen: Eine Storage verfügt über 1 TB physischen Plattenspeicher. Es werden 2 LUNs (LUN1, LUN2) mit jeweils 600 GB präsentiert. Eine VM von 550 GB wird auf LUN1 gelegt und anschließend auf LUN2 verschoben. Aus Sicht des ESX Hosts sind weiterhin nur 550 GB belegt. Aus Sicht der Storage werden jedoch weitere 550 GB angefordert, ohne die alten 550 GB auf LUN1 freizugeben. Die physische Speicherkapazität ist damit überschritten (1100 GB > 1TB). Jetzt bekommt der Host über VAAI eine “Out of Space Condition”, was dazu führt dass die VM angehalten wird (stun). Ein Zustand, den man unter allen Umständen vermeiden möchte.
In der Praxis
Ich zeige das Phänomen am Beispiel eines echten vSphere5.5 Clusters, dem ein DataCore Speichercluster als Target bereitgestellt wurde. Den ESXi Hosts werden 15 LUNs mit insgesamt 21 TB präsentiert. Die präsentierten 21 TB sind zu 100% durch physisch vorhandenen Speicher gedeckt. Es findet keine Überprovisionierung statt. Es gibt im vCenter mehrere Storage-Cluster mit aktiviertem Storage-DRS. Über die Zeit ereigneten sich mehrere svMotion Vorgänge, die so neuen Speicherplatz vom Storagesystem forderten, aber den alten nicht wieder freigaben. So entstand eine Diskrepanz zwischen dem, was laut ESX Server belegt war und was seitens DataCore als belegt vermerkt wurde.
| Summe | 3217 | ||
| LUN | alloc. DataCore [GB] | alloc. ESXi [GB] | Delta [GB] |
|---|---|---|---|
| High1 | 1823 | 1580 | 243 |
| High2 | 998 | 725 | 273 |
| Normal1 | 2765 | 2219 | 546 |
| Normal2 | 1843 | 1564 | 279 |
| Low1 | 2007 | 1501 | 506 |
| Low2 | 1782 | 1586 | 196 |
| VDI1 | 1005 | 867 | 138 |
| VDI2 | 977 | 877 | 100 |
| VDI3 | 1005 | 866 | 139 |
| VDI4 | 1015 | 852 | 163 |
| VDI5 | 991 | 846 | 145 |
| VDI6 | 971 | 854 | 117 |
| VDI7 | 990 | 906 | 84 |
Das bedeutet, dass mehr als 3 TB zurückgegeben werden können!
Prozedur
Unmap erfolgt seit version 5.5 mit dem Befehl esxcli. Dazu verbindet man sich per SSH auf einen ESX-Host, welcher Zugriff auf die LUNs hat. Zunächst ist es sinnvoll, alle LUNs anzuzeigen.
# esxcli storage vmfs extent list
Auf diese Weise erhält man eine Liste der LUNs und deren UUID.
VAAI tauglich?
Nun muss geklärt werden, ob die Storage VAAI unterstützt. Dazu muss der Device Name übergeben werden (Bsp.: Volume Low2)
# esxcli storage core device list -d naa.60030d90978b9e03d2bbce3748224fec
Ausgabe:
naa.60030d90978b9e03d2bbce3748224fec
Display Name: DataCore Fibre Channel Disk (naa.60030d90978b9e03d2bbce3748224fec)
Has Settable Display Name: true
Size: 2097152
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/naa.60030d90978b9e03d2bbce3748224fec
Vendor: DataCore
Model: Virtual Disk
Revision: DCS
SCSI Level: 5
Is Pseudo: false
Status: on
Is RDM Capable: true
Is Local: false
Is Removable: false
Is SSD: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: yes
Attached Filters:
VAAI Status: supported
Other UIDs: vml.02000c000060030d90978b9e03d2bbce3748224fec566972747561
Is Local SAS Device: false
Is Boot USB Device: false
Damit sieht man, ob die LUN “thin” provisioniert ist und ob VAAI unterstützt wird.
Thin Provisioning Status: yes VAAI Status: supported
Um noch sicherer zu sein sollte man prüfen, ob das VAAI unmap Primitive von der unterlegenden Storage unterstützt wird.
# esxcli storage core device vaai status get -d naa.60030d90978b9e03d2bbce3748224fec
Ausgabe:
naa.60030d90978b9e03d2bbce3748224fec VAAI Plugin Name: ATS Status: supported Clone Status: supported Zero Status: supported Delete Status: supported
In der Ausgabe ist auf “Delete Status” zu achten. Nur wenn hier “supported” steht kann ein VAAI unmap durchgeführt werden.
ESXi 5.5 VAAI unmap
Der allgemeine Befehl für unmap ist:
# esxcli storage vmfs unmap -u <UUID>
Er hat drei Parameter, von denen einer der ersten beiden obligatorisch ist.
- Volume Label [-l]
- UUID [-u]
- reclaim unit [-n]: Anzahl Blöcke, die pro Iteration freigegeben werden sollen (Standard 100).
esxcli storage vmfs unmap -u 5175adc7-a361f985-36bf-001b212980b6
Die Dauer der Auführung liegt zwischen wenigen Minuten und Stunden. Jeweils abhängig von der Belegung der LUN. Der Vorgang erzeugt ein “.asyncUnmapFile” auf dem jeweiligen Datastore. Dieses liest (und sperrt) die Blöcke, für die im aktuellen Durchlauf ein unmap durchgeführt werden soll. Somit wird sichergestellt, dass diese zwischenzeitlich nicht beschrieben werden.
Sobal der Prozess gestartet ist, beginnt der Datacore Server mit einer Reclamation der freien Blöcke.
Links
- VMware-Blog (Cormack Hogan) – VAAI Thin Provisioning Block Reclaim/UNMAP In Action
- VMware-Blog (Cormack Hogan) – Thin Provisioning – What’s the scoop?
- boche.net – vSphere 5.5 UNMAP Deep Dive