Interesting use cases for VPLEX

As I’m sure most are aware, EMC released its VPLEX product for federated storage access (a virtual storage engine). The idea being able to share storage across sites using distributed caching algorithms making active/active data centers a reality. Currently available across synchronous distances (100km) and for local site use cases. This product does all the things Invista does, plus cache coherency, plus across distance, plus a scale out cluster model, plus simplified setup and management and not performing the virtualization at the SAN switch level (thus not requiring stretched fabrics between sites), plus doing it with an appliance model, plus….. well you get the point.

The main reason for this technology is to further enable cloud based IT architectures. The ability to dynamically move storage work loads across data centers (or even within different arrays in the same data center) seamlessly without any application downtime or interaction. Once can also make a case for easy tech refreshes since virtualizing the storage volume decouples it from the physical array, allowing you to play the “storage vmotion” game with which back-end array the data actually resides on. Very similar to how VMware decouples the application/OS workload from the physical server.

Those are all pretty standard use cases for storage virtualization, but how about some others?

An alternative to array based replication. Instead of utilizing the underlying array based replication, why not utilize the VPLEX to do RAID1 mirroring across the sites. While this is just a spin on creating a DR1 (distributed RAID 1 volume) for the purposes of federated storage access, there is nothing that is stopping you from using it for traditional BC/DR purposes. The advantages here would be not having to pay for the cost of replication licenses on the individual arrays themselves (which can be a BIG cost savings as some are licensed per TB of capacity), and also simplifying the management by doing all your management with the VPLEX interface. I suspect this is one of the reasons an SRM SRA is in development, as some customers may very well utilize it in this fashion as you can build a good case for it given the (relatively low) cost of a VPLEX. The DR1 mirroring found in a VPLEX Metro configuration would be synchronous in nature, so it could easily perform the duty of MirrorView/S, SRDF/S, SnapMirror, etc..but with the added advantage that the volume would be available at the secondary site and not in a write disabled state as with current replication technologies. For a company with disparate arrays in their datacenters, this may be a very cost effective way to replicate between them using VPLEX Metro and DR1 devices AND get all the other benefits of VPLEX. I could absolutely see some businesses purchasing VPLEX for this initial duty while they slowly transform their IT into a cloud based model, and then take advantage of the data mobility features down the road when they are ready. There are MANY business which haven’t even implemented standard BC/DR, let alone who are ready for a private cloud. Granted, this type of replication is not on par with what Recoverpoint can do with journaling the writes to give CDP, which leads me to my next point….

In the future, CDP using VPLEX. VPLEX already requires the use of journaling devices for the purpose of logging writes during cluster interconnect failures in the VPLEX Metro configurations. It does this so that when the cluster communication is resumed, it can sync the “secondary” volume with just the writes that have occurred since the failure, instead of doing a full resync. So it wouldn’t seem to be a large leap to think Recoverpoint type replication for the DR1 volumes utilizing the journals would be possible down the road. If this were the case, you could have superior replication scenarios available to you by dropping the traditional block based replication technologies found in current storage arrays and leveraging a “CDP DR1” volume through the VPLEX. Something tells me this functionality is *somewhere* on the road map. 🙂

Cache is king. Its no secret that one of the main selling points in an enterprise storage array is it ability to cache workloads and subsequently serve the I/O from the memory. Its fast. Much faster than disk. This is the main reason we are seeing the move to SSD for high IOPS workloads, as well as EMC’s creation of FAST CACHE and Netapp’s Flash cache (formerly known as PAM). How about instead of buying a VMAX, with tons of cache, you get some Clariion instead and put a VPLEX infront of it to take advantage of the 32GB of cache per director * 2 directors in a single engine = 64GB of cache available to front-end your data. One of the many reasons to purchase an expensive Tier-1 class array such as a VMAX or HDS USP-V is for the massive amounts of cache you can outfit them with. Will it be possible for new storage architectures to utilize multiple mid-tier / lower class arrays (instead of VMAX…CX4s…or gasp some AX4s?!?!), front end them with VPLEX and gain equal performance (distrbuting the I/O among a bunch of VPLEX FE ports in an active/active manner with tons of cache out front) and reliability (through device mirroring with the VPLEX) but at a much lower price point than a tier-1 array? Gee….isn’t one of the big selling points of an enterprise array TONS of FE ports with active/active access, and TONS of cache with maximum uptime? Granted I am over simplifying how a solution like this would be designed with relation to just purchasing a $1M tier-1 array and calling it a day. Time will tell.

An interesting discussion I recently had with a coworker was: “what is the use for SRM if you have a VPLEX?” There is still absolutely a use for SRM. If you have a VPLEX Metro configuration, and one of your sites completely goes down, you still need some kind of process to bring the VMs up on your secondary site. Yes the storage is available, yes you do not have to bring the volumes into r/w state, rescan them into virtual center, but you still need *some* way to power the VMs on. Since you are not stretching a VMware cluster across two sites (because it is bad practice for many reasons), you cannot rely on VMware HA to restart these virtual machines. SRM can still fill the role of powering up the servers in a consistent, automated, and pre-determined fashion to bring the business back on-line. Hence EMC is developing an SRM SRA for VPLEX. It all depends on the failure scenario, as there would definitely be some that would NOT benefit from SRM in the environment as well.

The really cool thing is that even if the VPLEX were purchased for any of the above use cases, you STILL get the capability of doing all the other neat stuff such as data mobility, data migrations, etc and being setup for a private cloud down the road. And I think the way EMC has priced the solution, it will be attractive to some customers for these use cases. The neat thing about technology is there are always many uses for the same gadget. Many solutions to a problem, and many problems to solve. Its all about marrying business requirements with technology. I’m sure there are dozens of other non-standard use cases that this could be used for, but these are just a few that popped into my mind.

Comments always welcome.

Categories: EMC, Virtualization, VPLEX

2 replies

  1. Good and concise article.

  2. I’m not sure that stretching a vmware cluster across sites is a bad practice anymore, specifically with vSphere 5.0 and its HA changes, plus the fact that it is a certified configuration by vmware.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: