As long as I can remember, the EiaB syndrome has been alive and well. Technology moves from 100MB drives to 200MB drives? Too many eggs in one basket, people would scream!! This cry is an endless industry-wide issue. The problem is part paranoia, and partly adapting to the constant “bar raising” that technology brings. The other problem, as Howard Marks mentioned to me today, is many folks have ended up with the occasional crappy basket from time to time. So the concern is real…
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.
Comments (4 )
the storage anarchist on 27 May 2009 at 2:37 pm
Umm…if I get this right, you propose to avoid the “EiaB” syndrome by buying twice as many eggs and dividing them into two baskets, consuming twice as much power, twice as much space and generating twice as much heat.
It is thus perhaps fitting that the acronym for your new product is HAM.
Green Eggs, anyone?
Christophe Bertrand » Blog Archive » Classy Treat Part II: An unfair business advantage on 27 May 2009 at 4:01 pm
[...] was reading Claus’s recent blog entry and I wanted to provide a complementary perspective and highlight my take on how our [...]
Dick on 27 May 2009 at 6:35 pm
Anarchist,
In the past, you would have suggested using Invista to achieve the same benefit… Or did you stop peddling that product since it does not work? The HAM analogy is not accurate because one may use a less expensive media to avoid “EiaB”. (Also, please note, replication and thin provisioning actually work on Hitachi.) Additionally, please focus on the huge impact this technology will have operationally to avoid outages while migrating from one subsystem to another.
the storage anarchist on 28 May 2009 at 1:05 pm
I’ll happily focus where you’d like: but first understand that we are all still waiting for you to explain the host requirements.
Does HAM require host-resident code? Does the host have to have HBAs configured to point at both old- and new- storage? Can all of this host “preparation” be implemented non-disruptively? Are the two data paths truly active-active - writes down both, or active-passive? If the second member of the USP-V cluster is remote (say, 80KM away), does the host still have to have a connection to both arrays? If the “local” array fails, all of the hosts’ I/Os will be serviced by the remote - right? How much standby communications bandwidth would a customer have to have to utilize this? And since the two arrays are essentially mirrors for each other, does that mean the customer requires 2x replication and other SW licenses to use in a HA scenario? What about if just doing a migration. And are the WWN and SCSI ID of a given LUN the same on both sides of the HAM cluster?
And since remote replication has to be suspended whenever you actually relocate a LUN (and you can actually only relocate 8 LUNs at a time from a maximum queue of 64 LUNs) - and THAT’s either within the USP-V or to/from externally virtualized storage, how is the remote site kept in sync with the primary during LUN migrations? And doesn’t the storage admin actually have to perform TWO separate migrations - one on the primary and one on the remote - should they want to relocate a LUN? During that relocation period of time, aren’t customers out of compliance - and in fact still at risk of data loss should the primary fail?
Oh - and when does HAM ship? How much does it cost? Is it even in Beta (I know HDS customers who were told that the planned May Beta had been rescheduled for August - is that true)?
Enguiring minds wanna know.