A Disaster Recovery Discovery to vCloud vApps

So while recently working on a couple of vCloud design engagements I’ve been having some discussions around the recoverability of vCloud and its artifacts with some VMware colleagues and one in particular who I call Manchach (Michael Mannarino), the VMware architect that I mentioned on my previous posts related to Auto Deploy and Cisco UCS, but enough about him again, that dude is just crazy. So the talks were about finding ways to protecting and recovering the environment from the infrastructure and vApps components as much as we could in order to provide a solution that our customer could agreed to from a recoverrability standpoint. Now I want to make it clear that this is not the complete soup to nuts solution automatic recovery and it works with a specific use case at the moment, but I have some other pieces that I’m finalizing a couple of other efforts to streamline what we’re trying to accomplish here with the east administrative effort. This post is part one of a three part series. So Manchach (Michael Mannarino) pounded on my door the with a thorn in his side.  The thorn was the recovery of vCloud Director.  An age old problem with provisioning systems.  Immediately we began to whiteboard solutions and prioritize the viability and complexity of each of the solutions.  The goal was to create a recover solution for vCD within an environment based on full disaster recovery (names of environments are not important here – what is important is a viable recovery solution for vCD).  The objective was to perform that recovery of workloads within vCD within an acceptable amount of the time, once a disaster has been declared on-site…Low and behold we believe we created a solution some 22 hours later…being a newlywed – you can bet I got no action at home that weekend working on the recovery…but ultimately for my sanity and my customers (present and future) it was worth it.

The environment for vCD recovery consisted of the following:

• ONE primary DC (let’s call it DCWest)
• ONE secondary DC (let’s call it DCEast)
• Close proximity to span the LAN networks between the primary DC and secondary DC.
• All workloads would run in production in the primary DC.  All workloads would be recovered for production in the secondary DC