Dell Unity: Verschil tussen datastoregebruik op VMware-niveau en Unity-storage LUN-gebruik

Klanten merken op dat de ESXi-datastore meer verbruikte ruimte laat zien dan de bijbehorende Unity-datastore.
 

Verschil tussen datastoregebruik op VMware-niveau en Unity-storage LUN-gebruik

Er zijn twee scenario's waarin dergelijke problemen kunnen optreden:

1. De klant heeft ruimtebesparingen aan de storagezijde ingeschakeld, zoals deduplicatie en compressie. 

Wat is deduplicatie?
Deduplicatie verwijst naar een methode om de redundante data van een dataset te elimineren. In een beveiligd datadeduplicatiebeoordelingsproces identificeert een deduplicatiebeoordelingstool extra kopieën van data en verwijdert deze, zodat een enkele instantie vervolgens kan worden opgeslagen. Software voor datadeduplicatie analyseert data om patronen voor dubbele bytes te identificeren.

Wat is compressie?
Datacompressie is een vermindering van het aantal bits dat nodig is om data weer te geven. Het comprimeren van gegevens kan storagecapaciteit besparen.

Deze ruimtebesparingen worden alleen uitgevoerd op de storage-array en daarom zal er een aanzienlijke gebruiksvermindering zijn op de LUN, maar de VMFS-datastore zal een hoger gebruik rapporteren volgens de bestanden in de datastore.

2. Klant heeft ingericht als thick VMDK

De extra verbruikte ruimte aan de VMware-kant is te wijten aan het feit dat de klant Thick provisioned VMDK's maakt in de Datastore. Bij het maken van een Thick provisioned VMDK op een datastore, reserveert VMware die ruimte in de datastore en beschouwt deze als verbruikt. Vanuit het array-perspectief zijn er geen echte data geschreven en daarom zal het een laag verbruik blijven. Pas als de host begint met het schrijven van data, begint de Unity LUN/Datastore op verbruikt te lijken.

Aangezien de VMDK thick provisioned is bovenop de VMFS-datastore, blijft VMware de ruimte weergeven als verbruikt, terwijl de array lijkt op de ware grootte van de geschreven data.

Als er een ruimtebesparing is ingeschakeld, is er geen oplossing voor een dergelijke situatie. 

Als er een thick VMDK-configuratie bestaat, hebben we twee opties. We kunnen de VMDK's maken als thin-provisioned apparaten of accepteren dat VMware de ruimte die wordt gebruikt door VMDK's met thick-provisioning behandelt als gereserveerd. Dit komt omdat het ruimte in de datastore reserveert op dezelfde manier waarop een dikke LUN de LUN-grootte aan groepsruimte verbruikt bij het maken vanuit de array. Daarom kan elke discrepantie in ruimtegebruik in dergelijke gevallen buiten beschouwing worden gelaten, aangezien dit een bekend effect is.