Storwize V7000 and VMware vStorage APIs for Array Integration (VAAI) – Block Zero

There is a ton of information already available online which covers the vSphere 4.1 VAAI implementation so I’d rather focus on how it relates to Storwize V7000 and SAN Volume Controller.

VAAI allows certain VMware tasks to be offloaded to the storage array.  The 4.1 release of VAAI includes three primitives one of which is the focus of this post:

Hardware-accelerated Block Zero

By default .VMDK disks are created as zeroedthick.  Which means a 50GB .VMDK has the full 50GB of space allocated on the VMFS volume, but that space is not formatted until needed.  By comparison another disk format, eagerzeroedthick fully formats the .VMDK with zeros before use.  The Block Zero primitive aids in the creation of eagerzeroedthick disks by eliminating the redundant host write commands with a single command, and allowing the storage array to handle the rest.  The following two images show the throughput on the Storwize V7000 performance charts of a format operation without and with VAAI enabled:

As the images depict, utilization on the Fibre Channel interfaces on the Storwize V7000 is eliminated for the VAAI enabled operation.  This is benefit #1 of hardware-accelerated Block Zero.

Benefit #2 is that tasks are faster, in some cases dramatically faster.  Take the above example.  A 50GB eagerzerodthick .VMDK was created two times.  Once with VAAI disabled, and another time with VAAI enabled.  The following graph shows the task times:

Deploying a eagerzerodthick .VMDK is not the only beneficial use case for Block Zero. VMware recommends that eagerzerodthick .VMDKs be used for throughput intensive workloads.  This ensures that you get maximum performance for your workload.  Otherwise if the default zerodthick format is used, each block of data must be initialized before it is written too.  But what if you forget to follow the recommendation and create a default .VMDK for that new virtual machine which is storing video surveillance footage (first example that came to mind).  Well with VAAI, don’t worry about it!  Throughput to zerodthick .VMDKs with VAAI enabled, is significantly better than with VAAI disabled.

What this basically means is the performance penalty normally found with write operations to zerodthick .VMDKs is eliminated if VAAI is enabled on the system.

My next post will talk about another VAAI primitive, hardware-accelerated Full Copy, and the types of results I observed for it on Storwize V7000 and SVC.

 

Advertisements
This entry was posted in Performance, VMware. Bookmark the permalink.

3 Responses to Storwize V7000 and VMware vStorage APIs for Array Integration (VAAI) – Block Zero

  1. ibmbcrsian says:

    Interesting stuff Rawley – I’m trying to get to grips with our recent V7000 + Cisco Nexus MDS’s + HS22v”s + x3850 ex5’s installation + VMware VAAI + VMware Performance for Extreme I/O – over and above our ‘older’ wintel estate in Warwick (UK). This article gives some further clarification – good work and thank you!

  2. ibmbcrsian says:

    ……oh, and WordPress! ;o)

  3. Pingback: Administer hardware acceleration for VAAI - The Foglite

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s