Home | GestaltIT | Enterprise Computing: The Wide Striping Debate

Enterprise Computing: The Wide Striping Debate

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

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.

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.
  • Pingback: Cinetica Blog » Chi è nato prima? l’uovo o la gallina?()

  • http://blogs.rupturedmonkey.com Nigel


    I think its worth pointing out two things –

    1. The UVM is for 3rd party storage only. No free UVM if you want to virtualise HDS arrays.
    2. The 10TB HDP amounts to very little in large enterprise accounts. 10TB is neither here nor there.

  • http://storagebod.typepad.com Martin G

    The risk you state very much depends on how the wide-striping is implementing and how the RAID is implemented. I’m sure Marc will be along to correct me if I’m wrong but in 3PAR’s implementation, the RAID is at the chunklet level and not at the disk level. This has positive advantages in the rebuild times but also a double disk failure is unlikely to the impact you describe. At least, that was my understanding of 3Par’s implementation.

    It is one of the advantages of starting without a legacy architecture…

  • Jason Jensen

    You beat me to it Martin. My understanding of 3PAR RAID as well is that it is at the chunklet level and not the physical disk level.

  • http://thestorageanarchist.com the storage anarchist

    Clarification came out today that “Free VP” is available to all VP-supporing Symmetrix platforms, new or already installed. DMX3 & DMX4 must be running Enginuity 5773; all V-Max arrays support VP with Enginuity 5874.

  • http://thestorageanarchist.com the storage anarchist

    Right now I can only say that reclamation of unused/all-zero space is just another common feature of thin provisioning. Likewise the ability to shrink a storage pool to remove/repurpose unused capacity (Hitachi DP doesn’t support this feature, V-Max VP does). Feature races are usually temporal – any feature advantage is generally short-lived.

    And indeed, if/when V-Max VP supports zero space reclaim, it will inherently be more efficient than Hitachi DP thanks to the smaller chunk/page/extent size of VP (768KB vs. 42MB).

  • http://blogs.rupturedmonkey.com Nigel

    Can any of the above who bring up 3PAR RAID at the 256MB chunklet level offer any more information on how this is better than traditional RAID Groups for lowering the risk of double disk failures?

    My understanding, albeit limited, is that it lowers the “possibility”, but that the possibility exists….

    Also the 3PARs dont currently offer the ability to create storage pools. Its all your eggs in one basket scenario with an albeit lower risk of double disk failure. However, other technologies offer the ability to create multiple pools and spread your eggs among multiple baskets.

    Im well aware of the limitations in the HDS implementation but am not so sure that its all that worse than the 3PAR implementation.


  • http://blogs.rupturedmonkey.com Nigel

    So Barry,

    In saying “..And indeed, if/when V-Max VP supports zero space reclaim, it will inherently be more efficient than Hitachi DP thanks to the smaller chunk/page/extent size of VP (768KB vs. 42MB)…” Are you suggesting that VP ZSR will be less efficient on V-Max than on 3PAR as 3PAR has an even smaller chunk/page/extent? Not as simple as that otherwise we’d probably all have 1K extents (OK obviously not but its not all that simple is it).

    And interesting that none of those extolling the virtues of 3PAR above have piped up with explanations of why what 3PAR does is better than what the likes of HDS and EMC do. Hmmmmmmmm! (or may be they dont follow the comments feed on here) No probs as Im pretty sure I already know anyway…….

  • Pingback: VIRTUMANIA Episode 5: Sir Mix-A-Lot Storage Virtualization | VM /ETC()

  • Pingback: zsr()

  • klstay

    Seeing Pure add the “compute layer” and become a hyperconverged platform would be far more interesting. First there is NetApp’s other than stellar track record with acquisitions providing long term value in any kind of a reasonable timeframe. (Sure, Engenio has been a nice-to-have for those smart enough not to run SQL on WAFL though still dumb enough to insist on a NetApp nameplate on the box.) Second, the kind of innovative thinking to pull that off left that building a long time ago. Third, the whole “hyperscale/webscale” thing is architectures that scale down poorly to the mere size of the majority of typical corporate datacenters.

    It is clear Pure is working on cluster style scale out, though when it will ship is anyone’s guess. It would be very surprising if that was not implemented with NVMeF. Personally I hope they stick to a 4 node limit initially which would make either ring or mesh interconnects doable with no external switching needed. Unlike VSP, but like 3PAR, inter-node commits prior to ack back upstream would be store & forward though over shared PCIe (NVMeF) instead of IP encapsulated as with Solidfire. Since for most workloads for must datacenter sized customers (yeah, just my estimate here) the majority of traffic is strictly ever with just one of those nodes. The important part is the active and passive controller in that node have continuous shared access over PCIe to the single pool of NVRAM. (At least IF I am recalling the architecture correctly; there is no dedicated per controller set of NVRAM necessitating a copy to other controller dedicated NVRAM process)

    There are two salient characteristics of that which make Pure more interesting as a potential hyperconverged platform; the size of “most” datacenter quantas of workload would obviate the need for ANY off node storage communication and the local compute hosting servers in a node (assume up to 4) would probably be NVMeF interconnected to the on-node storage (a la DSSD) thus eliminating ALL of the IP/ethernet overhead for volume access.

    Sure, today with SQL DBAs and programmers abusing tmp DB like they know they need to since commits are SO painful such a platform is not in the real world that much better than Nutanix. However, remove the constraint of commit space being thousands of time slower than in memory database transactions to being maybe only 10 times slower and those folks will figure it out. At that point such an architecture will crush IP encapsulated store & forward at the same price point.

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×