VAAI Thin Provisioning is enabled by default [...] ]]> Last week VMware issued this advisory on their knowledge base, recommending the disabling of VAAI Thin Provisioning reclaim in ESXi 5.0.  Apparently it seems to be causing “poor performance’ during certain vSphere actions like Storage vMotion.  The “cause” section contains the somewhat vague comment as follows:

VAAI Thin Provisioning is enabled by default on devices that adheres to T10 standards. ESXi will identify Thin Provisioned LUNs and issue UNMAP commands to reclaim deleted space on the storage. The implementation and response times for the UNMAP command may vary significantly among storage arrays.

Note the “may vary significantly among storage arrays” comment.  There’s no list of who’s arrays are suffering performance issues and clicking through to the VMware Compatibility Guide, I’m unable to find arrays that claim to support the T10 plugin.  I’d imagine, based on this post from Chad Sakac and the referenced Scott Lowe blog post that we’re talking EMC arrays being affected here.  I haven’t seen any comments so far from other vendors.

This whole discussion brings me back to this post from a week or so ago.  End users need to know what controls have been put into storage arrays to control the effect of VAAI primitives on the array.  It’s a large risk to simply let hosts issue direct commands to the array that have such an impact on I/O.  Imagine having storage DRS also implemented.  It would be incredibly easy to create a scenario where far more work is being done to balance environments simply because too many VAAI requests had been thrown at an array.

Now, I’m not anti-VAAI in any way.  In fact I think the concept makes total sense.  Think back to in-array (clone/snapshots) and remote replication.  It makes so much sense for the array to handle that kind of heavy lifting and the same applies to VAAI.  Most sites wouldn’t give out the ability for end users and their hosts to perform infinite snapshots and replication failovers at will.  This function is best managed centrally, or through a controlled proxy that allows the storage administrator to suspend the use of snapshot commands.  This is essential if maintenance needs to be carried out on hardware or if there are performance or other issues being investigated.

What I’m saying is that we need both an understanding of how VAAI workload is prioritised against normal host I/O and an ability for the administrator to control/restrict the workload where required.  I still believe that neither of these options are in products from the major storage vendors.  I’d like to be proved wrong….

So far, only Hitachi/HDS have responded to my previous post – see Hu Yoshida’s post here – Weighing in on VAAI.  Come on the rest of you, I *know* you read what I write and your silence speaks volumes to everyone.

http://www.theregister.co.uk/2011/03/29/hds_storage_virtualisation_podcast/

Unfortunately we still didn’t have the Hu v Claus benchpress competiton, but hey….

In this picture are:

Point 1: I’ve paid for my 100% of storage and I’m going to use it.  I don’t [...] ]]> Hu Yoshida has an interesting view on his recent post discussing storage utilisation rates.  His concluding remark suggests running at a maximum of 60% utilisation – even with Dynamic Provisioning.  Hu, you must be joking, right?

Point 1: I’ve paid for my 100% of storage and I’m going to use it.  I don’t remember any vendor suggesting only paying 60% of their invoice and calling it quits.  Granted, spending an inordinate amount of time to reach the 80%+ goal isn’t necessarily cost effective, however it can be achieved.

Point 2: It’s perfectly possible to run at 80% utilisation.  It just takes some thought and planning.  As Hu rightly points out, Dynamic Provisioning helps significantly towards this.  The features of wide striping and thin provisioning mean storage can be more easily provisioned and requires less manual balancing.

Point 3: Achieving high utilisation isn’t all about technology.  It’s also about process.  That means Demand Planning, Capacity Planning, efficient processes for deployment of new hardware and for provisioning of customer requests.  All this is possible without incurring additional expense.

So, don’t think 80%+ isn’t an achievable target.  After all, it’s your money you’re wasting if you don’t try!

First there’s Martin Glasborow’s post, which discusses whether wide striping and thin provisioning should be chargeable items.  I’d go a step further than Martin and suggest that thin [...] ]]> I’ve read with interest this week the posts on wide striping and the consequent expansion to thin provisioning.  Here are some of the highlights:

First there’s Martin Glasborow’s post, which discusses whether wide striping and thin provisioning should be chargeable items.  I’d go a step further than Martin and suggest that thin provisioning (TP) should also be free; after all, over time thin provisioning becomes fat provisioning without some kind of reclaim technology and there’s only value to TP with something like Zero Page Reclaim to get back those unused blocks.

Then there’s Hu Yoshida’s post referring to the Overheads of Thin Provisioning.  In it, Hu makes a very interesting claim that wide striped LUNs have “greater protection from multiple disk failures”.  On this point I have to disagree.  Firstly, if a disk fails within a RAID group, then the impact on a LUN is only experienced if the subsequent failure is also in the same RAID group.  This is a fact whether then LUN is wide striped or not.  For wide striped LUNs which are spread across multiple RAID groups, there’s more chance of a failure because a double disk failure could occur within any of the RAID groups supporting the presentation of that LUN.

In addition, wide striping has more impact if a failure occurs.  One benefit of having LUNs created from a single RAID group is that the impact of that RAID group failing is limited to only those LUNs.  Imagine a 300GB 3+1 RAID group divided into 18x 50GB LUNs.  Failure of that RAID group impacts only the 18 LUNs.  So, wide stripe across 10 RAID groups – now the impact of any RAID group failure is 180 LUNs.  Remember that’s any RAID group failure, which is much more likely as we have more RAID groups on which every LUN is dependent.

Finally there’s EMC and their free Virtual Provisioning – free that is on new purchases, not existing DMX-4 deployments.  While laudible, this offering is less generous compared to HDS’ Switch It On promotion which offers free UVM, Dynamic Provisioning (first 10TB only) and Tiered Storage Manager on existing USP-V deployments.  

Wide striping and thin provisioning are clearly becoming features where vendors are looking to differentiate their products.  This must be vindication for the likes of 3Par who’ve had these features from day 1.

P.S.  You can find two EMC blogger references to the free Virtual Provisioning here and here.