In a previous post, I mentioned that one of the primary objectives of Storage enhancements in 5.0 is to make the management of storage much simpler. In order to do this we are trying to encourage customers to use much larger and far fewer datastores.
One feature that assists in achieving this goal is Thin Provisioning. However, there were two factors with Thin Provisioned datastores which raised concerns for many customers.
When VMs are deleted or migrated from a datastore, the array is not informed that these blocks are now free. This leads to array management tools reporting a much higher space consumption than is actually the case.
What happens when I run out of space (OOS) on my datastore? In the past, an OOS conditions could lead to all VMs on the OOS TP datastore being impacted.
A number of enhancements which include new vSphere Storage APIs for Array Integration (VAAI) primitives for Thin Provisioning are being introduced in 5.0 to address these concerns:
If a Thin Provisioned datastore reaches 100%, only those VMs which require extra blocks of storage space will be paused, while VMs on the datastore that do not need additional space contnue to run.
A new VAAI primitive (using the SCSI UNMAP command) allows an ESXi to tell the storage array that space that was occupied by a VM (whether it be deleted or migrated to another datastore) can be reclaimed. This allows an array to correctly report space consumption of a Thin Provisioned datastore, and allows customer to correctly monitor and correctly forecast new storage requirements.
A warning is now raised & surfaced in vCenter via VAAI if a Thin Provisioned datastore reaches 75% as per the screen-shot below. This allows an admin to proactively add more storage, extend the disk or Storage vMotion some VMs off of the datastore to avoid OOS conditions.
What about NAS Support?
Prior to this release, VMware only supported Hardware Acceleration on block storage devices. In this vSphere 5.0 release, we have also include a number of new NAS Hardware Acceleration primitives. Hardware Acceleration for NAS will enable faster provisioning and the use of thick virtual disks through newly introduced VAAI primitives:
Full File Clone – Similar to the “Full Copy” Hardware Acceleration Primitive provided for block arrays, this primitive enables virtual disks to be cloned by the NAS device.
Native Snapshot Support – Allows creation of VM snapshots to be offloaded the array.
Extended Statistics – Enables visibility into space usage on NAS datastores, especially useful for Thin Provisioning.
Reserve Space – Enables creation of thick virtual disk files on NAS whereas previously the only supported VMDK type that could be created on NAS was thin. Note the screenshot below which shows the ability to select lazy-zero or eager-zero disks on NAS datastore:
From a block primitive perspective, the final enhancement that I wish to discuss is to the Atomic Test & Set (ATS) primitive. ATS is used for locking on VMFS datastores, and is far superior to the SCSI Reservation locking technique. There is now more use made of ATS on block storage. One example is that in previous versions of VAAI ATS, when there was a mid-air collision of ATS (i.e. two ESXi trying to lock the same file), the VMkernel would revert to using a SCSI reservation. We no longer do this, but use an ATS retry mechanism.
To close, you may be interested to know how way we determine the overall VAAI status, and when do you see the Hardware Acceleration status as SUPPORTED, UNSUPPORTED or UNKNOWN in the UI.
The following if-then-else statement is a pretty good indicator.
if (ATS==supported)
VAAI = SUPPORTED
else if (ATS==notsupported && ZERO==notsupported && CLONE==notsupported)
VAAI = UNSUPPORTED
else
VAAI = UNKNOWN
Finally, we have also introduced a new vStorage API for Storage Awareness in vSphere 5.0, surfacing Storage Capabilities in vCenter. That will be discussed in a future posting.
