So, what brought this to light was reading Josh Krischer’s rather (very!) excellent white paper on storage architectures. Although it is entitled: “Storage is Still Not a Commodity: an Updated Comparison of High End Storage Subsystems”, it talks little about the “commodity” part but a lot of the storage architecture part. That’s good. My take on this is that storage is not a commodity, obviously, but it used to be.

Prior to April 1992 (I’ll explain that date in a moment) storage was indeed a commodity. The only metrics us storage vendors had to promote our products was performance, reliability (anyone remember R-Plus?), and price, or as most customers would say: price, Price, and PRICE. Now that’s a commodity!! The April 1992 date was when the first “intelligent” storage function was released by IBM (Concurrent Copy which introduced what now is called Copy on Write). Josh got it a little wrong when he said EMC was the first to introduce feature/function. A couple of other corrections: the days of XRC/PPRC/SRDF rollout were a blur of two vendors trying to roll out function that was a little prior to “prime time”; it’s hard to say who beat whom here since it was all happening at the same time. Also, my position is that EMC’s TimeFinder was really just a reaction to the availability of STK’s Snapshot on the Iceberg and IBM RVA after IBM went on a marketing blitz for it.

BTW, before I go further, I do strongly recommend reading this white paper. Josh has done a lot of research and his conclusions are well worth noting.

Anyway, my passion over the past few decades has largely been storage architectures. It still is. And when I look at what is available today from all the major vendors, I’m amused, surprised, and sometimes shocked at the numbers of different architectures available, obviously some better and more robust that others.

Architectures are at the heart of everything electronic we have in our lives. As an example, OS’s have an architecture. Solaris, HP-UX, AIX, Windows, and z/OS all have different architectures. Windows, as an example, can run on Dell, Lenovo, Acer, Gateway, HPQ, and a myriad of other hunks of hardware. Similarly, that hardware can be powered by Intel or AMD. My point is that “architecture” in this context has little to do with hardware. Another example, if you’ll allow me to be biased, is EMC, which although they’ve changed the hardware (basically, chips and wires), their architecture, in my estimation, has NOT changed in the last couple of decades. As long as they cling to static cache assignments and “bin files”, my argument is that the underlying “architecture” has remained unchanged (evolved and improved, yes) since the old Mosaic 2000 days (such a quaint name now that it’s 2009). Changing the body parts does not change the architecture. VMax may change this, but little is known about VMax so it’s too early to tell (for me, at least).

At this point, I will expect (and will entertain) the cadre of EMC loyalists to take me to the mat on this, but I’m publicly voicing an opinion I’ve had for some time. And to reiterate strongly, I am NOT saying that EMC has not made improvements over the years in function and performance; I am saying the architecture has not materially changed. This limits their ability to roll out advanced feature/function which is one of the points Josh makes in his white paper.

I think it was Larry the Cable Guy who said the 47.2% of all statistics are made up on the spot. Well, I’m gonna say that 81.3% of those of you that read the white paper will like what it has to say, or at least learn from it. Try it out…

The problem (not always bad, mind you) is that whether you’re a startup attempting to secure VC money or trying to get R&D funding within an established company, the gig is the same. How do you get someone to invest money in your scheme? The answer is obviously simple: you hype the hell out of it. Expectations soar, you’re in business, and now you only have to deliver. We often forget that last little fact.

One thing I’ve seen repeatedly is the constant prediction of the demise of the disk, or the hard drive. After all, mechanical things in our lives all seem to eventually disappear, being replaced by the electronic version of the same thing. Record players, 8-track tapes, cassettes, and CD players have all given way to iPhones and MP3 players. Telephones, with those round dials, even buttons, have yielded to voice recognition and speed dial. In fact, the only three components of a datacenter these days (that I can think of) that still largely rely on mechanical components are printers, tape devices, and storage. Even printing is becoming a victim of online reading and browsing (but will not disappear in my career or lifetime) and tape as a standalone technology is being marginalized by virtual tape (i.e. disk). That leaves storage and that little workhorse often overlooked: the hard drive. I’m fascinated that it is still around! And yes, it’s still round.

Off the top of my head I can recall the wild promises of bubble memory, crystal memory, optical memory, optical drives, holographic memory (that one is still some potential), and now SSD’s or flash drives. That last one also is a potential replacement for hard drives, but not for a very long time in my estimation. There are many other promising technologies that have made their way into the technology dumpster over the years.

Why is this? Well, for one reason, the disk drive guys, remarkably, continue to dramatically increase aerial densities and after 53 years of existence, that’s a tough act going. And at the same time they continue to deliver the goods at a 30%-35% decline in price every year. These are averages over a 53-year span but that’s still a tough rabbit to chase both from a technology perspective and an economic one.

Why am I writing about this now? Well, for one thing, as I bounce around the planet talking about technology, folks are more and more asking about the disk drive business. Where is it going; will it ever be replaced? The simple answer is: YES. I believe the disk drive will disappear. I won’t be around to see it and I might even question whether either of my two children will be around to see this total transformation.

But before I get into the “why” of this, let’s look at the past. A totally fascinating piece was assembled by Chris Preimesberger showing up on eWeek. If you ever want to know where we’re going, it’s always nice to see where we’ve come from. I hated history class in school, but I like it now, especially when it includes cool pictures, which this does. Check out this piece, and look at the specs attached to each picture. There is a term they use called “megabyte”. Anyone remember what that was?

But what does the future hold for the hard drive industry? Well, this little snippet published in The MIT Technology Review might give a hint. To give you a perspective, today’s densest drives are recorded at just under a terabit (tb) per square inch (or .155 tb per square cm for the metric fans amongst us). Seagate has now prototyped a technology called “heat (or thermally) assisted magnetic recording” or HAMR or TAMR that can drive densities up to 50 tb per sq/in. Are we looking at a 50 terabyte drive in a few years…probably. Hitachi Global Storage Technologies is working on “Patterned Recording” that has similarly grand claims of increased densities. This is by no means the only research activity on mega-densities but the most visible. Whether these happen or not is hard to say but we have an industry with an enviable track record. And anyone who thinks we won’t suck up that capacity as quickly as we can doesn’t ascribe to my “closet principle” which basically states there is no such thing as an empty closet. We’re a clever species and we’ll fill that capacity in short order. The next question here is how do we manage these capacities (see your local HDS rep for that answer but briefly it relates to storage virtualization and dynamic provisioning and archiving).

One question I do get a lot these days is whether SSD’s will replace the hard drive. My quick answer is “no”. We (HDS) love selling these things and they give incredible performance boosts to those cache unfriendly workloads that keep us up at night, but SSD’s replacing the whole drive industry in short order…I think not. I know EMC likes to position them as drive replacements, but I would argue seriously against this. They have their place, use them there, but they’re still a small segment of the market and show little short-term sign of dominance in the capacity space.

What might ultimately replace the hard drive? Well, boys and girls, if I knew the answer to that question I’d be sunning on my yacht anchored off a beach somewhere rather than writing this blog. But the best hope is what is generically called Storage Class Memories (SCM’s). Scientific American had a great article on this a few months ago, but if you click on the link I think they will ask you for money to read this, but there are many other articles on SCM’s that you can collect through your favorite search engine.

So where does this bring us? Well, in my little world I’d say the hard drive is here to stay and for a long time. Use them, enjoy them, fill them up, back them up, and replicate the contents. Especially in the data center where technologies such as dynamic provisioning, de-duplication, “spaceless” snapshots, and storage virtualization, mean that “virtual” capacity is different than physical capacity. And also remember that the cynic writing this blog might actually be wrong. I’d be interested in your thoughts…

Check out the above video where I explain in a bit more detail the benefits of Dynamic Provisioning outside of the more well-known ‘thin provisioning’ benefits. For those who don’t have perfect streaming, or don’t have the time to watch my 3:30 minute video, here’s what I cover:

- There’s a significant performance boost from the wide striping of large page sizes, since it essentially allows a high number of drives to participate in read activity.
- Because of the wide striping, we also have essentially obviated the need for what I call “provisioning for performance” since HDSP will out-perform anything that is manually provisioned
- Carve out what you need, not what best fits the storage array to maximize capacity. Since LUNs are carved out of a common pool, anything to do with physical awareness of LUNs - for example static LUN sizes - are a thing of the past. You need 3GB? Just provision it. How about 147GB? Provision that as well. A 1.3TB LUN? You get the idea.
- What we’ve done is essentially provided that last abstraction layer of virtualization so that we can all start provisioning storage based on what the application needs. That’s a significant milestone.

Hope you enjoy! Look forward to your thoughts.

EMC plus Data Domain equals what exactly?

Or as I prefer to write it:

EMC plus Dat oin q wh xy?

But the past few weeks have been pretty interesting watching the bidding war between EMC and NetApp over Data Domain. With the final numbers in, it appears EMC are shelling out something north of $2.4B to acquire a technology they’ve already acquired in the form of Avamar. But is it worth $2.4B? I’m not sure, but that might be the war I would want to lose, but history tends to be the ultimate arbiter on such things; everything else is just opinion.

But it points to a stark difference between our two companies in terms of strategy, and that’s something I would like to cover: It’s all about integration.

Before I go further, I’d like to throw out a trivia question. Of all the dozens of storage companies EMC have purchased over the past 12-15 years, which is the only one that was actually integrated into EMC’s storage line? I may be wrong here, and I’m will to be corrected in public, but I can only think of one, and that’s PowerPath. All of the others seem to be more or less left as separate entities. Correct me if I’m wrong on this…

Now this is fine for the likes of VMware and SMARTS, but looking at the Hopkington storage lineup makes me think of a large warehouse with a leaky rooftop with a different bucket under each leak. We have DMX/V-Max, Clariiiioon, Celera, Centera, Iomega, and now Atmos. To manage this array of buckets requires multiple products as well. And then we have the appliance fraternity of Avamar, Kashya, and my favorite, InVista. Now add DataDomain to the mix. I’m sure I’ve forgotten a few, but does anyone see a problem here? How many storage buckets does this world really need? That’s a rhetorical question of course, and I’m not suggesting it always has to be one, but each additional bucket not only complicates the scene, it begs for more plumbing!

Contrast this to HDS and you see an entirely different picture and strategy. We’re not adverse to acquisitions, but we are big fans of consolidation, integration, ease of use, and simplified environments, and we believe an integrated approach is the right approach. Whether mainframe, open systems, block, file, archival, and all tiers of storage, we pretty much have that under one (not-so-leaky) roof. Wanna blend a bunch of different storage types and tiers into a single manageable pool, and be able to non-disruptively move data amongst those types and tiers? We can even include EMC’s “buckets” into the mix!

So while EMC increases its “bucket count”, we simply add function and scalability to an ever-increasing pool managed by the same stack. OK, we still all have a bit to go but that’s clearly our direction.

But every time EMC acquires another company, I keep waiting for the follow-on announcement of what they will actually be doing with that technology, but it never seems to come.

Personally, I’d like to know that I can buy multiple storage types and tiers and have it all fit together…nicely.

But there is a related topic I’ve been wanting to write about for a while now, and it relates to the trade-off in memory management at it relates to HDP and page size. But before I dive into it, let me take you back in time and (re)introduce some buzzwords and concepts from the past, in this case, the late 1970’s and early 1980’s. The two concepts were: “Access Density” and “Short Stroking”. Access density is a measure of IOPS per capacity of a hard drive and Short Stroking was what a lot of folks were doing to compensate for declining Access Density. The two terms are, or course, still used but rarely outside the domain of DBA’s. Put 10 DBA’s in a room and you’ll know what I mean (I used to be a DBA so I’m kinda allowed to poke them).

The problem at the time was that drive capacities on those 14-inch diameter behemoth drives were increasing, but they couldn’t spin the drives faster than 3200 RPM. Spinning a 14-inch drive reminds me of those circus guys spinning dinner plates on the ends of sticks: the tolerances by today’s standards were pretty bad. The problem was increasing capacity with the same RPM. Sound familiar? That is the Access Density problem.

The answer to this dilemma was “Short Stroking”, meaning just putting less data on the drive (to reduce the IOPS demand). It even included physically placing data in the center of the platters so that the heads wouldn’t have to seek (stroke, hence the term) as far. And you all thought Short Stroking was a description of my golf game? It actually is, but that’s a discussion left for another day…

Enter the new decade. Anyone see a repeat here? It’s been quietly happening again, since the drive folks are stuck at the 9-year old 15,000 RPM drives. Unfortunately, that will not change; there is no 20,000 RPM drive in our future. And while we all want utilization rates to increase from the measly 20%-30% industry average, the fact is that unless we start adopting available technology, it will not, for many applications.

I’ve spoken with many customers that were delighted with their 36GB 15K drives, tolerated their 76GB counterparts, but limit the amount of data stored on their 300GB or larger drives. Meaning if something is not done, utilization rates might actually go down further. In other words, they’re Short Stroking, especially in the database world. Performance still rules, and the drive guys won’t be giving us any relief, and flash drives are still too pricey. So what do we do?

Well, HDP, and Thin Provisioning in general, address the utilization rate problem, I think we’ll all agree on that one. But does it address the Access Density problem? Read on…

Our implementation of HDP lays out data in 42MB stripes (32MB stripes on the HDS AMS2xxx midrange array, that was announced today) in a wide striping scheme that offers as much as a 700% improvement (measured) in workloads (or more!!). Access Density, what’s that? 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!). We’re seeing many of our customers adopting HDP only for performance reasons, and not only for thin provisioning reasons. A customer I spoke to last week had a batch job that went from 10-15 minutes to less than 1 minute using HDP wide striping (150,000-225,000 RPM drives?).

And it gets better…

Considering that the major effort in provisioning, especially databases, is to “provision for performance”, now you don’t even have to do that. I’ll defy anyone to manually provision in a way that will outperform the wide striping we do with HDP. So now I’m telling our customers to just throw the data out into a HDP pool and let us manage for performance. For the thin provisioning argument, there are some caveats with some older file systems, but for performance, there are no drawbacks.

So with HDP we have:

1. Thin provisioning – 30%-40% improvement is not uncommon
2. Massive improvements in performance – orders of magnitude
3. Provisioning for performance – What’s that?

Maybe soon we can get all the world’s DBA’s to have a bonfire-party to burn all those old whitepapers they’ve been clutching for 30 years…..I’ll provide the matches…

It’s not that I don’t enjoy the give-and-take with Barry. It’s that Barry is using our announcement last week as an avenue to pose questions that he already knows answers to. That is, feeding the FUD machine that EMC has so ineptly been clinging to for quite a while.

I had to select between 3 choices here - Answer his increasingly inane questions (few of which actually related to our announcement last week), post to his blog equally inane questions about lagging Symmetrix/DMX architecture, or just bring a halt to this silliness. I originally thought I’d select the second option and “pepper” him with a million detailed questions about EMC’s architecture and its limitations but have decided on option three to end this once and for all. I have a “day job” that requires taking care of our customers, working with engineering and development, product management, global services, marketing, and corporate communications. What is also on my plate is blogging. What is not on my plate is having to answer the most detailed of silly questions from a competitor. Barry, as you concluded one of your recent posts to me - “inquiring minds want to know.” What is your day job? And do you really have this much time on your hands?

I will never preclude answering Barry, and look forward to the next exchange. What I will not do is engage in this silly banter in public. I have neither the time, nor the inclination, to do so.

Back to my day job…

In the past 3 days (today included), we’ve fielded questions, had many dozens of conference calls, spoken to the media, financial analysts, and industry analysts. It’s been a fun few days, and the interest is very high, but I would like to emphasize that in fielding these questions and interest, customers top the list as does any analyst representing customers. Somewhere further down on that list are the questions that come from our competition: EMC and IBM. It’s not that there’s no love here, it’s just a basic priority thing (‘scuse me Mr. ReallyBigBank customer, I’ll get back to you tomorrow after I answer EMC’s questions, first).

Barry’s post the other day took exception to our less than prompt answers to his good questions. They are good, and I will answer them here, although I suspect the motivation is pot stirring and information gathering to fuel the expected FUD machines. I’ll ignore his dripping sarcasm and vitriol and get to the basics of his questions. Really, you should all read his post!

But if Barry would allow, and to compensate for the above, I have to have a little fun first. Barry’s post on this started out by saying: “…I hate to be a pest, …” which got me thinking that since this whole HDS announcement started with an anagram, I could anagram “STORAGE ANARCHIST” into “’TIS A STRANGE ROACH”. (Sorry, Barry, but I couldn’t resist!!)

But onto the questions:

• Q: Why didn’t you include the GA date in the announcement? Are you hiding something? A: Yes, we are trying to conceal the GA date and you have no idea how much trouble I’ve gotten into by saying over and over that it’s 4Q this year. Why wasn’t it in the formal announce? I dunno, I don’t write those, but the information is all over the place.
• Q: Are there really NO host requirements? A: I may have misled here. What I’m saying is that there are no additional host requirements since I’ll assume path failover software is pretty standard these days. Initially we’ll support HDLM and perhaps others by GA.
• Q: How does a host know to start sending I/O’s to a different target? A: Path failover that supports HHAM will have owner-paths and non-owner paths after all owner-paths fail then path failover accesses the non-owner paths which are on the secondary controller. I would think you could have guessed that!
• Q: And exactly how does consistency and compliance work when TSM can’t relocate a volume that is being replicated? A: Consistency is maintained by TrueCopy Sync. HAM takes another pre-caution by checking the Quorum disk before a failover to insure that the pair(s) in question haven’t been suspended.
• Q: Oh, and please - you are the undeniable expert in all things IBM mainframe. Are you suggesting that Hyperswap is the solution to tech refresh migrations for CKD devices? A: Nope, I’m not. I’m just suggesting that the functions are similar in the sense that it can swap devices, and as you know, the similarity stops there. Hyperswap is an OS function, to begin with.

Peace…

But I would like to crisply answer a number of the questions that have come up in the last 36 hours and try to recreate the egg from the scrambles.

Firstly, there is no host requirement, and we support all platforms except z/OS. z/OS has Hyperswap which is very similar to AM when you think about it.

So it’s transparent to the apps which is a very good thing. No agents, no restrictions, no impact on performance (other than that imposed by synchronous replication; we’re used to these kinds of things).

You simply define which LUNs you wish to include (much like you would do with any replication product), the array copies the data over and the LUN is either moved (if this is a migration scenario) or kept in a  “mirrored” state, available in case a failover is initiated. So it’s not double the storage or double anything other than what data you wish to move or protect. Again, just like any other replication scenaro. The only additional requirement is that the quorum disk needs to be external to the USP-V.

Keep in mind, this “magic” is done entirely within the embedded software of the USP-V and does not require additional investment other than the quorum disk (keeping in mind that pricing is not finalized).

Availability is Q4, and yes, it has been tested by customers. This announcement is not a slide deck of what sounds cool in the future, nor is it vaporware, this is reality. Sorry guys…

Is AM for everyone? probably not, but the interest I’ve seen from NDA’ing this for a number of months would indicate that interest is a lot higher than some of these blog comments might think (or hope).

There it is, transparent failover from one array to another in the event of loss of access. It’s as simple as that…

Part of the problem is we (HDS) can scale our USP-V to hundreds of TB of internal storage and even to the PB range for our virtualized storage (yes, we do have customers that have scaled to the PB range). Great stuff, but it does elicit the EiaB cry, and for that reason alone, many of our customers have placed arbitrary limits on the amount of storage they’re willing to place under the control of a single array. The answer? “If you could cluster these things we wouldn’t be so concerned!!”

As our announcement today spelled out, we now have storage clustering, meaning there should never be a reason for a customer to lose access to critical data whether that data resides internally to the USP-V, or as external virtualized storage. It’s pretty straightforward, where if access is lost, failover is initiated and the applications never miss a beat. Cache coherency is maintained through local mirroring and an external quorum disk.

It also serves the purpose of being able to non-disruptively move data (internal and virtualized external) between USP-Vs. That means future data migrations will all be non-disruptive.

So, no loss of data access. Ever. And, no outages for any data migrations. Ever. And all of this done with embedded software on existing arrays. Forklifts need not apply.

Well, let’s see if the “blog-as-billboard” idea can work. So we obviously have a big announcement next Wednesday May 27th and although I can’t tell you what it is, I thought I’d try a different approach. Since I’m a big word-gamer, I thought I’d anagram our announcement and see who can come up with an answer. Anybody want to try to figure out what we’re announcing? Then solve this anagram:

REGRADES OUR CLASSY TREAT