Well, there you have it vCloud Air Disaster Recovery is now generally available! I’ve been working behind the scenes on this for some time since before it was in Beta, and I’m proud to say I have been part of this launch. I plan on continuing to record some more videos and writing blog posts as well as speaking on the topic over the next few months. I bet you cannot guess what my key VMworld session submission will be about can you? I did want to take a couple minutes just to talk about 5 things I think people should know right off the bat. Before you go further just remember that this new offering is specific to allowing vSphere based machines the ability to replicated to vCloud Air for Disaster Recovery.
What is Being Used to Replicate Machines?
The easy answer is that vSphere Replication is being used. However, it is a modified version from the 5.5 release that adds some new underlying components. This means if you go to download vSphere Replication you will see two versions. Version 5.5 is for use with Site Recovery Manager, and 5.6 is for use with vCloud Air Disaster Recovery. You will know if you got the right one if you have the ability to configure and replicate to a cloud provider.
How Many Machines Can I replicate To vCloud Air-DR?
Well, I have had requests for 20 to 1500. The fact of the matter is that there is a 500 machine limit to any single vCenter/vSphere Replication pair. That means if you have more than 500 machines, you will need to separate them into multiple pairs of servers and also procure another vCloud Air-DR virtual data center. The reason is your cloud based tenant will also only have a single vSphere Replication Server for you as a tenant also good for 500 machines on the cloud side. You can scale as you need to and that’s the good thing!
Are There vCloud Air-DR API’s?
Yes! There are some extensions for vCloud Air Disaster Recovery for the main things you’d want to do without vCenter. Mainly, Failover, Stop Replication, and Test Failover. Beyond these the other standard vCloud API’s would be used to automate a workflow. Things like powering on a machine, changing networks, editing the virtual machine hardware are all done through the existing vCloud API’s. The Disaster Recovery API’s are specific to to the functions related to Disaster Recovery in the cloud. There is not currently any API for the on premises side to create and edit a replication through vSphere Replication. That’s because previously vSR has never had a need for API.
Is Replication encrypted?
YES! The data is encrypted in flight from on premises to the vCloud Air side. The traffic is also passed using a vCloud Proxy service on the vCloud Director cells so you are still processing data through a single API endpoint. This makes it a very simple setup for you to set up the appliance and get connected to the service once you’ve purchased a subscription.
Is It Easy To Use?
Hellz yeah it is. It’s one virtual appliance to download and import into vCenter. From there you connect to your cloud and decide which machines to start replicating. It goes without saying that you still need to develop a failover run book like you would with any solution. From there you can think about where and how you may want to automate things. I have presented and will present a few slides on where some of the integration points are for a simple run book. The bottom line is it’s easy to deploy and get setup and start replication machines to vCloud Air.
How is On Premises Connected to the vCloud Air-DR Side
Actually they are not “Connected” in the sense of a VPN unless you elect for the Direct Connect capability. What I mean is by default the replication is per machine using random ports and an encrypted channel to send the data changes to vCloud Air. There is no permanent connection to your site unless you use Direct Connect. That being said, even in that case once you have a DR event the assumption is the on prem side is gone so the direct connect link has no access back to your original data center.
How Do I Handle Networking Changes
That depends actually. If the machines being failed over are public facing you can assign new vCloud Air public IP’s to them and update your external DNS, with a low TTL of course. That’s standard procedure for moving web-based applications for most people. I will be doing a video on this actually in the coming weeks. For internal only machines, if they are now in the cloud they need access to Active Directory and other services that may reside in another site that was not part of the DR event. I am covering that in another blog post later this week on vcloud.vmware.com, but the bottom line is you have to create your run book to contend for IP changes for the machine in the new site. This is also pretty standard for a disaster recovery run book.
Be sure to check out all the tutorial videos I recorded as well to see it in action!