Does VAAI Equal Improved Backup Speed?

[kmille1398]

Hi All,

Just curious for those using Veeam Backup and Replication against an and ESX 4.1 environment and SAN that supports VAAI....have you noticed improved backup speeds prior to upgrading firmware that supports VAAI and/or running ESX 4? We currently run ESX 4 with Equallogic PS 6010 SAN members. Currently running Equallogic firmware 4.37, and would have to got firmware 5.02 and upgrade to ESX 4.1 for VAAI. Would be a lot of work, but just wondering if faster backup speeds would come with it. If that was the case it might be worth it.

Kevin

[Gostev]

Hi, I would only expect improved snapshot operations performance. I know some of our customers have already upgraded to 5.0.2, so may be we can hear from them. Overall feedback so far was excellent (in terms of stability etc.)

[joergr]

Hi, stability of fw 5.0.2 is excellent.

VAAI covers: full copy operations, block zeroing operations and lock operations. Snapshots, Cloning, Turning on/off, vmotion, svmotion is faster and more slick, especially the locking is great, imaging creating large 1,9 tb luns and don´t have to care about scsi reservation locking conflicts, not bad, eh? But the speed is the speed is the speed - Or to say it in another way: VAAI can´t do supermagic, your backup speed will mostly stay quite the same.

A clone, or a zeroing operation (e.g. format) of course, from EQL LUN to EQL LUN will be faster than before FW 5.0 because the esx/i/vc will have to do nearly nothing, the san does it all for you.

best regards,
Joerg

[ctchang]

Hi, stability of fw 5.0.2 is excellent.

VAAI covers: full copy operations, block zeroing operations and lock operations. Snapshots, Cloning, Turning on/off, vmotion, svmotion is faster and more slick, especially the locking is great, imaging creating large 1,9 tb luns and don´t have to care about scsi reservation locking conflicts, not bad, eh? But the speed is the speed is the speed - Or to say it in another way: VAAI can´t do supermagic, your backup speed will mostly stay quite the same.

A clone, or a zeroing operation (e.g. format) of course, from EQL LUN to EQL LUN will be faster than before FW 5.0 because the esx/i/vc will have to do nearly nothing, the san does it all for you.

best regards,
Joerg

I am wondering the following.

Beginning with Equallogic version 5.0, the PS Series Array Firmware supports VMware vStorage APIs for Array Integration (VAAI) for VMware vSphere 4.1 and later. The following new ESX functions are supported:

•Harddware Assisted Locking – Provides an alternative meanns of protecting VMFS cluster file system metadata, improving the scalability of large ESX environments sharing datastores.

Does this means the previous Best Practice NO LONGER APPLY?

ie, Best Practice suggesting limiting per volume to 500GB and putting maximum 20 VM per volume. and create MULTIPLE volume to gain more performance. So with VAAI and FW5.0.2, I can simply create just ONE big volume say 1.9TB and put as many as VM as I want? Is it true? or the old Best Practice still apply? (ie, multiple smaller volume 500GB each and max 20 VM on each volume)

[joergr]

This is true - BUT you have to keep an eye an the latency. Many SAN Vendors won´t let their san focus all power to a single lun. So if you see the latency is too high i´d suggest you add another lun and distribute the vms and check again. If the latency is then better, this is the way your san likes it.

Best regards,
Joerg

[ctchang]

This is true - BUT you have to keep an eye an the latency. Many SAN Vendors won´t let their san focus all power to a single lun. So if you see the latency is too high i´d suggest you add another lun and distribute the vms and check again. If the latency is then better, this is the way your san likes it.

Best regards,
Joerg

I think I will use the old Best Practice as a foundation, that is 500GB 20VMs, but increase a bit to say 800GB and 30-50VMs on that lun.

[ctchang]

Update: Official Answer from Equallogic

Good morning,

So, the question is does VMware’s ESX v4.1 VAAI API allow you to have one huge volume vs. the standard recommendation for more smaller volumes while still maintaining the same performance?

The answer is NO.

Reason: The same reasons that made it a good idea before, still remain. You are still bound by how SCSI works. Each volume has a negotiated command tag queue depth (CTQ). VAAI does nothing to mitigate this. Also, until every ESX server accessing that mega volume is upgraded to ESX v4.1, SCSI reservations will still be in effect. So periodically, one node will lock that one volume and ALL other nodes will have to wait their turn. Multiple volumes also allows you to be more flexible with our storage tiering capabilities. VMFS volumes, RDMs and storage direct volumes can be moved to the most appropriate RAID member.

i.e. you could storage pools with SAS, SATA or SSD drives, then place the volumes in their appropriate pool based on I/O requirements for that VM.


So do you mean if we are running ESX version 4.1 on all ESX hosts, then we can safely to use one big volume instead of several smaller ones from now on?

Re: 4.1. No. The same overall issue remains. When all ESX servers accessing a volume are at 4.1, then one previous bottleneck of SCSI reservation and only that issue is removed. All the other issues I mentioned still remain. Running one mega volume will not produce the best performance and long term will be the least flexible option possible. It would similar in concept to taking an eight lane highway down to one lane.