This is a post regarding VAAI (vStorage APIs for Array Integration). I have read some posts from Chad and personally, I don’t think I can do any better job than him to explain what VAAI is. However, I do can explain it from a user angle instead of manufacture perspective.
All right, let’s hit on the road.
What is vStorage API for Array Integration(VAAI)?
Essentially, VAAI is technology that Vmware use to offload certain disk activity/jobs to SAN to save Host I/O resource and improve performance and it’s enabled by default. From user point of view, this is still nice to have feature since the tasks you can offload are following.
•Hardware-Accelerated Locking = 10-100x better metadata scaling
–Replace LUN locking with extent-based locks for better granularity
–Reduce number of “lock” operations required by using one efficient SCSI command to perform pre-lock, lock, and post-lock operations
–Increases locking efficiency by an order of magnitude
•Use Cases –Bigger clusters with more VMs –View, Lab Manager, Project Redwood –More & Faster VM Snapshotting
•Hardware-Accelerated Zero = 2-10x lower number of IO operations
–Eliminate redundant and repetitive host-based write commands with optimized internal array commands
Use Cases-Reduced IO when writing to new blocks in the VMDK for any VM,Time to create VMs (particularly FT-enabled VMs
•Hardware-Accelerated Copy = 2-10x better data movement
–Leverage native array Copy capability to move blocks
Use Cases -Storage VMotion -VM Creation from Template
What kind of benefit you can get from using VAAI?
I believe the Vmware View will gain some performance boost when it try to provision more desktops. SAN can take load off from HOST. So it should be faster for View host to create more snapshots.
The other one is Anti-virus. For example, the new Trend Macro is using VMSafe API to scan and respond. Let’s see what Trend said about it.
How Core Protection for Virtual Machines product works is we take a snapshot of the Virtual Machine via the VMsafe API and scan the snapshot when performing the full system scheduled & manual scans, if malware has been detected we then send an instruction to the real-time agent for the mitigation process to initiate. The real-time scanning agent on the other hand performs On-Access scanning on the virtual machines which subsequently initiates the mitigation process if malware is identified.
With lots of creating snapshots during the scan, VAAI is definitely help a lot to Trend or CA anti-virus software.
so are you wondering how much performance it can gain?
Let’s see what Chad said about it.
Just one example (of many)… using the Full Copy API:
- We reduced the time for many VMware storage-related tasks by 25% or more (in some cases up to 10x)
- We reduced the amount of CPU load on the ESX host and the array by 50% or more (in some cases up to 10x)(by reducing the impact during the operation and reducing the duration) for many tasks.
- We reduced the traffic on the network by 99% for those tasks. Yes you read that right, 99%. During these activities (storage vmotion is what we used in the example), so much storage network traffic can be so heavy (in the example 240MBps worth of traffic), it impacts all the other VMs using the storage network and storage arrays.
And like Intel VT with vSphere 4, these improvements just “appear” for customers using vSphere 4.1 and storage arrays that support these new hardware acceleration offloads.
Where do these integrations occur?
There is nothing better than Chad’s blog, I just quote here.
To understand the dialog that goes with this, listen to the webcast (link below). As a point of note – while all vendors are working hard to integrate with VMware (which is good – highlights the importance of VMware in customer environments), to date, as far as I know, EMC is the only single vendor to have products available that integrate witheach of the areas in green. BTW – “co-op” means it’s an area where it’s not an integration API per se, but that there is a lot of cooperative development.
What are VAAI requirements?
Well, In general speaking, everything you purchased more than 2 years old won’t support the VAAI unless you update FLARE or firmware. As you can see from above picture, it requires “Vendor-specific VAAI SCSI command” loaded in the SAN. For users who are still using CX3 (32bit), it’s time to move on and end your current lease of SAN to get new one.
Still, quote from Chad:
What do you need to benefit from this hardware acceleration of storage functions?
- Well, of course, you need vSphere 4.1. VAAI is supported in Enterprise and Enterprise Plus editions.
- If you’re an EMC Unified (an EMC Celerra purchased in the last year – NS-120, NS-480, NS-960) or EMC CLARiiON CX4 customer, you need to:
- Be running FLARE 30 (which also adds Unisphere, Block Compression, FAST VP aka sub-LUN automated tiering, FAST Cache and more). You can read more about all the FLARE 30 goodness here and here if you’re interested in more detail about what’s new in that release. FLARE 30 is going to be GA any day now…
- Also, ESX hosts need to be configured to use ALUA (failover mode 4). If you’re using a modern EMC Unified or CLARiiON CX4 array, using ALUA (with the round robin PSP or PowerPath/VE) with vSphere 4.0 or vSphere 4.1 is a best practice (for iSCSI, FC and FCoE). We will be automating configuration of this shortly in the always free EMC Virtual Storage Integrator vCenter plugin, but for now it’s pretty easy to setup manually.
- If you’re an EMC VMAX customer – it will be a bit longer – but not much, but VAAI support is in the next major Enginuity update scheduled for Q4 2010.
- It is supported on all block protocols (FC, iSCSI, FCoE)
What are the catch?
- When does a VAAI offload NOT work (and the datamover falls back to the legacy software codepath) if all of the above are true?
- The source and destination VMFS volumes have different block sizes (a colleague, Itzik Reich, already ran into this one at a customer, here – not quite a bug, but it does make it clear – “consistent block sizes” is a “good hygiene” move)
- The source file type is RDM and the destination file type is non-RDM (regular file)
- The source VMDK type is eagerzeroedthick and the destination VMDK type is thin
- The source or destination VMDK is any sort of sparse or hosted format
- The logical address and/or transfer length in the requested operation are not aligned to the minimum alignment required by the storage device (all datastores created with the vSphere Client are aligned automatically)
- The VMFS has multiple LUNs/extents and they are all on different arrays
Last but not Least:
First of all, there are other voices from Netapps. From this link, you can clearly see How Netapps work with VAAI technology. If we think about from Microsoft and Citrix angle, what are they going to do to offload snapshot and vm copy from host to storage? Will VAAI become a public protocol and APIs to be loaded by all Virtual platform?
And what happened to that missing feature of VAAI, Thin Provisioning Stun?