VAAI Posturing

With yet another HDS/VAAI post coming out from Scott Lowe (here), the irrelevant debate continues as to who is in and who is out of VMware’s inner circle of trusted storage vendors. Previously my friend Stephen Foskett discussed HDS’s position regarding VMware integration in this post, which followed on from an original post by Chris Mellor (who I hope would be happy to be called a friend of mine ).

So this is all great and understanding where vendors are heading in the future is nice to know, but perhaps we should take it back to today and the real world of using the current VAAI features. We’ve seen lots of posturing about who was first to support when VAAI first came out, but at the end of the day, what’s relevant is how this feature support works in practice. I’ve seen some good demonstrations of the technology, but as yet, there’s no meaningful measurement of who’s implementation of VAAI is best. Clearly it will depend on the underlying hardware and the way the engineers have chosen to prioritise VAAI workloads. I’ve not seen any answers to questions covering VAAI performance, if and how it could bring an array to its knees with overuse or how it can be controlled or prioritised. Oh and don’t get me started with the security implications. So for all of you out there involved in the discussion and promoting your VAAI support (that’s Scott, Heff and others), can you:

Provide real-world performance figures that show VAAI acceleration

Indicate how VAAI is prioritised/throttled from flooding a storage array

Explain how block copy functions are secure.

This degree of detail is much more interesting than discussing who’s in and out of the vStorage API Club.

As for the 3 points above, I’ll take the last one. I promised to follow up on it so expect a blog post soon. In the meantime, don’t question whether vendors have VAAI support – ask them how well that VAAI implementation works for you.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.

Could you please elaborate on “3. Explain how block copy functions are secure.” What are the security implications ? Thx

admin

Penta

Block copy enables data to be copied between LUNs on an array. The array acts as the data mover. From reading the T10 specification it seems like the way things are set up, is to specify source LUN & LBA then target LUN & LBA. There doesn’t seem to be any restriction on how the source/targets are specified. Therefore it’s theoretically possible to copy data from/to a LUN that doesn’t belong to you.

Regards
Chris

Penta Upa

Ok you mean that way. Then there is no issue IMHO. As you would know the XCOPY operation specifies the source and dest LUN. Internally they are identified by target identifiers, in the case of VMWare naa identifiers are specified. Now other than a bug in the array impl. the correct LUNs are identified.
Also There are a quite a few restrictions placed by VMWare on the Full Copy primitives. Both LUNs should belong to the same array etc.

I would however like to see how vmware go about VAAI (or similar) benefits with NFS. Nothing much written about it anywhere.

Regards,
– Peter

admin

Peter, far from it. As I say in my follow up, “Now, I’m not anti-VAAI in any way.”. Which is true, I think VAAI is a great idea for offloading unnecessary I/O. However my issue is with the fact this is such a powerful tool, we don’t know what controls are placed on it by vendors to make sure it has no adverse array effects, especially in shared environments. Traditional arrays are to a certain degree limited by the I/O which can be received on the front-end ports. This is one of the places where I’d be looking for problems if I had a performance issue on an array. Now with VAAI we have an issue where the array could be processing lots of internal copy requests but the storage adminstrator has no visibility of this; that’s not right. I definitely think we need VAAI but we need proper management and reporting with it to..

Thanks for the link you provided, I will check it out.

Thanks
CHris

Peter

Chris,

My apologies, I hadn’t read the followup before. I get the point you are driving at now. I think the solution is more analytics from the array side and probably a way of integrating (maybe a plugin) on vcenter side. Ofcourse i’m not aware of any vendors providing such data.

In my opinion VAAI or similar is eventually the way to go. Storage arrays with more control is always a plus like VAAI and dedupe i mentioned before.

The issue which you point out and i fully agree is tracking down issues on the array side. Administrators would need to dig deeper and learn new things to track VAAI issues on the array side.