Hitachi Announces....Something?

Hitachi Data Systems recently announced HAM. A pork product? No. HAM is their cluster technology for their monolithic storage.

What the heck does this mean or do? Honestly? Who knows! This product announcement was barely more than a few paragraphs on a news page. From reading into the HDS blogs and others, this is what I have gathered:

HDS USP-V arrays can be clustered to be made aware of each other. Think NetApp (And any Hitachi engineers reading this just cringed) head clustering. Except each head needs its own storage (You only need double storage for storage that you want to cluster).

The benefits:
1. You can put your application’s storage on both arrays so that if an array completely explodes you have another local array with the data
2. If you continue to buy HDS USP-Vs you can migrate nondisruptively (zero downtime migrations are huge) provided that you have path failover software that supports HDS HAM (In other words, Hitachi’s path failover software)

Super, are the benefits worth it?

Application Continuity
Ok, so here’s the deal. In the real world, the IT Enterprise demands that data be available ALL THE TIME. 5 Nines (99.999% uptime) is not acceptable. So, anything that makes that possible is a benefit. However, in case the good folks at Hitachi failed to notice, but the Economy just took a world class shit. So purchasing an additional storage head and additional storage is an exorbitant cost considering just how hard it is to take down a storage array with anything that wouldn’t also take down the other storage array. Benefit? Sure. At all smart from a cost level? No. Increase in management complexity? Huge.

Nondisruptive Migrations
Ok, at first I was excited about this. This is an outstanding idea. Nondisruptive storage migrations would be incredible.

But look at the following blog:
Claus Mikkelsen’s Blog » Blog Archive » A Response to Barry Burke, The Storage Anarchist

In this blog the following statements are made:
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!

This is where I became concerned. EMC’s PowerPath Migrator addon will migrate data between EMC targets nondisruptively. Basically, the gist I get from HDS is the cluster will migrate the data if your path software can be aware that disk targets are on multiple arrays…. So why couldn’t you just set up your path software to do all of this? Further, how many people buy Hitachi’s path software? Most of the implementations I’ve seen utilize OS native tools or Veritas, because HDS's HDLM is crap.

Don’t get me wrong, I like a successful Hitachi to keep companies like EMC honest. But why didn’t they just bake all of this into their Path Software and made that a more dynamic and essential product? The product won't even be available till Q4, when EMC will release FAST v1, which will allow data to be moved on the same array between different tiers of storage with zero host knowledge or disruption.