Before I unleash the posts on my VAAI Array project, I thought it best to make sure the readers are somewhat famiar with VAAI.
VAAI (vStorage APIs for Array Integration) is a feature first introduced in ESX/ESXi 4.1 and later expanded in ESXi 5.0. It is an API that was developed to enhance performance on the vSphere infrastructure by offloading several tasks to compliant Storage Arrays. *More on the compatible Storage Arrays later*
- Atomic Test & Set (ATS), Atomically modifies sectors on a disk without having to use SCSI reservations. This means that LUN access from other hosts won't be the locked. This should increase performance many fold, depending on how many hosts access the same LUN.
- Clone Blocks/Fully Copy/XCOPY, directly on the supported Array without having to resort to ESX software data mover and moving data to/from the hosts and to/from the Array. If VAAI is enabled, copying/cloning of data will move at the speed of the hardware Array.
- Zero Regional Blocks, Zeros out a large number of blocks on the Array for provisioning. This allows vSphere to speed up provisioning and do other tasks.
- Thin Disk Space Reclaim, this API uses SCSI UNMAP instead of SCSI Write and is based on VMFS 5.0. This basically tells the Array to write Zeros where something was deleted and then tells vSphere it's available.
Keep in mind there are several things to be aware of when using VAAI, so I want to list two of them that I think most will need to be aware of.
- If the source and destination VMFS volumes have different block sizes, then ESXi resorts to the default data mover. So suppose you used a 8MB block size on ESXi 4.1 and then upgraded to ESXi 5 and then as a result upgraded your file system to VMFS 5.0. You would think that the block size would either change or wouldn't matter, but the result is that it doesn't change the block size to the ESXi 5.0 default of 1MB. So if you add a VAAI enabled Array to the mix, then Hardware assisted offload won't work, until you recreate the datastores to be the same default block size.
- If the source VMDK type is eagerzeroedthick and the destination VMDK type is thin, then VAAI offload won't work.
This post was meant to be a short summary of VAAI. Feel free to comment on anything I missed or items that you think will benefit the readers.