StorageRap

The absurd prognostications for storage in a stack

 

How is it that some people possess the gift of foresight and the ability to predict the future?  Some say they have dreams or visions, some extrapolate from experience and logic, while others make predictions hoping to fulfill an agenda. Then there is the element of public exposure. Is the predication public and do they use their real name or hide behind an alias? 

Nicholas Carr took was very public and very open when he wrote his breakthrough book "Does IT Matter?".  In it, he stated that there are no sustainable advantages to be gained by a company through the implementation of information technology.  He argued that any short term gain can be matched by competitors in a relatively short period of time with lower capital investments - effectively punishing companies for innovating. He recognizes the necessity of having IT in order to stay competitive, but finds it difficult to justify being an early adopter of technology.

Since Carr published his book, we've seen a lot of change in IT markets, including the rapid deployments of virtual systems technology and the expansion of hosted, utility computing and all things "cloud."  But the biggest changes have resulted from the global financial crisis, forcing companies to reduce non-essential costs significantly - especially IT costs.

Unfortunately, not every technology implementation intended to reduce costs has been successful. And that's one of the things that makes the information technology business so fascinating and perplexing - intelligent people with deep expertise in technology fail to predict the ways that things can go awry and what the cost of their shortsightedness will be. 

The rich history of failed IT projects is exactly why there is so much FUD spread by the competitors in our industry - FUD gets customers thinking about the consequences of their purchase decisions and all the possible problems that can result from an error in judgment. It also contributes to the interest in the machinations of our industry and the "war games" that are played out in traditional and social media. Whether we are predicting changes to the industry through mergers and acquisitions or the development of new business models, it all flows into the river of FUD at purchase time.

With the abundance of FUD, one naturally develops an aesthetic for the stuff to cull the weak from the strong. For example, a piece of weak FUD recently appeared online on Silicon Angle titled "Why Netapp Must Seek Acquisition", written by the poser "secretcto".  The author starts with the suggestion "let's take a look at the market cap of each of these players" and then neglects to make any comparisons. It goes downhill from there, reaching its lowest point when the article referred to Nicholas Carr as Daniel Carr and then failed to negotiate the transition of whether or not IT matters to cloud service providers. The tipping point for Carr's logic is that to service providers, IT absolutely does matter because operating data centers is their core business.  

By contrast, you barely notice good FUD, it has a smooth logical flow and subtly builds to a persuasive conclusion based on a key point that usually has it's origins in a subjective opinion or bias. A decent example of good FUD was Chris Mellor's recent piece about the Storage Array Killing Fields qualifies as good FUD.  Chris doesn't have an axe to grind, but he is a journalist and therefore has the responsibility of stirring the pot.  It's a well written piece that uses an analogy that compares the selection of equipment for data centers with the selection of components used in an automobile.

The problem is that automobile manufacturing is a poor analogy for running a data center. When a car rolls of the manufacturing line it is shipped to a dealer, sold to a customer who drives it away.  There is nothing about the experience of making, selling or buying a car that is even closely related to the constant ongoing data processing services that are provided by a utility or cloud service provider. 

A better analogy is running a restaurant. Restaurants succeed or fail based on the quality of their customer service and that's why chefs like Thomas Keller strive to maintain consistent, excellent quality every minute of every day they are open.

Should we expect the recipe for success in hosting and cloud services to be any different? This recent article in Information Age states that 71% of the 450 CIOs in a KPMG survey want to improve the price to quality ratio of their outsourcing contracts. The dynamics of the business relationship between CIOs and their utility/cloud service providers are going to be the same. Service providers with the best reputations for customer service are going to thrive. Those that don't measure up will fail.

Vendors of consolidated stack solutions of servers, storage and software are trying to convince customers that the "All-in-one" stack solution is the safest way to proceed during the transition period while cloud computing is emerging. They would have you believe that the biggest risk in operating a data center is in ordering the products and getting everything installed initially. Considering that customer metrics for utility/cloud service providers will be responding to the needs of their customers quickly and accurately, the lions share of the risk will come well after the initial installation during the life of the service engagement.

The weakness of the All-in-one approach is that it does nothing to address the dicier aspects of owning, operating and changing an IT infrastructure after it is up and running. In many cases the stack vendor's answer to change management will be the same as it is today - time-consuming and expensive professional services.  There are definitely utility/cloud service providers that will want this sort of service, but many would prefer to do it themselves at much less cost. That's what you do when your primary business is running a data center.

A talented chef can find a way to prepare a gourmet meal on an Electrochef All In One Kitchen, but they would never decide to run their business with them. They are going to select best of breed appliances and equipment that best fit their needs and enable them to prepare quality dishes in a quality fashion.

So the question for the utility/cloud data center operator then is - "what is best of breed equipment for my business?" 

The classic clash between Best-of-breed and All-in-one solution pits cost against complexity. Best-of-breed technology has traditionally been more customizable to fit a wider range of requirements and therefore has been more complicated and expensive to operate. In contrast, All-in-one technology has traditionally been cheaper, limited to a smaller set of functions and easier to operate.

Unfortunately, neither stereotype works very well for the utility/cloud service provider. They need fully functional products that are also easier and quicker to operate. Fast, accurate change management and operator efficiency are the key elements for utility/cloud infrastructure products. 3PAR's Best-of-breed storage products have these characteristics as well as being extremely space-efficient and high-performing. Customers appreciate the amount of time they do not spend managing their 3PAR storage while they are getting the job done. When a new order comes into a 3PAR kitchen, the system is ready to go right away - including tasks that take a long time to set up on other storage, such as Remote Copy.

And what about the All-in-one stacks in the market?  Surprisingly, unlike traditional All-in-one solutions, they are more expensive to install and operate.  Change management is complex, which leads to relatively poor operator efficiency and the engagement of professional services, which does not necessarily speed up the process. The traditional benefits that All-in-one solutions typically provide are not part of these stack solutions.

The predictions for stacks taking over the market are all wrong. Sure, there will be stack solutions sold and it will take time for all of this to sort itself out as it always does when an industry is going through major, fundamental changes. The most important changes that will occur in the years to come will be driven by the service demands placed on utility/cloud service providers. Customers of utility/cloud services want their money's worth and the best service providers will do what it takes to give it to them. Stacks add no value in that equation.

The transparent facts of open benchmarking

Nate at Techopsguys has put together a comparison of SPC-1 benchmarks with six different bar charts showing the various characteristics of the configurations, performance and cost.  

Here's an example of what's in is post.

 

Knobs, Prison Knobs and STACK WARS

Technology integration makes computing products much easier to use and significantly drives down the cost and effort of owning it. For instance, technologies such as WiFi that were recently beyond the grasp of most people are now inexpensively integrated into PCs and usable by almost anyone.

The trick with integration is understanding what variables should be exposed - or as my friend Rick Vanover likes to say - how many knobs there are to turn.  End user and infrastructure provider requirements differ considerably when it comes to knobs. For instance, Apple computers are great end user machines because they lack knobs, but are not always loved by technology professionals for the same reason. Data center operators need products with knobs in order to accommodate all the cross-purposed requirements that stretch beyond a one-size-fits-all design.

So knobs are generally good - but like so many things - their usefulness depends on how effective they are and their station in FARLEY'S HIERARCHY OF KNOBS, which includes the following levels:

Suicide Knobs:  knobs that delete data and make things blow up.  A good example of a Suicide Knob is something that formats storage.

Prison Knobs:  knobs that make changes that are very difficult or impossible to reverse.  Many storage provisioning knobs fall into this category. Once you provision and reserve storage with most storage arrays today you are stuck with that decision until the array's EOL.

Faux Knobs:  knobs that never seem to do anything, no matter how far you turn them.  For features past and future, but not now.

Random Knobs:  knobs that produce unanticipated results that can go unnoticed for years.  These are the knobs that fuel the technical publishing industry.

Slippery Slope Knobs: knobs that start you down a path to ruin through a chain of system dependencies. These are the knobs you spend a lot of money to learn about in vendor classes. 

Dumb Ass Knobs:  knobs that do things, but not anything useful. Granted there is a LOT of subjectivity in making a call on a dumb ass knob - but we all agree they exist.

Honest Knobs:  knobs that actually do something you need them to without having to plan for weeks on how to use them.  Most knobs should fall into this category, but alas!

Magic Knobs: knobs that do things so useful it makes you wonder how anybody thought of a knob like that. Most of these knobs are actually Honest Knobs, but we are so accustomed to seeing Suicide, Prison, Faux, Random, Slippery Slope and Dumb Ass knobs that we are blown away by a truly great Honest Knob.

Which brings me indirectly to the discussion of STACK WARS,  which, have been centered around the announcement of VCE (VMware\Cisco\EMC) and their vBlock concept last November. 

 

I'd like to say I was surprised yesterday when graphically-challenged Hitachi announced their intention to sell their own Unified Cloud Graphic, (complete with Hitachi compute servers!).  But it wasn't a big shock considering their marketing strategy of "just copy it".  

 

I really don't know how they expect their graphic to compete with vBlock's graphic, with all the color, multiple font sizes and graphics within graphics.

What's missing from the both stack graphics are the knobs that administrators use to get real work done.  Yes, knobs tend to be part of the underlying details, but to anybody that actually uses a product, they are very important details. The detail that C-level executives need to understand is that the stack does not have nearly the automation that is being promised today and that administrators will be doing a lot of work, turning the knobs that the stack provides. Again, it's not the number of knobs that matters, as much as it is the quality of those knobs.

Some people have speculated that the vBlock was a knob-less invention that originated in the board rooms of the VCE companies. Some have even suggested that it was the fallout after a failed acquisition bid by Cisco to acquire EMC.  I don't know if THAT's true, but there is some evidence that the engineering groups in the companies involved have been scrambling to put meat on the bone.

Maybe someday stacks will be the next big thing, but I don't see it playing out that way unless an awful lot changes in the underlying products that make up the stack. Here's my take on STACK WARS:

STACK WARS give everybody something to write about- me included, right now!

Bloggers that write about stacks have a chance of getting jobs with stack vendors. If you are out of a job, start a stack blog today and twitter your back-stack off!

Stacks are all about packaging. Stacks will be assembled and shipped together (presumably), which could make things easier if your goal is to streamline receiving.

Stack products, are actually more services than products. However, if you ever want to make configuration changes in your stack it might not be economically feasible. (Think gigantic FRUs) For example, there is not a lot of flexibility in vBlock's configurations.

Due to the limited configuration options, stack resources are not likely to be used very efficiently and the economic return on the investment will lag. However, EMC customers are already accustomed to low storage utilization levels - so poor utilization might not be THAT big a deal. Definitely a weird way to win a point, but I 'll concede it grudgingly.

The business advantage of integration should be much lower costs. However, the VCE companies all need to maintain their margins if they want to satisfy investors. It's not clear how they will be able to leverage the integration effort to reduce the cost of vBlock, but then again if STACK WARS turn into PRICING WARS for STACKS, things could get very interesting. IBM must be STACKING up something - after all Hitachi already beat them to the punch.

The C level view of stacks are that they smooth out purchasing and operations expenses by providing a smaller number of Purchasing Knobs (that would be a Faux Knob).  John Nash posted in his blog last week,"The Case for the vBlock":

What is interesting is that, usually, the higher up in an organization you are communicating the better the Vblock conversation goes. Remove the detailed technical questions and the value of the Vblock idea really shines. You get a known “product” from trusted sources. You get known costs today as well as known costs for future expansion. It greatly removes the risk from the organization with unknown infrastructure expenses.

There you have it, vBlocks will be sold from the top down by Cisco and EMC - companies that are good at selling from the top down, which will make it somewhat easier for the VCE companies to justify their price tag. But that won't make the price any easier to swallow. 

As Nash wrote, "remove the detailed technical questions and the value of the Vblock idea really shines."  That's like saying chapulines (fried grasshoppers) might appeal if Anthony Bourdain is talking about them on TV, but your own personal experience chewing and swallowing them might be different. I'm not talking about price here, I'm referring to the experience of running the vBlock. There is going to be a lot more involved than the knob-less graphics portray.

The weakest link in the vBlock chain today is EMC's contribution.  There are far too many Prison (provisioning) and Slippery Slope Knobs in EMC storage.  They aren't the only vendor with this problem, but they are the E in VCE.  Provisioning storage with a v-Max is the about the same as it was with a DMX - despite what EMC employees would have you believe. 

Prison Knob provisioning creates a lot of problems for customers as storage ages and as demands shift.  Once storage has been reserved for usage in an EMC system, it is pretty much bound to that purpose. 

My advice is to buy the products with the most Magic Knobs and avoid those with the most Prison provisioning Knobs. If you have ever felt trapped by a storage configuration that you couldn't live with or afford, you know what I'm talking about.  Magic Knobs are those that reduce the effort to manage and change storage, increase the efficiency of storage and provide the most versatility for all applications, workloads and multi-tenancy.

Top 10 Reasons HDS is out at Oracle

 iKnerd (Greg Knieriemen) broke the story yesterday about Oracle/Sun breaking off their relationship with HDS.  That got everybody twittering -  with the majority of tweets from the storage universe suggesting Oracle had greedy motives. How unfair!  So, the video below attempts to restore balance to the universe and brings Netapp, HP, cloud computing, 3PAR and Larry's toys into the discussion.

If you are a Sun storage customer and think its time to change, you should check out 3PAR. We have a lot of ex-Sun server engineers who designed our storage cluster. I'm sure you'll appreciate the architecture of our InServ arrays, as well as our 50% capacity reduction guarantee.

(Hey, Claus Mikkelson at HDS. I've had a comment in on your blog for a couple days and it hasn't  been posted yet.  I know things can slip through the cracks sometimes, so I thought I'd bring it to your attention.)

Customer says 3PAR's online upgrade process is "Easy as Pie!"

From a customer's blog:

In the last few weeks 3PAR released a major software upgrade for their arrays which enables a boatload of new features, including enhanced thin provisioning, autonomic provisioning, and RAID-MP. Today I performed the upgrade to Inform OS 2.3.1, and it went without a hitch and was quite easy. Unlike high-end arrays from Hitachi, EMC, and IBM, the upgrade process is not complex and took no more than an hour of time.

The whole blog post is here:   Thanks for the kind words,  Derek!

Click on the image below to find out about our capacity guarantee program. The program EMC doesn't want you to check out.

EMC skating in the rear with IBM, HP (and Oracle/Sun) at the back of the capacity garantee derby

As Mike Riley points out on his Netapptips blog today, I was not exactly a fan of Netapp's guarantee program when it first came out, but now I am an unabashed supporter.  Sometimes other vendors come up with excellent ideas. 

Yesterday HDS announced their capacity guarantee program and although it depends heavily on the capacity differences between RAID 1 and RAID 5 (which is a little cheesy), they offer a contract and appear to be ready to put back the program with more than a hand wave. That leaves HP, IBM and EMC (oh wait - and Oracle Sun) as the major storage players who aren't offering a capacity guarantee for customers making a technology refresh on storage.

 The question is - are these programs just marketing ploys?    Sure they are, just as any customer satisfaction guarantee for any product is a marketing ploy designed to hook customers - whether it's soap, kitchen knives, bass lures, vacuum cleaners, etc, but these ploys and the products behind them are targeted directly at data center operators that are tired of over-spending on storage. All are serious products from some of the biggest names in the storage industry and proven technology leaders.  3PAR's thin technologies (provisioning, conversion, persistence, reclamation and zero-detection) continue to lead our industry.

Depending on the applications and requirements of your data center some of these products and programs will be a better fit than others.  All of them should save you money on capacity purchases, but there are other things to consider, such as required software and services.  The details of each vendors' programs are different. That said, if you are offered a contract to reduce your storage capacity costs, that's pretty strong negotiating leverage with any other vendor - whether or not they offer a guarantee.  And even if you are not ready to make a purchase now, you might want to know how these programs work so you can be better prepared when the time comes.

To find out more about 3PAR's capacity program, click the image below. 

Storage is the Cookie! And sharing is beautiful!

A long time favorite of mine, Chris Evans: aka the StorageArchitect, has a new post on thin storage.  After he maps out the way disks are virtualized by thin provisioning systems, he writes about storage utilization before moving to open a brief discussion on storage reclamation, something he has been leading the charge on in the storage blogosphere over the last year or so.

He starts the discussion on reclamation by showing how file systems consume storage space and the typical inefficient utilization that follows. He ends the discussion by stating:

In a thin provisioned environment, storage would have been requested only for the blocks with valid data and in this way, a LUN can be less than 100% allocated.

Some readers might be tempted to think that LUN allocation percentage and has an inverse relationship to disk utilization,  - in other words, the lower the LUN allocation is, the higher the disk utilization is likely to be.  While that may appear to be the case, there are too many variables involved to say there is a mathematical (linear or otherwise) or causal relationship between them. Filing software, such as file systems, databases and virtualization platforms, that allocate capacity from storage, tend to consume more storage over time as users and applications create new, incremental data and files.  It follows that the percentage of a thinly provisioned LUN that is allocated is likely going to continue to increase over time.  Think of it as storage entropy, which might be some sort of new digital law (the amount of consumed storage in the universe is always increasing) enforced by the extremely high probability that we will continue to create lots more data all the time.

And this is where the idea of 3PAR's thin reclamation, persistence and conversion technologies come into play. These technologies are designed to deal with the ongoing life cycle problems of storage entropy, such as deleted files and in a virtual systems world - deleted systems. But more on that in posts to come.

Returning to Chris' post, it's fitting that he chose a Sesame Street analogy, considering that Sesame Street celebrated it's 40th anniversary last week.  He makes the point that storage can share capacity (cookies) among filing systems through reclamation and suggests four kinds of storage cookie monsters; greedy, selfish, nice and saintly.

As much as I love the Sesame Street gang (especially Grover), I'd suggest that the real Cookie Monsters are the filing systems (file systems, databases and virtual system platforms), and that the cookies are storage capacity. Filing systems have been historically bad at sharing the storage cookies they have been given and Symantec's Storage Foundation is truly a breakthrough product designed to share it's capacity cookies with any other filing system in the neighborhood.  Saintly behavior, indeed!

But the filing systems are not completely to blame here because storage hasn't provided the means for sharing allocated capacity. As in any system, the hardware and software have to move in something resembling unison. The way storage cookies are shared is by taking capacity that was previously allocated to a filing system and returning it to some form of unallocated storage plate. Using the Sesame Street theme, capacity reclamation is the process of putting storage cookies back on the array's plate where they can be allocated all over again by the monsters in your digital neighborhood.

Did I forget to mention that I LOVE data storage!  (munch munch munch munch....)

 

dw'Ville: the CTO role in social media

Chinese Take Out, Combative Technical Operative, Competitive Technology Obfuscator, Compulsive Twittering Object, Chief Pimp Online.

Storage bloggers showcasing their talents!

OK, the talent show of the decade is on!  The League of Suspicious Avatars (LOSA) has been working behind the scenes to bring you the very best of the storage blogosphere, complete with an astounding panel of judges.  Remember to submit your comments about who you think shows the most talent!

The group blogging circus and FUD findings: Anarchist, Enrico, Hu and the no shows from Compellent

(Author's note:  a couple typos in the next to last paragraph have been corrected, which should make things clearer  -mf 8-08-2009)

It's funny how things work in the stoblogosphere.  The  Anarchist goes after my reservationless post and steps in a pot hole of tchit and in the process brings blogging newcomer Enrico Signoretti - a Compellent reseller from Italy - out of the woodwork to howl about the stench. 

A couple things about what Anarchist and Enrico said brought to light that people get 3PAR and Compellent confused sometimes. Mostly these are financial people - but lately Anarchist seems to be looking for a new career as a financial analyst as the long slow decline of Symmetrix sets in. Anyway, I felt compelled  to point out the differences between 3PAR and Compellent, which got Enrico's attention again and like a true defender of the faith he posted on some things he felt I mis-spun.  God, I love blogging.  And for money's worth - it is much, much richer than  twittering.

Of course, as things go, I recognized some pretty lame Compellent FUD that they have been feeding their resellers for some time now about 3PAR's hardware, which reminded me to post about it because it's actually a huge advantage for us. FWIW, I'm betting that no one from Compellent shows up to challenge it as they seem content to let their FUD-fed resellers do the dirty work for them.  Clever, but in the end it's not a nice thing to do to guys like Enrico (have them carry you FUD for you).  To be clear Enrico, you are OK with me, my gripe is not with you.

3PAR has been using Intel processors from it's inception in it's storage controllers.  There are a lot of good things about this and it's heartwarming to see EMC finally move to Intel on V-Max after all these years.  It takes them a long time to get caught up and of course, the target continues to move in front of them - despite their hollow declarations of parity.  Oh yeah!  And implementations don't matter either!

The proprietary stuff in Compellent's FUD has to do with our ASIC, which is a co-processor for storage functions.  While Intel platforms have some great advantages (that we recognized 10 years ago), there are some shortcomings to using them - like segregating different types of I/O traffic - especially small database I/O versus long sequential streams.  The ASIC in our system does this superbly, which is why our mixed application workload is so freaking good (along with our reservationless true wide striping.)  Why would you want to buy a different array for each major application - that's a waste of resources.

But why would Compellent tell their resellers that 3PAR runs on proprietary hardware, when we run on Intel with a kick-ass co-processor to handle the hard stuff?  It wouldn't be the usual disingenuous marketing tactics they like to accuse EMC of - would it?

The other thing our ASIC does is compute parity.  Why on earth would you want to tie up your main controller processor doing this?  Because you don't have the architecture to do it in a co-processor.

Which brings me to some of Hu Yoshida's recent posts. Hu has obviously been fed some things from the engineers in Odawara, Japan when he recently wrote about about the trade offs you have to make when you select your allocation size. Now I don't have much beef with Hu personally because he is a pretty good guy, but this post really only exposes the limitations of Hitachi's engineering team.  Yes, there are trade offs in every design decision, but there are are an almost infinite number of ways to pay for them.  3PAR's design inception is still way ahead of the rest of the industry because people that designed high end cluster server systems for SUN designed the 3PAR architecture. I don't want to be too snide, but it's pretty clear that Hitachi has  does not have the same sort of perspective on clustered systems design.

Whew - rant over.  I'm going for my first coffee of the day now.

Carpe Bloggem: no guts, no glory for Dell EqualLogic - and Compellent?

I'm waiting to see if either Dell EqualLogic or Compellent show up for the storage blog smackup started by EMC's the Storage Anarchist and taken up by yours truly for 3PAR yesterday. 

The comments I'm imagining have to do with their business performance versus Clariion.  Use an outside source.  If you don't have one handy, just bring your best smack!  Don't be like IBM and run for the covers - or Hitachi by blogging a week later and making vague references to past posts. 

Carpe Bloggem!

I love a good battle royale!

And the Word is: Reservationless

OK, even I thought my last video was weird, but its nice to have it confirmed by Simon Sharwood's weekly storage dish last week.   (As a lover of blogfo-tainment, I look forward to his weekend roundup of the storage blogosphere with my usual hidrosis, knowing that his diagnosis of my public neurosis - without prescribed  pharmaceuticals to expand my gnosis - might cower me into sleeping late on Saturday morning.)

Here it is a new month and a new week and a new opportunity to expand the vocabulary of storage blogging with a new word!  We won't be talking about clouds today, or even allocation sizes except to say that computer engineering is not an exercise in Newtonian mechanics as the folks at Hitachi seem to think. 

The new word for month of August (at least!) is RESERVATIONLESS.  You can try to look it up, but it does not seem to be an official word in any dictionaries that matter.  Whatever, you already know what it means, unlike words like "CLOUD", here shrowded in verbosity by Chuck Hollis or "GREEN", as discussed by William Shatner (the SHAT) here.  (Is it just me or does it make sense that I just put Chuck and the SHAT together in that thought?)  This could be a new storage blogosphere meme - Chuck Hollis as the SHAT of storage!

Reservationless means that you can do something when you want to or need to as opposed to making plans that may or may not work out.  You know how it is, you make a dinner reservation at the hottest new restaurant for 4 and then for significant-otherly reasons you show up 10 minutes late with a party of 6. Or you make a prepaid reservation for a Hotel and a late night arrival and an early morning presentation - only to arrive and find out the place is next to a switching yard.

Reservationless means you can adjust your plans as you need to without penalty.  Reservationless means you don't have to pay a penalty for changing plans.  Reservationless means you can have access to resources without painful rework to change the plans you already put in place. Reservationless means you don't have to undo anything - because you never had to do it (whatever it is) to begin with.

3PAR InServ storage arrays are Reservationless, by design.  You don't have to reserve snapshot capacity that you might not ever need, you don't have to create special pools of disk drives that are only used for thin provisioning and best of all you don't have to pay for professional capacity planning services that you end up changing later anyway. 

Back to today's new storage meme:

 

Claus, someone should smack you up for bad math! And the HBP smackups continue

Claus Mikkelsen at HDS wrote in his most recent blog post:

Having a 700% improvement in workload throughput is equivalent to having 105,000 RPM drives (very crude arithmetic and workload assumptions, but you get the point; don’t beat me up on this!).

What??  "don't beat me up on this"  Claus, what sort of lame disclaimer is that??  If you are going to write something stupid - and you know it when you are writing it, don't beg for mercy like a stoolie.  The math checkers in the storage blogosphere will find out and then decide if they want to give you a heaping load of sh%& for it. 

But I'm going to cut you slack because you are promoting wide striping, an excellent technology that doesn't get enough attention.  So, thanks.  We're really good at wide striping in 3PAR arrays and we appreciate the fact that HDS is trying to help people understand how well the technology can work - even if the explanation you provided is screwed up. While I'm at it, let me give you props for this line too:

I’ll defy anyone to manually provision in a way that will outperform the wide striping we do with HDP

A page from the 3PAR hymnal! - except you don't have to be using thin provisioning on a 3PAR array in order to get wide striping.  Automated provisioning in 3PAR arrays provides wide striping that performs much better than can be achieved with manually tuning. Not only that, but the utilization levels with 3PAR arrays are very high - especially for mixed workloads, where customers often want to store data for different applications on different RAID levels or tiers. 

With HBP (HDS Bloated Provisioning) - if application data is stored on different RAID levels you need different pools for each RAID level, which means you have to divide your disk resources between pools, which means your wide stripes aren't as wide and the performance advantages of wide striping are diminished. The other problem with using multiple pools is that utilization tends to be lower because disk resources are leveraged unevenly across different subsets of applications.

Nigel Poulton, who is a pretty good guy for a dyed-in-the-wool HDS cheerleader, and I have been videoing back and forth about HBP and 3PAR's thin provisioning differences.  I seem to recall him saying that you could setup an HDS array with a single pool.  Really Nigel - would that be s serious recommended best practice? All data stored in one RAID level?

Tony Asaro, in his blog,  quoted Nigel as saying:

For a start it maps perfectly with the internal workings of the USP V and VM.

Which was my point - Hitachi's engineer's did it to make it easier for themselves as opposed to fitting it to customer requirements.  Which leads me to Nigel's metadata fixation where he assumes that all metadata processes obey the same immutable rules of coding. They don't. That's because processes that are core design concepts usually are more efficient than bolt-on afterthoughts.  

Oops, correcting my HDS bloat shrink blog

I'm probably not alone when I say that I figured HDS' zero page reclaim was something more than it actually is.  After I posted my bloat/shrink video a couple days ago, Hu Yoshida at HDS posted a pretty clear entry explaining that it is a fat to thin migration function. My apologies for not getting it right - I should have - and so I try in this video below, once again, to explain what it is.

Zero page reclaim has been one of the stranger announcements this year - and it certainly doesn't top Storage Anarchist's announcement coup of IBM's XIV last year, but if there were awards, for this sort of thing there might be a category for zero page reclaim this year.

HDS' catastrophic storage management

Catastrophe theory attempts to explain how seemingly small, incremental changes to systems result in catastrophic results - such as bridge collapses. Sometimes it involves oscillating or resonating behaviors that get out of control.

When HDS released their version of dynamic provisioning, they created a system that can grow in ways that can cause problems for customers.  The allocation unit for dynamic provisioning is large compared to other thin technologies - and when lots of host systems start writing to unallocated block storage, the amount of available, physical storage needed to supply all those allocations can spike quickly. Can it become a storage catastrophe?  I don't know, but it certainly is the poster child for thin provisioning out-of-disk-space concerns.

In order to fix the over-allocation of storage by dynamic provisioning, they (sort of) released their zero page reclaim feature back in February to get back some of the allocation overkill. It's not exactly two wrongs making a right, but zero page reclaim is simply a bug fix for sloppy, bloated dynamic provisioning. It's interesting that several months after making the functionality available they announced it this week as if its something new.  I guess you can do that if you keep it swept under the rug well enough.

Reclaim technology is going to be a very big deal in the storage industry, but it will work much better when it is integrated with efficient thin technologies, such as those developed by 3PAR, to create a consistent, well-behaved, predictable environment - as opposed to one that requires customers to manage unpredictable allocation storms.