VPLEX undressed

OK,  Monday's post lacked the punch that people have come to expect from me where EMC announcements are concerned.  Thanks to my readers who were disappointed and told me so. This post is for you. 

 

VPLEX (announced Monday with all the hype that EMC could muster) is the result of EMC trying to become something more than a storage company. They put a systems professional in charge of developing storage products and produced a science project that looks very attractive as a technology but relegates storage to a secondary role and questions EMC's commitment to solving storage problems. In fact, VPLEX probably creates more storage problems than it solves. More on that later.

The concept of teleportation for virtual machines resonates with childhood space fantasies. I remember summer afternoons from my childhood going out to a nearby field with my brother and his model rocket club. My brother built some stunningly cool looking model rockets, and the amazing thing was that they all went where he intended them to - up. Just as amazing was the fact that the engine always ejected the nose cone and parachutes to bring his creations back to earth gently.  It was a riot running across that field trying to catch them in our bare hands as they descended. A few years later those rocket designs turned into a set of World Book Encyclopedias that he won at a big science fair in Michigan.  I was prouder of him than any kid brother could be, even though I was just the rocket runner.

However, his rocket club also had a couple of less-talented rocketeers who also launched their contraptions with great fanfare and, quite often, spectacular disappointments. Engines became separated from the rockets holding them, shooting around at random on the ground - and then there was the memorable starship design that took a 90% turn after exiting the launch wire and proceeded to fly parallel to the ground at height of 4 to 5 feet, sending parents, siblings and friends scrambling for cover behind a shrub, pet or each other.

It's good to believe in some things and to be wary of others.

 

So what is VPLEX anyway?

For starters, VPLEX is a virtualization appliance - a bump-in-the-wire product. EMC says it will take the technology at some point in the future and build it into their arrays, but like a lot of things, its much easier to talk about it than to actually do it. The irony of the situation is that it VPLEX fills a storage virtualization role that is similar to IBM's SVC - a product that EMC bloggers eagerly lampoon. EMC is downplaying the similarity to SVC and are spinning VPLEX as a teleportation device for your virtual machines.  Of course, the image of teleportation they want you to think of comes from Star Trek, but sci-fi fans are familiar with the risks of teleportation too - just for fun, recall the problems Jeff Goldblum had with it in The Fly.

The point is, VPLEX is an appliance and therefore it is another thing to manage and pay for. In fact it is at least 4 more things to manage (two here and two there) and can be as much as 16 additional things to manage. Just in case that point was not clear, VPLEX is new stuff to manage in between your servers and your storage.  Like the Wizard of Oz, EMC would like customers to "Pay no attention to those things in front of your storage, - they are virtual and therefore invisible." In fact, it's so invisible that EMC claims you can use it with any vendor's storage, which means there is minimal integration with storage functions. EMC is calling VPLEX Storage Federation, and yet it doesn't integrate with storage on any meaningful level. That's not federation, it's virtualization.

Suddenly, the virtualization of all your storage through an appliance is a trivial matter. But of course it adds considerable complexity to an environment that is already complex enough. To put a finer point on it, EMC customers are familiar with the down and dirty disappointing reality of working with Virtual Provisioning, SRDF and change management. They should expect to pay for additional professional services to figure out how to do these things with VPLEX inserted.  

And then there is the matter of managing mixed workloads in virtual environments, something that is a problem for a lot of customers.  EMC's technique of isolating workloads on certain disk and cache resources doesn't work for highly leveraged VMFS's where there are many VMs running concurrently. When the workloads are all mixed together, there is no way to isolate them. VPLEX appears to be an answer to that problem by allowing customers to move VMs elsewhere - presumably where there are more resources available. In reality, those VMs are going to be moved to another environment with the same storage limitations as where they came from.  Do you really think putting a distributed write cache between servers and storage is going to solve workload balancing problems?  If so, the fix will only be temporary before the same problems are repeated. And that is the problem with VPLEX - it doesn't solve anything by itself, it only allows a problem to be moved elsewhere - presumably someplace where there is more headroom that is not being as heavily utilized.

Storage systems that were designed for utility computing and assuming there would be mixed workloads to deal with, such as 3PARs InServ storage systems, are much more effective at maintaining performance levels for virtual machines and allow customers to operate at much higher system and storage consolidation ratios.

EMC wants you to imagine all the things you might be able to do with VM teleportation. I'd say, imagine how much fun its going to be doing the capacity planning for a VPLEX installation. How much storage do you need in location A and location B to support two way VPLEX functionality for a collection of 80 VMs? As it is with most things, it depends on a number of variables including whether or not VPLEX is being used to facilitate disaster recovery. It would not surprise me if VPLEX ends up effectively capping storage utilization at 50% for customers that employ it. If the maximum utilization is 50%, what will your actual utilization levels be?  Something far less than that. 

Reducing consolidation ratios

In a nutshell, all systems that are fronted by VPLEX will have the same write cache data so that a read from those systems will be serviced from the write cache, if the data has been recently written. However, if a read request is made from a VM for data that is not in VPLEX's write cache, the data will be read from either a local or remote storage array. That's why there are distance limitations to VPLEX today - the time it takes to cross-ship data from a remote location can't be too obnoxious. 

It's also why EMC's Virtual Geek spent time talking about using applications that have a single writer - such as v-Motion. A VM with an application that attempts to write to the same block from two different locations is apparently problematic. My guess is that applications with long sequential reads might not be so great either.

That implies a couple things: You should expect to find out there are limitations as to what applications can be running with VPLEX. Maybe identifying VPLEX friendly applications will be easy, but perhaps this task will be harder than assumed. If so, the best answer may be to engage EMC's pricey professional services organization. The details, the details.

The other implication is that VPLEX will limit the number of VMs that can be running on a single vSphere server. After all, you wouldn't want to have any congestion problems forwarding write cache data through the VPLEX network. The higher your server consolidation ratio is, the more likely it is that you could run into bottlenecks of varying types. Expect to see best practices for VPLEX that scale back your server consolidation ratios.  

Just because you can do something, doesn't mean it's a smart thing to do.

Comments

[Dikrek]

Nice article, Marc.

I'm still trying to figure out if the V-Plex virtualization works just like all other virtualizers - i.e. does it render the back-end arrays into plain disk, in order to provide more intelligence.

Does the V-Plex do the same thing?

If so, I see no mention of cloning, snapshots, deduplication, compression, thin provisioning or indeed any intelligent storage function besides replication.

To me, it seems like another EMC attempt to sell us futures. Just like FAST (http://bit.ly/9dj7XW), the current incarnation is really not that useful, the good stuff comes a year or two later.

HDS USP-V, SVC and our very own NetApp V-Series provide virtualization WITH extra functionality (and, in the case of NetApp Metrocluster, the similar ability to provide simultaneous access up to 100 miles apart - for several years now).

Cache coherency is interesting but in order to work it needs super-low latencies per EMC.

I think it's also important to understand the full ramifications of the "simultaneous" access. 2x the storage is needed, and I believe a LUN is still only seen by one side at a time, though I'm sure EMC will correct me if I'm wrong.

But, ultimately, aside from all of us giving EMC free publicity, what extra functionality do V-Plex customers get beyond migrations?

Thx

D

[marc farley]

I don't know for certain, but I don't think VPLEX provides much virtualization functionality and nothing in the way of storage management functions, such as snapshots, remote copy, thin provisioning. I think it has it's work cut out just managing the distributed write cache.

[Tom]

The following comment was received from somebody using the email address tomjessey@yahoo.com - an email address that has been disabled. (dd Sorry your message to tomjessy@yahoo.com cannot be delivered. This account has been disabled or discontinued [#102]. - mta1027.mail.sk1.yahoo.com ##)

I'm not sure who it came from, but I'm sure it's not worth responding to. Here is their comment:

LOL, its always funny to hear Marc talk about what he clearly doesn't understand...
By the way how is 3par doing anyway? are they still trying to sell Tier 3 storage...

[Liem Nguyen]

Good analysis Marc. For once I agree with you. :-)

[marc farley]

Liem, you should ID yourself as a Compellent employee - I'm not sure everybody knows you by name. Thanks.

[Jim]

Here's a VPLEX architecture and deployment guide: http://www.emc.com/collateral/hardware/technical-documentation/h7113-vplex-architecture-deployment.pdf

[Nick Triantos]

Dimitri,

2x is the minimum. The recommendation is that for critical data you mirror "onto two or more storage volumes that are provided by different arrays". Different arrays is to be interpreted as in "distinct arrays of the same model as the source".

The other interesting thing I read was although EMC is showcasing Long Distance VMotion, they do not recommend the migration of a single VM across sites. Instead, the recommendation is you migrate all of the VMs in the datastore. Quite interesting. pg. 121 of the deployment Guide.

I think as you start peeling back the onion there are going to be lots of restrictions here, at least initially.

Nick w/ NetApp

[EtherealMind]

My favourite part is that "long distance" is 100 km. Which isn't long since less than 5ms is easy. That's available today. But "really long distance" is sometime in the future.

As long as your storage is located in the same town, it's going to work today. Otherwise we will have to wait to see if the Powerpoint release becomes a reality.

[Michael]

Interesting article – Thank You for his.

I try to understand VPLX but I still have a missing piece. Can somebody help?

When I use a VPLEX Metro and use Metro distributed virtual volumes then I have a copy of my data on both sides.

Who performs the synchronous mirror operation? Is it the VPLEX code or is it the backend storage system?

If it is the backend storage system does VPLEX have all kind of storage systems supported? Each of them is talking a different language. It would be a highly complex thing to manage.

Is it VPLEX code internal operation? Is it then performed by each engine or through ISL kind of replication between two engines?

Hope for answers to better understand this system.

Thank You