This is part 3 of a 3 part blog post. The first one categorized various “disaster avoidance + disaster recovery” solutions. The second examined more closely one of the solutions (stretched vSphere clusters) and also the implications on the storage (and touched on the network) layers. That second post also discussed the gory details of EMC VPLEX in those use cases.
The 3rd post will talk about where the R&D and product development is taking us in the world of Disaster Avoidance and Disaster Recovery.
BTW – thank you to many on the EMC and VMware teams who have given great input on post I and II.
I’d strongly suggest starting with “Post I” – which you can read here, and “Post II’ – which you can read here.
OK – are you back?
So – what are we (without divulging any material details :-) thinking and spending a lot of time?
First of all – all roadmaps are subject to change, and I can’t really discuss the roadmaps in this forum, PERIOD. As close as I’ll get is the below (and no, I will not characterize “near”, “mid” or “long”.
The most important thing to understand is that “linking” the private IaaS clouds that enterprises are building (usually on VMware) with the public IaaS clouds that are emerging (often on VMware) is something that is of great interest to EMC. The core question we’re trying to figure out is “how important is that mobility being non-disruptive, vs. ‘a little bit of downtime’”.
So – what are we working on?
Near – Changing VPLEX partition behavior – will mark the target as “dead”, working better with vSphere.
- This is a relatively small thing. As alluded to in the other posts, having the VPLEX signal differently to vSphere (rather than going read-only) that the datastore is dead would result in more defined behavior in some of the more tricky failure cases, and would require less human intervention. File this under “improvement”.
Mid – Introduction of VPLEX Geo (Async) – will have interesting failure behavior
- We’ve been public that VPLEX Geo (stretching active-active storage models over async-class distances) will GA in 2011. This creates some funky behaviors. The keys to understanding this are:
- realize that the IOs are served locally.
- That all a VM’s IO traffic is served by an ESX host that lives on one side or another, and during a VMotion, there is an atomic cut-over of which initiators and host are servicing a given VM.
- VPLEX cache makes it so that each side of the Metro-Plex (or in this case “Geo-Plex”) sees the same image of the datastore all the time, but what is actually in the local cache and the local non-volatile storage isn’t the same on both sides. When a chunk of data that isn’t in the local VPLEX cluster, it grabs it from the remote VPLEX cluster.
- This means you can vmotion willy-nilly, and aren’t replicating everything, just the data needed - “sub VMDK” in fact.
- BUT – left to itself, THAT means that on partition, you may not have “all” of a VM (only the chunks of data requested). Ouch – that’s a “splinch" in Harry Potter vernacular.
- So – we need to have some way of “revert to coherent state”, which means that at WORST it would have the behavior (both in terms of bandwidth and RPO) of an async replica ON PARTITON, and the magic behavior of VPLEX when there is no partition.
- As 2011 approaches, and we know we’re introducing this funky new idea, a lot of time and effort is being spent on “solutioneering”. Expect blog posts on the topic.
Mid – Extending to active-active geographically dispersed NAS models
- VPLEX today is a block model. Of course, the natural idea is how do you “layer on top” NAS functionality?
- You could, in theory, geographically federate the storage under a datamover, making failover occur over geographic distance. This wouldn’t be active/active per se, but active/passive, with a failover that could occur in failover time periods.
- We’re spending a lot of time thinking about active-active models that would mirror what VPLEX does for block. This is tricky, but we’re exploring.
- Of course, new scale-out NAS models raise interesting questions on that also.
Long – Working hard to determine how to get the benefits of SRM, without losing non-disruptive vMotion
- This is one we can’t solve without our VMware brothers/sisters. Scheduled/automated register/deregister (and handle recreating all the vCenter properties of a VM) is something SRM does today. But, architecturally it has the idea of vCenter at every side (which is a good thing, IMO). Until inter-vCenter vMotion becomes possible, that means that all these “vMotion between sites” solutions are kind of orthogonal to SRM.
- What seems like it could ideal would be inter-vCenter vmotion (with all the stuff that entails), which would make SRM-type models not be mutually exclusive with non-disruptive site-to-site mobility.
- It’s not nearly as “simple” as it sounds on the surface, of course.
Long – Are there simpler ways to deal with the networking issues?
- If you look at what I just said above (and the Networking issues discussed in post II), inter-vCenter motion looks like that to hit the “bulk of the use-cases” would need to somehow deal with the fact that you couldn’t by definition assume Layer-2 equivalence at both sites.
- Are there easier ways (thinking along the lines of the “kinda built-in” NAT that is part of vCD as an example.
Near – As much as I hate to say it :-) some very cool Hyper-V and Oracle solutions
- Actually, I don’t hate saying it. EMC completely embraces and supports Hyper-V and Oracle. There are loads of exiting soluions docs, like this one, and you should expect to see more.
One area where we could get help from you, dear reader, is helping us understand YOUR use cases. I’d love to see your comments, hear what you are looking for. In particular, we’re trying to “suss out” the answer to the question: “how much is non-disruptive site-to-site mobility worth to you? Where would you prioritize it?”
In January, I’ll post a survey (with prizes!!!):
- How important is “non-disruptive” to you, site-to-site?
- Is “cold migration” good enough?
- What are your thoughts on IP mgmt (are you looking at OTV type stuff?)
- Would you pay for it (easiest litmus test of “nice to have”)
Thanks for bearing with me through this blog post series – hope it is useful to you!
Would love get your commentary!
Comments