#vplex

                                Over the past week I had the pleasure of attending VPLEX training in Milford MA at one of EMC's training facilities. Obviously one of the benefits of attending these classes as a partner is the depth of information you receive. Certainly much more than the customer training. In most cases there is a nice mix of EMC internals and partners that naturally draws spirited debate. Given the amount of information thrown at you in such a short time, I thought it would be appropriate for me to focus on Planning and Design considerations. After all these areas contribute tremendously to the overall success of the project. Especially for VPLEX. By the way, my intent is to carry this out over several posts. The focus will be expressed in an advisory manner, everything doesn't have to be so complex does it? Vendor documentation is built for technical depth. If something needs further explanation hit me up on the twitter and I can point you in the right direction.

So lets get started…

What and Why VPLEX?

In short VPLEX is the middle man between your storage array and your hosts. Today you would typically zone your hosts to a storage array for storage access (LUNs). With VPLEX in the mix, your storage is derived or pooled between one or many backend arrays (of various vendors or just EMC). Think of it as the hypervizor of storage virtualization. Zoning, at this point is directed to the VPLEX engines (directors more specifically) themselves. By doing this, you are virtualizing/abstracting the underlying storage. Why would you do this? The same reason you virtualize your servers. To free your data of physical constraints, opening up a world where the impossible comes possible. Features like active/active storage between geographically dispersed sites, Stretched VMware clusters that lend itself to Live VM migrations between sites, and eventually worldly data mobility. Now other use cases could include disaster avoidance, zero downtime maintenance, or even site load balancing. Use your imagination. Multiple copies of your data, Read/Write, accessed across the world (Access Anywhere), its a compelling story and one that companies are seriously considering. Although not without its set of challenges, VPLEX is the future of data mobility and a product we (as technologists) should all be familiar with. This is EMC's vision of Virtual Storage…  

VPLEX Flavors - Product family below, current state (I purposely left out global due to it's lengthly time to market) with a bit of design consideration sprinkled in. 

Local – Single Site/Data center. 1, 2 or 4 engines. By the way an engine handles or services all your front end and back end processing (I/O). Within the engine are 2 directors, Director B and A right to left. Each director has 5 I/O modules, so 10 total for a single engine. 1 (4 8G FC ports) module for FE connectivity, ie to which you would zone your hosts to. 1 (4 8G FC ports) module for BE connectivity, i.e. to which you would zone your arrays to. 1 for WAN COM (used exclusively for Metro and Geo configurations) in either a 4 8G FC port module or a 2 port 10G module for cross site communications. 1 module with 2 8G FC ports for intra cluster comm and finally 1 module for expansion or future use. With this configuration you can service or virtualize up to 8000 LUNs. 

Metro – 2 sites. Synchronous distances, less than 5ms latency. 2 to 8 engines. Total of 16000 LUNs virtualize capable. Of note all WAN COM or intercluster communication is over FC. Typically this is over an extended fabric between sites (ISL's) 

Geo – 2 sites. Asynchronous distances, less that 50ms latency. 2 to 8 engines. Total of 1600 LUNs virtualize capable. Of note all WAN COM or intercluster communication is over IP (over 10G capable on VS2 HW, 1G on VS1 HW)

I tell you, I find these two products just fascinating. The combination of Disaster Avoidance and Disaster Recovery is truly unprecedented. Who would have thought, 10 years ago we would have been standing at a doorway that is open to so many possibilities.

To think beyond a server or rack back then is now thinking beyond a physical data center. The level of abstraction available to us today allows us to dream the impossible. So outside of this post, I challenge you to think beyond whats comfortable in your data center and imagine the unimaginable.   

So anyway, lets look at how these two titans of reverie mesh. Now VPLEX is like a new born infant to me, I don’t yet know how to care for it. But I will do my best. I will do my best. RecoverPoint is of course, old hat :) So let’s start with key concepts of each product…

VPLEX Volumes, and yes it is confusing..

Storage Volumes–these simply are LUNs that you have presented to the VPLEX backend. These LUNs can be from not only EMC arrays but any supported third party array. EMC is really starting to diversify its product line so it’s no longer a “this is my world operate within it” type mentality. RecoverPoint is another example for support of third party arrays.

Extents– these are slivers of a storage volume or a one to one mapping between the said storage volume. This is important for RecoverPoint integration.

Device– these map to extents. A single device can encompass multiple extents or can be one to one. A tell tell sign of a device is its RAID type or protection scheme as its noted. Now an extension of a device is the concept of distributed device. This is two legs of an extent (RAID 1 protection) from two separate VPLEX clusters. This is known as Metro-Plex, sync distances apply. So in summary, a device is typically two extents, one from each array at a single site. A distributed device is two extents, one from each array across two separate sites. And finally..

Virtual Volumes – these are mapped to devices and are “exposed” to the hosts by way of the VPLEX FE ports. Single site = Virtual volumes, 2 sites = Distributed Virtual Volumes.

So here are the associations in directional format..

Storage Volumes ->Extent(s) ->Device ->Virtual Volumes. Say it again in your head. Ok once more..now make yourself a sandwich..

RecoverPoint Volumes, not as confusing..

There are a number of volumes associated with RecoverPoint environments, but in the interest of time I will focus on just the ones pertinent to VPLEX integration...

Production Volume  - these volumes or LUNs are nothing more than your source volume. This is where your data lives, not to sound too much like an EMC marketing ad.

Replica Volume– this is a block for block copy of your source volume. This can exist on your source array or a destination array, depending on what type of replication is in play. For this post, the replica volume will be part of a CRR configuration. CRR stands for Continuous Remote Replication and is unidirectional async replication from Site A to Site B.

Now there are journal volumes, and repository volumes as well but these two volume examples should get us through this example.

So consider the first graphic below… this is a distributed virtual volume between site A and site B. Site C is where our RP replica(referenced as the Target Remote Copy) is in our CRR configuration. What’s important to note, and the significance of this post is VPLEX Metro and RecoverPoint CRR w/ CX4 Splitter Co-exist, they really don’t provide a complete dynamic solution. And here’s why…

For these two products to co-exist, there has to be a one to one mapping between storage volumes and extents, between extents and devices and between devices and virtual volumes. No big deal, right? Right. But this whole design is based on the assumption that the Source Volume (represented as “Source”) never moves. If it does replication is broken. So the act of “Data Mobility”, of moving a source storage volume from one LUN to another or one array to another breaks replication. This assumes the whole reason you bought VPLEX is to have the flexibility of moving your data, non-disruptive, right?  

Queue second graphic…

So the act of performing “Data Mobility”, or moving a source storage volume from one LUN to another or another array, breaks replication, yes I said it again..

I suspect in future RP releases, that there will be the concept of multiple source volumes that operate within a group setting. So as you move a storage volume around on the backend (whether between sites or arrays), RP will track that movement and adjust its replication according. This is manual today within RP and requires a full sweep after reconfiguring the source volume within the consistency group, but doable.

I can tell you this makes a lot of sense in a number of customer environments, having the flexibility to move workloads around yet still maintain DR capabilities is the Data Center of the future that we tout and want.