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.
