I thank those who have made positive comments on my behalf, it is most appreciated.  I find it even more [...] ]]> Well, it appears from comments on recent blog entries that I’m all of the above!  The post(s) in question are as follows;

• http://www.thestoragearchitect.com/2010/08/02/netapp-the-inflexibility-of-flexvols/
• http://storagebod.typepad.com/storagebods_blog/2010/08/and-bod-makes-three.html
• http://www.grumpystorage.com/2010/08/notapp-random-thoughts.html
• http://blog.nigelpoulton.com/netapp-some-good-and-some-errrrr/

I thank those who have made positive comments on my behalf, it is most appreciated.  I find it even more amusing that my style of writing has been described as tabloid.  Perhaps I need a few more appropriate blog titles.  How about the following: Netapp ate my Hamster or Gotcha! (when EMC outbid Netapp for Data Domain).

The things I write about are coloured by the work I do – which is for and on behalf of customers.  It’s my job to cut through the marketing hype and understand the real issues in deploying and managing technology in the most efficient and cost effective way.  No vendors are without faults and I can point to many posts that place each vendor in a negative light.  However in my defence where I see something I like, I also talk about it.  If you don’t like what I write, I urge you to unsubscribe now.  If you do like what I write about, I’d appreciate your views on what else you’d like to see me discuss.  If you have something to say, then leave a comment that can be treated as courteous.  I always post comments – apart from the SPAM ones.  I’m happy to discuss things in a reasoned manner and to admit when I’m wrong.  You never know, if we continue in that manner we all may just enjoy the blogosphere more.

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.

The subject today is Tony Asaro’s rant on one of StorageBod’s recent posts denegrating virtualisation.

Now let’s get things clear – I like HDS’s implementation of virtualisation. I’ve deployed it, I’d recommend [...] ]]> For the second time in two days I find myself drawn to comment on a Storagebod related post.

The subject today is Tony Asaro’s rant on one of StorageBod’s recent posts denegrating virtualisation.

Now let’s get things clear – I like HDS’s implementation of virtualisation. I’ve deployed it, I’d recommend it again, but some of Tony’s comments are way off base.

“The cost per GB for your DMX FATA and SATA drives is much higher than using other tiered storage solutions.” – yes, but UVM ain’t free – there’s a licence charge. When you virtualise an array, you’re not paying for just JBOD, you’re paying for extra stuff like the controllers. Also on the USP array you have to reserve out ports for virtualisation; if you connect the storage together through a fabric then you’ll be taking up fabric ports too. The point is, the cost of HDS virtualisation means there’s a break even point in the TBs of storage – from my experience, that was a big number.

“Storagebod does not want to have applications span multiple storage systems but other IT professionals are open to doing this. And storage virtualization is a powerful technology to enable this. That is the point of any virtualization technology – to overcome the physical limitations of IT infrastructure.” – there are very good reasons for not spanning arrays with applications, like ensuring replicated storage is consistent, for instance. Whilst virtualisation allows a virtual array to grow in size to almost limitless amounts (247PB in USP V) it also means there’s a concentration of risk; multiple components to fail, multiple places where data can be pinned in cache when things go wrong. In fact, placing data on lower availability arrays will increase risk.

“That may be true for Storagebod but that is not my experience in most data centers. We are shifting from transactional data being the “big space-hogs” to unstructured data consuming the lion’s share.” – this may be true, but USP LUN-based virtualisation isn’t going to help here. Overlaying file-level granularity data migration onto LUN-based arrays would require a particularly complicated scheme for ensuring data for migration was concentrated onto exactly the right LUNs so they could be moved to another tier. Anyway, why put unstructured data on expensive enterprise arrays?

I think we all expected Tony would have something better to talk about than technology HDS brought to the market 4+ years ago. We need to hear something new, something game-changing (oh and not me-too stuff like HDS putting SSDs into their arrays).

Tomorrow I *promise* I’ll talk about something else.

Apart from when I worked in the mainframe storage arena, I’ve always struggled with SRM tools. Just for reference, the [...] ]]> Martin (Storagebod) has an interesting post today. Rather than post a long reply, I’ve chosen to steal his thunder and post specifically on the subject – of SRM tools.

Apart from when I worked in the mainframe storage arena, I’ve always struggled with SRM tools. Just for reference, the mainframe was great – SMS did the job, although there were a few shortcomings like the lack of quota tools. In the open world, things are so, so different. I think the reason open systems is a problem relates to the fact that although standards exist, technology is all different.

Look back at my recent post; there are two fundamental issues happening here. First of all, each vendor has a different implementation of technology – EMC/HDS/IBM/3Par/Pillar/Equallogic, the list goes on. Why are they different? Because there has to be something to create a USP, a differentiator. Sure, front-end technology might be consistent; each vendor will implement LUNs and the fibre channel standards, but in reality the back-end deployment will be different as each manufacturer competes on features and functionality. The same applies for the switch vendors, NAS vendors, and so on.

SMI-S was meant to address these problems but never would as it basically dumbs down each vendor to a single set of features and doesn’t address the platform specific functionality. Try using IBM and HDS arrays from ECC (in fact, try managing EMC arrays like Clariion from ECC) and you’ll fall at the first post. I won’t even suggest trying to use any other product like HiCommand…

Some software vendors have tried to do cross-platform SRM. Think of Creekpath. It failed miserably to offer cross platform support because (as Martin rightly states) they never understood how Storage Admins did their work.

The answer to the lack of an SRM tool would be for an independent to develop one. However there’s one major barrier to entry and that’s the vendors themselves. All the major vendors make a tidy profit (Martin’s cash cow) from their SRM tools – software without which you could do *nothing* but for which you are obliged to pay. Why would those vendors give up that monopoly position?

I’ve been working on a tool for some months (see here) which will provide cross-platform reporting, but full SRM is another step again. Without full vendor support, and by that I mean full knowledge of the APIs and interfaces to their products, not just the standard SMI-S providers – and advance notice and access to new features -then developing an SRM tool will be impossible.

However if anyone is prepared to pony up the cash, I’m still up for it!!