Enterprise Computing: VPLEX – A Dreary Storage Cluster?

Those of you with relatively good memories will remember last year’s announcement from Hitachi/HDS, which at the time promised more than it delivered.  In fact, the anagram posed by Claus Mikkelsen on his blog and used as part of the press release was “REGRADES OUR CLASSY TREATS” and should have translated to “STORAGE ARRAYS CLUSTERED”  my tongue-in-cheek alternative was “A DREARY STORAGE CLUSTER” (who could have imagined such a serendipidous alternative).  With EMC’s new release of VPLEX, it’s deja-vu all over again….

With the usual EMC fanfare, VPLEX has been heralded as “a new storage platform“.  For a product that appears to contain no storage at all (and in fact writes through to the underlying virtualised arrays before confirming I/O to the host), I can’t quite see how the claim stacks up.

Background

OK, before we dive further in, let’s just summarise what VPLEX appears to be about.  In a nutshell, VPLEX offers “federation”, this year’s buzzword for shared or virtualised storage.  The product is currently offered in two flavours; VPLEX-Local, which basically adds a virtualisation layer into the host->fabric->storage stack and VPLEX-Metro, which creates a clustered storage environment, pretty much like the Hitachi HAM (High Availability Manager), announced 12 months ago.  VPLEX-Local is also remarkably similar to IBM’s SVC (SAN Volume Controller).

The Hype Factor

Of course VPLEX is different, or at least that’s what we’re lead to believe.  From the documentation I’ve read, VPLEX-Local is nothing more than a cluster of SVC-like devices.  This functionality is already there in USP V and SVC.

VPLEX-Metro looks slightly different and starts to get interesting.  Multiple VPLEX clusters can be connected together, enabling I/O for a single LUN to be shared across the VPLEX-Metro complex.  Distances of up to 100 miles can be achieved, the only downside being latency overheads.  I’m not aware of SVC offering this kind of functionality, however that is exactly what Hitachi HAM was designed to do.

Catch-up and Future

With the Local and Metro offerings, VPLEX seems to be simply catching up with the opposition.  In true EMC style, however we are being tempted by two future offerings, VPLEX-Geo and VPLEX-Global.

VPLEX-Geo will offer asynchronous federation over a wider distance (presumably infinite, if you’re happy to cope with the latency).  Asynchronous changes offer the possibility for a world of pain for data integrity.  I suspect the first implementations will be tightly controlled using EMC’s own VMware operating system (ESX).  VPLEX-Geo is slated for 2011.

VPLEX-Global is an anything, anywhere offering.  Let’s reserve judgement on that one until we see it – there’s no dated roadmap other than after 2011.

Unanswered Questions

Here’s what I don’t know:

• Will VPLEX pose the same restrictions on the host multipathing as USP-HAM does? HAM requires HDLM.
• Does the host still have to manage their own cluster configuration? (I expect so).
• Is VPLEX-Metro really updating both data copies or is data just being shunted between the clusters, then replicated back again?

And finally, as quoted in the documentation, VMax will offer VPLEX functionality this year, so you may want to consider holding off on that rash VPLEX purchase if you’re on the cusp of moving to VMax.

Final, finally, what happened to InVista?

• Pin It
• Share
• Tweet