{"id":1705,"date":"2012-02-13T11:26:32","date_gmt":"2012-02-13T16:26:32","guid":{"rendered":"http:\/\/chriscolotti.us\/?p=1705"},"modified":"2012-05-06T19:08:56","modified_gmt":"2012-05-06T23:08:56","slug":"disaster-recovery-in-vcloud-director","status":"publish","type":"post","link":"https:\/\/chriscolotti.us\/vmware\/disaster-recovery-in-vcloud-director\/","title":{"rendered":"Disaster Recovery in vCloud Director"},"content":{"rendered":"
Note:<\/strong> This is a re-post of the article written for the VMware vCloud Blogs<\/a>.<\/p>\n This article assumes the reader has knowledge of vCloud Director, Site Recovery Manger, and vSphere. It will not go in to depth on some topics, we would like to refer to the Site Recovery Manager, vCloud Director and vSphere documentation for more in-depth details around some of the concepts. This solution is very much about Disaster Recovery OF the Cloud infrastructure itself using Site Recovery Manager and vCloud Director. This is not intended to be a fully integrated solution, but rather a way to use both products together to achieve BCDR of the cloud.<\/p>\n Creating DR solutions for vCloud Director poses multiple challenges. These challenges all have a common theme. That is the automatic creation of objects by VMware vCloud Director such as resource pools, virtual machines, folders, and portgroups. vCloud Director and vCenter Server both heavily rely on management object reference identifiers (MoRef ID’s) for these objects. Any unplanned changes to these identifiers could, and often will, result in loss of functionality. vSphere Site Recovery Manager currently does not support protection of virtual machines managed by vCloud Director.<\/p>\n The vCloud Director and vCenter objects, which are referenced by each product, that are both identified to cause problems when identifiers are changed are:<\/p>\n Besides automatically created objects the following pre-created static objects are also often used and referenced to by vCloud Director.<\/p>\n Over the last few months we have worked on, and validated a solution which avoids changes to any of these objects. This solution simplifies the recovery of a vCloud Infrastructure and increases management infrastructure resiliency. The amazing thing is it can be implemented today with current products.<\/p>\n In this blog post we will give an overview of the developed solution and the basic concepts. For more details, implementation guidance or info about possible automation points we recommend contacting your VMware representative and you engage VMware Professional Services.<\/p>\n vCloud Director disaster recovery can be achieved through various scenarios and configurations. This blog post is focused on a single scenario to allow for a simple explanation of the concept. A white paper explaining some of the basic concepts is also currently being developed and will be released soon. The concept can easily be adapted for other scenarios, however you should inquire first to ensure supportability. This scenario uses a so-called “Active \/ Standby” approach where hosts in the recovery site are not in use for regular workloads.<\/p>\n In order to ensure all management components are restarted in the correct order, and in the least amount of time vSphere Site Recovery Manager will be used to orchestrate the fail-over. As of writing, vSphere Site Recovery Manager does not support the protection of VMware vCloud Director workloads. Due to this limitation these will be failed-over through several manual steps. All of these steps can be automated using tools like vSphere PowerCLI or vCenter Orchestrator.<\/p>\n The following diagram depicts a logical overview of the management clusters for both the protected and the recovery site.<\/p>\n\n
\n
Logical Architecture Overview<\/h2>\n