the storage anarchist

1.014: the laurel and hardy of thin provisioning

UPDATED (July 3, 2008): Deletions struck-out, additions noted in green.

One is decidedly skinny.

The other is unabashedly portly.

And I'm not talking about Stan and Ollie, folks.

No, such is the differentiation between the thin provisioning implementations of IBM's SVC and Hitachi's USP-V/USP-VM.

Sir Barry White eloquently describes the petite implementation of SVC's fine-grained Space-Efficient Virtual Disk (SEV for short) in a recent blog post (any resemblance of BarryW to fellow Brit Stan Laurel is purely coincidental, I'm sure).

Not to be outdone (and in an obvious attempt to justify the Hardy-ness of Hitachi's Dynamic Provisioning), HHSNBN explains why DP's heavyweight approach makes for better thinness (at least on the USP-V). Given the title of his post (When is Thin Provisioning Too Thin?), I figure ole' HHSNBN doesn't think the SVC's implementation is all that, shall we say, robust.

IMHO, both have managed to gloss over details that are very pertinent to understanding if, when and where one implementation is better than the other. Not surprising, especially since BarryW & I both know full well HHSNBN will never respond directly to any inquiries or challenges. No, HHSNB prefers only one-sided discourse (his side, of course), so I guess that leaves it up to me to try to tease out the truth.

So let's look a little deeper at these near-opposite implementations and see what we can figure out for ourselves, shall we?

Warning: readers of this blog have asked that I spend more time talking tech,
and less time bashing the competition.

This post is about as close as I can get to fulfilling those requests...

 

1.005.2 hitachi hits new lows (reposted)

Notice: I withdrew this post yesterday afternoon after receiving a challenge from a commenter who insisted that I was mixing up Hitachi's disk drive results with their storage array business. After carefully reviewing Hitachi's published results, I am convinced that the revenue growth numbers I used for Hitachi's storage business are correct (and exclude HGST). Therefore, I have reinstating my post intact, with the addition of a new "Hitachi Math" section (in blue) below.

Hitachi announced their earnings this past Tuesday (May 13th), and their Storage Solutions results (among others) were particularly gloomy. Not as bad as the free-fall in plasma TV sales in the US that they experienced, maybe, but dismal nonetheless.

In what is their fiscal Q4, once high-flying Hitachi only managed to eek out storage revenues that were down 1% from a year ago and down 3% from last quarter, while both EMC and IBM (if you include Tape) actually grew revenues double digits Y/Y in the same period. It marks a notably downward trend in Hitachi's Storage Solutions revenue growth over the past couple of years, as can be seen in this chart:

And Hitachi's projections for the future was for even more revenue contraction for this quarter and next - shrinking perhaps another 5% before they expect a turn-around, they said.

more hitachi math

As I noted above, the above results were challenged yesterday with an assertion that the "decline" was due to HGST. Fact is, these numbers are taken directly from Hitachi's earnings supplement, where they report "Storage Solutions" (array hardware, software and services) separately from "Hard Disk Drives" (see the top of page 2).

You'll note that Hitachi reports by halves (wouldn't want to make it easy to figure quarterly results now, would you?) - but if you go back to last quarters' results, you can do the math to verify that their Storage Solutions revenues were up 2% Y/Y in FQ3'07 and down 1% Y/Y and 3% Q/Q in FQ4'07 - just like I said.

In researching the accuracy of the numbers used in the chart, I was also allowed to see a couple of financial analyst's reports that included additional revenue insights provided them by HDS executives. While I cannot reprint specifically what these analysts published, I must say that there is something that smells an awful lot like Hitachi Math in their reports. Perhaps they just misunderstood what the HDS execs told them, but the numbers the published in their reports simply don't add up.

More importantly, since HDS only sees revenues excluding Japan, their perspective undoubtedly skews any possible analysis - especially since it's not clear whether HP and/or Sun storage revenues are reported through HDS or if they go directly to Hitachi Ltd. (I'm pretty sure they go directly to Japan).

And if revenues really weren't shrinking, then why the heck would HDS execs be trying to spin the story with Wall Street in the first place?

Bottom line: Hitachi Headquarters reported (and documented) that FQ4'07 Storage Solutions (ex-hard disk) was down 3% Q/Q and down 1% Y/Y - just like I said.

And on top of declining revenues, word on the street is that morale in Hitachi's US field operations is at an all-time low. Nobody seems to know if morale is suffering from the recent out-sourcing of customer service, the collapsing of the former solution/consulting business with the former Hitachi Data Systems subsidiary, or the new Japanese management that are running the new US holding company now. Or maybe it's something else?

Given that the flagship USP-V is nearly a year old, it seems very odd that revenues would be shrinking at a time when the new system should be really starting to gain traction.

It all makes me wonder...
 

0.065: for whom the bell tolls

IBM today announced the addition of NTAP's top-of-the-line FAS6000 storage platforms to the Big Blue Product Portfolio, rebranded as the N7000 series, and positioned specifically in enterprise storage market segment.

With that move, IBM now resells a directly competing product for 100% of their Systems Storage disk portfolio. From the lowly DS3000, to the DS4000, through the DS6000 and the DS8000 families, there is now also an N series product designed (by NTAP) to compete head-to-head with IBM's product lineup.

And even the vaunted SVC now has a direct challenger from the N series, in the N7000 "gateway", IBM's rebranded version of NetApp's V-Series (V-is-for-virtualization, don't you know).

That's gotta get confusing if you're an IBM sales rep or channel partner.

Not to mention if you're a potential customer.

Cue Flight of the Valkyries ...

0.050: thin provisioning - don't leap before you look

I've been hanging out over at the Wikibon this week, both to monitor the feedback on Hitachi's latest announcements as well as just getting to know some of the folks there. Lots of familiar faces, and far too many "lurkers" who haven't yet stepped up to be heard. I have high hopes that this Web 2.0 approach to collaborative storage analysis is the wave of the future. Heck, I can't imagine why anyone would pay the Gartners, IDCs or Evaluator Groups of the world anything once this Wikibon community gets its legs under it.

There are lots of interesting topics flying around over there in Wikibon-land in addition to coverage of vendor announcements and strategies. If you've followed my call to action to join Dr. Kartik's efforts to redefine storage performance benchmarks, you'll notice that Dave Vellante has thrown the energy of Wikibon behind that initiative. And capitalizing on the benefits and returns of green storage is another interesting topic that's getting a lot of attention over at the Wikibon.

0.036: data integrity and virtualized storage

Is your data really safe?

In what many think is a modern-day impression of Chicken Little, Robin Harris has been asking this question over on StorageMojo for quite a while. In his most recent blog post, he refuels his concerns using "evidence" presented in a Data Integrity research paper done by the folks at CERN.

I highly recommend you at least skim that document, as there are some interesting observations in it that could have far reaching ramifications in your own storage environment.

According to this paper, more than 3 of the MP3's or TiVo videos I have in my Terabyte Home are probably corrupted -and I might never know it!

Now Robin takes the 50,000 foot view of this, and comes to the conclusion that the world just may collapse soon if this data integrity issue isn't resolved. He even suggests that HEY! Shouldn't we be doing something NOW to avoid all this?

</sarcasm> (I leave it to the reader to figure where the opening tag belongs )

Good news, Robin: some of us have already been solving this problem. Been doing so for years, in fact...  
 

0.035: hitachi drops another shoe (it sounded like a slipper!)

I guess I should be ashamed. Embarrassed at least.

Yesterday, someone asked me why I hadn't yet commented here about Hitachi's baby USP-VM announcement made earlier this week, and I responded "what announcement?"

Yep. I missed it. Completely.

Not that I wasn't aware it was coming...Mr. T doesn't make the rounds on Wall Street on the arms of HDS PR folks for nothing, nor do you wake poor old Claus from his year-long blogging hiatus unless something really important is about to happen.

As I had prior blognosticated, there were (and still are) gaping holes in the initial USPV announcement - clearly the team back in Japan had much more in mind than had been announced back in May. And at least a few rumors indicated that many of these would make it through the QA gauntlet before the end of Q3'07.

Guess this stuff really is hard for everyone.

So I guess because I'd expected so much more, the actual announcement of the USPV "mini-me" slipped right under my radar. I probably shouldn't have taken Nigel's advice and stopped stalking HHSNBN (although it has been therapeutic not to read about yet another world calamity that UVM can solve for a couple of weeks, mind you).

But now that mini-me has been brought to my attention, you just know I have to comment. Interestingly though, this time I'm not alone in correcting the typical misleading marketing that the Hitachi Data Systems Santa Clara marketing miscreants have become known for.

It seems I have some new friends in my quest to keep things honest.
 

0.031: inside tiered storage - part 2 (options)

Part 2 of a planned 4-part series exploring the concepts and implementation of tiered storage. If you missed it, you should probably read part 1 (definitions) first.

Several weeks ago I was invited to sit-in on a "Peer Incite" conference call with the folks behind Wikibon.org. The topic had been advertised as a peer review of EMC's 7/07 announcements, but the topic leader (Peter Burris - or was it David Vellante?) chose instead to focus the discussion around the implications of EMC's announcement that the Symmetrix DMX-4 would be the first high-end storage array to offer native support for SATA-II disk drives, and specifically the 750GB devices. (You can read the collective results of that conference call here.)

One interesting aspect of this discussion was the clarity offered around the differing approaches for implementing tiered storage. I personally thought this one of the more valuable parts of the discussion, but it seemingly was not included in the posted summary. In fact, it was that omission that initiated the idea for this series in the first place (admittedly, I had initially thought I'd be able to cover the topic in a single post, but I couldn't manage to pull that off).

So in this chapter I'll explore the four different options for implementing tiered storage, as was discussed in that original call.

Of course, I'll add a little of my own color along the way.

And maybe even a surprise ending...

0.027: inside tiered storage - part 1 (definitions)

There has been a lot of talk of late related to tiered storage, mostly surrounding the applicability of using SATA devices in enterprise-class storage arrays. After posting a few comments and follow-ups on fellow blogger sites, I thought perhaps I might invest in making a more in-depth look at the whole topic from an enterprise IT perspective.

The way I see it, this whole notion of tiered storage is pretty broad, so I've outlined my approach to the topic into a couple of related posts that I plan to deliver over the coming days/weeks. Roughly, I think I'll tackle the discussion like this:

part 1: definitions

In the first installment (this one), we'll explore the definition of "tiered storage" - I say "we" because I'd like to collect your feedback on the subject.
 

part 2: options

Next I'll explore the various approaches to implementing tiered storage, using different companies and their products as examples.
 

part 3: challenges

Then I'll discuss some of the challenges of implementing tiered storage, both related to each individual option and across the entire spectrum (I'll give a little preview: there isn't yet a good solution that solves everything for everyone).
 

part 4: predictions

Finally, I'll take a look at what I think will likely be coming down the pike to help improve the overall situation.

Now, I probably won't get through all this back-to-back, so expect me to intermix this series with other topics over the coming days or weeks.

One important caveat - this series is about Tiered Storage, and NOT Information Lifecycle Management (ILM). As SNIA has defined, ILM is about the entire operational ecostructure (people, process, practice, tools & technology) employed to effectively align the business value of information with the IT infrastructure throughout its' lifecycle. This series of posts will explore perhaps the most important of the infrastructure tools - tiered storage - that can be employed in support of ILM, and the various means this tool can be deployed.

So let's get started...

0.010: operating at exa-scale

You've seen the IDC/EMC report on the staggering rate of information growth the world faces. At something like 56% CAGR, we collectively today manage over 161 exabytes of data storage. If you have read the press release or the complete study, you'll have noted that the bulk of this growth is in data that resides outside of the typical IT data center - digital video, photography and audio. And unless you work within the industries that are building value on or around these new storage-hungry data types, you might harbor the impression that this growth is really somebody else's problem.

And you'd be wrong.

Many Individual IT organizations around the globe are dealing with the same levels of compounded growth in their storage requirements as is the entire global information economy cited in this report. And many of these IT departments are already dealing with 10's or even 100's of petabytes of on-line storage, not to mention perhaps a couple of exabytes of off-line or near-line capacity.

I've seen a few of these environments up close, and it literally boggles the mind. Off the top of my head, some of the larger ones include:

• the cellular communications company in Japan that services real-time "debit card" type transactions from millions of customers' cell phones and the cell phone company in China that has more customers than the United States has residents;
• multiple different global financial institutions that handle the billions of concurrent stock, currency and credit transactions that make up the global economy;
• the airline reservation and scheduling systems that keep pilots, planes and passengers moving in relatively organized chaos;
• the processed foods and consumer goods companies that constantly analyze point-of-sale and shelf-life information for its products in near-real-time so that it can maintain just-in-time manufacturing and delivery in response to geographical and seasonal  demand shifts;
• the DoD and national security organizations that um...well...ahem... do whatever it is they do with all that information that they've intercepted collected over the years (and it's a lot, or so I've been told d:^).

Bottom line - there are literally thousands of IT organizations operating at a scale that most of us can't even imagine.

And whether by vendor intent or sheer customer need, EMC supports the storage requirements of (dare I say it) the majority of these largest IT organizations in the world. Dealing with the evolving (and exploding) information demands of these customers has largely defined EMC's product and services portfolio, from the early days of Symmetrix through the latest server virtualization, data-dedup and information security additions. We've learned a lot by supporting these bleeding edge consumers of storage, including one very sobering reality.

And you know what that is?

Operating at exa-scale is extra-hard.

0.004: get ready for tagma-too!

Word's out - there's soon to be a new USP from our pals at Hitachi/HP/Sun. And I'm sure you didn't hear about it first from me.

It's about time.

Hitachi had been on a pretty set schedule of bringing new high-end platforms to market just about exactly every 24 months. And in fact, it seems many customers were specifically told in early 2006 to expect the next-gen "Tagma" in the September 2006 (ish) time frame, almost exactly 2 years after the original USP12000/9990v was announced.

That would make next week's (rumored expected) announcement just about 8 months late. Makes one wonder what when wrong - what happened in 2006 to cause such a delay? A delay so long that Hitachi's Wall Street Minions were out in force late last summer, admitting to anyone who'd listen that the company would likely suffer significant loss of market share through calendar Q4'06 and Q1'07.

Although the numbers aren't all in yet for Q1'07, the predicted loss of storage market share the last couple of quarters looks very likely to have been correct. In fact, estimates I've seen indicate that IBM's DS8000 surpassed Hitachi's USP+NSC sales in the high-end for the first time back in Q4'06.

After such a long wait, I'm pretty sure what the folks over at Hitachi are thinking right about now...

...Welcome to the machine!

0.002: storage virtualization: naming gone awry

Naming a product or capability is probably one of the hardest things to do well, especially in high tech where you try to strike a balance between descriptive and inspirational monikers. As one of my mentors oft noted, "All the good names are already taken; the trick is to find the available one that stinks the least" (rest in peace, JH).

I think we, as an industry, failed miserably with the term "storage virtualization."

Here's why:

Shall we play a game?

No, not Global Thermonuclear War. Or even Tic-Tac-Toe. (Already been done.)

Let's play: One of these things is not like the others. One of these things just doesn't belong.

1. Virtual Memory
2. Server Virtualization
3. Storage Virtualization
4. Virtual Reality
5. None of the Above

Give up? You might be surprised...