Why Steel Fusion EDGE Block store reports 2 times data written to VMFS volume as uncommitted data? How can large amount of data copied from Branch Storage to remote LUN?

Categories:
Solution Number:
S26181
Last Modified:
2015-03-06
Solution

Q: Why Steel Fusion EDGE Block store reports 2 times data written to VMFS volume as uncommitted data?

A: Lets first quickly review storage volumes:

Core LUN: Storage volume/disk provided by Filer (ex: EMC or NetAPP). This LUN could be iSCSI or FC LUNs

Edge LUN: Core LUN projected or made available on Edge. (iSCSI only)

VMFS: File System created on LUN to be used by VMware ESXi servers

VMDK: File created by ESXi server. This file will be visible to Virtual Machine as disk drive. (For example, VirtualMachine MYVM's D: drive will be stored as MYVM_2.VMDK)

Storage Privisioning: (SteelFusion Edge blockstore is ONLY affected by Virtual Disk (VMDK file)  provisioning on ESXi, hence Filer storage provisioning is not discussed here)

Thin Provision: Minimal amount of storage will be allocated during LUN/Volume creation and it will be expanded as required.

Thick Provision: All the Storage will be preallocated.

VMDK Formatting:

Lazy-zeroed: A lazy-zeroed  disk is the default format of VMware and this completes formatting quickly. Each virtual disk block is zeroed only on first write. If the DataStore is on Steel Fusion Edge, this format leads to small amount of uncommitted data.


Eager-zeroed: An eager-zeroed format takes more time to complete because each virtual disk block  zeroed out at the time of creation. If the DataStore is on Steel Fusion Edge, this format leads to uncommitted data that is approximately equal to the size of the Virtual disk(VMDK file). This is because ESXi writes zeros on each virtual disk block during format operation. All those block writes should be sent on WAN to core and written to backend Filer LUN. As zeros are highly compressible, steelheads can achieve up to 90% compression. 

Now lets review the ESXi workflows and how they affect the uncommitted data and Edge block store space usage:

20 GB VMDK- Thin provisioned disk: small amount of uncommitted data, because minimal amount of storage will be allocated, thus small number of virtual disk blocks that require zeros written during format.

20 GB VMDK- Thick provisioned Lazy Zeroed (Default) : small amount of uncommitted data because each virtual disk block will be zeroed only on first write.

20 GB VMDK- Thick provisioned Eager Zeroed: uncommitted data will be approximately 20GB, because  ESXi writes zeros on each virtual disk block (This is the preferred method of provisioning disks on SF Edge)

Now lets answer the question:

If Virtual Machine disk of 20GB (VMDK file) is created using the vSphere defaults, it results into 20 GB VMDK- Thick provisioned Lazy Zeroed virtual disk. If we copy 10GB data to this disk, (assuming  it is a first write on the virtual disk), ESXi has to first write zeros on each disk block and then the data. This could result 20GB of uncommitted data (10GB of zeros and 10GB of actual data) and 20GB space utilization on edge blockstore.

Q: Data I want to move from Branch Storage device to remote LUN (aka Core LUN) is greater than 50% of my edge free blockstore. Simple copy is failing because blockstore getting full resulting edge LUN de-activation. How can I do this?

A: Please follow below procedure:

  • Provision the Target Virtual Machine disk as "Thick provisioned Eager Zeroed", as explained above, this will result uncommitted data ~ size of the VMdisk. Allow this fully commit back to core.
  • After commit is completed, copy the data to virtual disk, this will result uncommitted data ~ equal to the data written. This will complete the data copy.

Q: My Virtual Disk is already provisioned with defaults and I can't destroy the data to recreate it, how can I copy my data successfully?

A: Please follow below procedure (VMware KB: 1035823 has more details)

  • If the VMDK virtual disk is of type Thin, convert the disk to Eager Zeroed Thick using the vmkfstools --inflatedisk command.

    For example:

    vmkfstools --inflatedisk /vmfs/volumes/DatastoreName/VMName/VMName.vmdk

    Note: The inflate command reports the percentage of completion.

    If the VMDK virtual disk is of type Thick, convert the disk to Eager Zeroed Thick using the vmkfstools --eagerzero command.

    For example:

    vmkfstools --eagerzero /vmfs/volumes/DatastoreName/VMName/VMName.vmdk

    Note: The eager zero command reports the percentage of completion.
  • Allow the resulting uncommitted data to commit fully.
  • After commit is completed, copy the data to virtual disk, this will result uncommitted data ~ equal to the data written. This will complete the data copy.

Q: My data size is > than the total blockstore space or available blockstore free space how can I copy my data successfully?

A: This requires careful planning. Inventory the disk, copy just enough data that fits into blockstore, allow it commit and repeat the process till all the data is copied.

Q: Our IT policy doesn't allow to provision disk as "Thick provisioned Eager Zeroed" how can I copy my data successfully?

A: Please remember that blockstore needs 2 times the data that need to be copied as explained above. With that in mind, please plan carefully. Inventory the disk, copy just enough data that fits into blockstore, allow it commit and repeat the process till all the data is copied.

Q: Is there any tool that can facilitate the data copy?

A: MicroSoft tool "robocopy" can be used to copy data. Syntax and man page for "robocopy" can be found on MicroSoft Web page here.
 

 

Attachments
NOTICE: Riverbed® product names have changed. Please refer to the Product List for a complete list of product names.
Can't find an answer? Create a case