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?

© Chris for Gestalt IT, 2010. | EMC VPLEX – A Dreary Storage Cluster?
Read more posts categorized as Storage

EMC has big plans for their VPLEX technology

The company previously outlined the vision for globally-distributed federated storage, but today’s announcement adds both meat and bone to that concept. EMC promises that VPLEX will transparently move data (and thus workloads) between storage systems locally or across a metro area and the company will eventually enable this technology across global distances.

All-caps VPLEX (never mind the spelling in the slide above) will be released in Local and Metro forms today in the form of an appliance starting at US$77k or a software subscription starting at US$26k per year. The slim client architecture does not include storage.

The VPLEX technology not only functions in heterogeneous storage environments, EMC claims it will take advantage of native features like thin or virtual provisioning, replication, and mirroring that EMC and other vendors provide. Timing for this functionality is unclear, as are specifics about exactly which features will be leveraged and in what configuration.

Each VPLEX engine includes two boards with dual quad-core Intel CPUs. EMC interlinks these using Fibre Channel, scaling to four engines in each of two locations. Confused? That’s a total of 32 CPUs, 16 boards, 8 engines, 2 locations, and one VPLEX. The company says this is nowhere near the maximum configuration, but it is all that has been qualified at this point.

Although many (including competitors) have compared VPLEX to Atmos, EMC’s new baby only virtualizes Fibre Channel block storage. The sweet spot seems to be implementing distributed server clusters with VMware, but we can imagine many other applications of the technology. EMC affirmed that Invista was complementary and compatible, though the future of that product is unclear. VPLEX offers greater functionality and flexibility, effectively eliminating whatever market there was for Invista.

Although EMC has shown an aptitude for product strategy sadly missing from much of the rest of the storage world, the company’s competitors are itching for a fight. HDS claims that their high-availability manager (HAM) technology “been there, done that” and one imagines that NetApp, IBM, HP and the rest will have something to say as well. Will EMC be able to differentiate their VPLEX strategy in the face of these competing technologies? The answer seems to be in sales and marketing execution, not just technological development.

© Stephen Foskett for Gestalt IT, 2010. | EMC Shouts VPLEX In A Crowded EMCWorld
Read more posts categorized as Exclusive, Featured, Storage, Top Story

Earlier this month, Texas Memory Systems announced they had acquired the intellectual assets of Incipient, a company that produced SAN virtualisation hardware and software.  With Incipient gone, EMC hardly bothering to mention Invista, what is the future of SAN LUN virtualisation? 

I talked about Incipient last year, here and here when discussing the costs of performing migrations.  As I said at the time, I couldn’t see how much of a saving deploying their iNSP would bring to the burdensome migration work we all have to manage on an ongoing basis.  So there’s got to be a more compelling benefit out there for using virtualisation products.  If there is, then what is it?

Excluding the defunct Invista, that leaves Hitachi with Universal Volume Manager (UVM) and IBM with SAN Volume Controller (SVC) still in the market place.    From experience, I know UVM is a great product and surprise, I’ve commented on that recently too especially herewhere I reference the fact that Hitachi are offering UVM for free.  Clearly, the drawback to UVM is that it is integrated into the array itself.  When the NSC55 first came out, I heard rumours that it may be a diskless virtualisation “head” and although it can be deployed in that way, it isn’t sold as that.  If Hitachi decided offer the USP VM or its successor as a diskless virtualisation controller, it would put them squarely in competition with SVC from IBM.

Earlier this year I was fortunate to have an invitation to meet Barry Whyte, “Master Inventor” and Performance Architect on the SVC product.  You can find Barry’s blog hereif you’re already not subscribed to it.  I highly recommend it especially for understanding the in’s and out’s of the SVC itself.  During my trip I got to see some of the hardware used to do interoperability testing of SVC – with storage it virtualises as well as servers it connects to.  It’s by no means a trivial task; there are 80 people in Hursley alone, working on development and testing of the product as well as a further 64 scattered around the globe.  Obviously virtualising storage is a complex business and requires huge amounts of testing.  I’d go as far as suggesting that the testing takes way more cycles than writing the code itself.

What’s all this got to do with the future of virtualisation?  Well, I think it highlights what a complex process it is.  Even though standards for interoperability exist, IBM (and presumably Hitachi, EMC and at one time Incipient) have to deal with complex interoperability issues and interleave that with additional features and functionality whilst guaranteeing data integrity.  The slide taken from an SVC presentation deck gives you an idea of what’s involved.  Thanks to Barry for permission to reproduce this.

Both Hitachi and IBM have been successful with a virtualisation product that doesn’t sit within the SAN fabric itself.  This seems to me to be counter-intuitive as I’ve always thought the fabric was the right place for virtualisation.  After all, every I/O leaving a host hits the fabric first and this naturally becomes the best place to route the I/O to its final destination, whether or not that is a “real” LUN or one created from a virtualisation product. 

Perhaps SAN fabric virtualisation was simply too complex and costly to deploy.  After all, recent history has told us that paying for a fabric-based virtualisation product is a non-starter otherwise we’d see more Invista and iNSP.  Perhaps fabric-based virtualisation didn’t provide the feature set that mature IT organisations required from the technology.  Either way, virtualisation in the fabric needs a rethink.  Maybe FCoE provides/provided that opportunity?

© Chris for Gestalt IT, 2009. | Enterprise Computing: What Next For Virtualisation?
Read more posts categorized as Server Virtualization, Storage

This is the final post in a series on Enterprise Data Migration Strategies.  Previous posts:

Enterprise Computing: Data Migration Strategies – Part I

Enterprise Computing: Data Migration Strategies – Part II

Enterprise Computing: Data Migration Strategies Part III

Enterprise Computing: Data Migration Strategies – Part IV

Previously we’ve discussed how to plan, structure and organise migrations.  In this post, I’ll touch on some of the tools which may be used to perform migration work.

One Size Does Not Fit All

First of all, its worth pointing out that no single solution fits all needs; migration methods are varied and the specific configuration in place demands the best solution at the time.  Therefore it pays to have an arsenal of tools at your disposal and know how you’d use each one.

Array-Based Migration

Storage arrays already have many tools for performing migrations.  These exist today for business purposes; remote replication to another array; local replication within an array using clones and snapshots.  The benefit of using in-array technology is the migration work is taken away from the host and potentially can be executed within minimal customer interaction.  On the negative side, most replication technologies which move data between arrays are product specific – i.e. SRDF on EMC DMX arrays isn’t compatible with HDS’ TrueCopy.  This shouldn’t be a surprise because they are proprietary technologies which gain their advantage by being specifically coded and optimised to the storage platform itself.  There are however tools like EMC’s Open Replicator which can move data between vendor/family technology.  Open Replicator does have restrictions though – depending on the type/direction of replication, incremental copying isn’t available and requires a full copy sync to complete, potentially removing the benefit of using the tool altogether.

Virtualised Migration

Sitting slightly higher up the “storage stack”, it is possible to do migrations using a virtualisation technology sitting above (or integrated with) the storage array.  For example, IBM’s SVC can be used to manage data migrations and sits above all storage arrays; HDS’ USP (equivalent to HP XP models) has a facility called Universal Volume Manager (UVM) which can perform the same work and is built into the array.  Incipient have a solution called INSP (Incipient Network Storage Platform).  If not already deployed, these tools will need an outage to be installed in the data path.  Both impact the World Wide Name (WWN) the host sees, so host changes may also be necessary, depending on operating system.  The benefit of these technologies, once installed, is that they allow data to be moved dynamically “under the covers” without involvement of the customer or work on the host server.  As with all technologies, there are restrictions under certain circumstances and you should check with the product vendor for those.  It may well be that you want to move the virtualisation tool at the end of the migration so another outage may also be required.

Fabric Migration

Moving slighly higher, we have the ability to perform data migrations in the storage fabric (SAN) itself.  Example products include Brocade’s Data Migration Manager (DMM) and EMC’s InVista.  Storage migration in-fabric requires the deployment of hardware in a SAN switch that intercepts I/O and redirects a second copy to another device.  Potentially these devices can be installed in the data path without distruption but will require an outage to cut over to the new target volumes.

Host Migration

Finally at the top of the stack we have host-based migrations.  Even at this level there are still a number of choices.  If a Logical Volume Manager is installed (e.g. Veritas Foundation Suite/Volume Manager), then migrations can be performed using this software without host disruption.  This is often a good choice of tool if the target devices are in a different array, if outages can’t be taken or if the LUNs are being re-organised or restructured.  Unfortunately this also means having either host-access given to the storage teams (plus O/S knowledge to complete the work) or requiring the platform teams to perform the migration work.  Both of these options may be a problem in certain organisational structures.  One word of warning using LVMs – if LUNs are being replaced by using “evacuate” functionality (where a LUN at a time is swapped with another) then a potential data integrity problem exists, especially if the LUNs are also replicated.  The risk occurs because data spans two arrays and if remotely replicated, then writes at the DR site might not be in integrity timestamp order.  Failure in either array can result in an outage.

For mainframe customers, there’s the fantastic TDMF (also available in an Open Systems version)

If LVMs are not available, then good old-fashioned data copying is the order of the day.  There are many tools to do this, too numerous to mention here, but be aware, that this method is likely to mean protracted downtime as storage shouldn’t be active and be accessed whilst it is being copied.  It is also possible to migrate data within an application, again, there are too many options to mention here.

Hopefully this article provides a flavour of the migration tools out there.  Please add comments or ping me if you’ve any specific tools you would like me to mention and I’ll add them on as a separate page.

© Chris for Gestalt IT, 2009. | Enterprise Computing: Data Migration Strategies – Part V
Read more posts categorized as All, Storage