Appendix C: vCloud Suite Disaster Recovery : Using VXLAN to Simplify vCloud Disaster Recovery : Background : Logical infrastructure
   
Logical infrastructure
To address the complexities of recovering a vApp from the production site to the recovery site in the absence of stretched Layer 2 networking, a mechanism is required to abstract the underlying IP address changes from the vApps being recovered. The following diagram provides a logical overview of the infrastructure deployed.
Figure 60. Logical View of Infrastructure
In the resource cluster, all vSphere hosts are connected to a common VDS with site-specific port groups defined for the Internet and Internet_DR networks. In vCloud Director the Internet and Internet_DR port groups are defined as external networks. In conjunction with this, an organization virtual datacenter network is defined and as a result, a port group from the VXLAN network pool is deployed.
The vSphere hosts deployed in the production site are connected to a common Layer 3 management network. Similarly, the vSphere hosts deployed in the recovery site are connected to a common Layer 3 management network, albeit in a different Layer 3 than that of the network for the production site. In addition the Internet external networks are the primary networks that will be used for vApp connectivity, and they are also in a different Layer 3 than the Internet network available in the recovery site. These are attached to vCloud Director as two distinct external networks. vCloud Networking and Security Edge firewall rules, NAT translations, load balancer configurations, and VPN configurations have to be duplicated to cover the disparate production and failover address spaces. There are two options for keeping the configurations in sync:
Option 1: Maintain the configuration for both sites at the same time.
*AdvantagesSimplifies failover as configurations are already in place.
*Disadvantages:
*Requires the organization administrator to be diligent in maintaining the configurations.
*Difficult to troubleshoot if there is a configuration mismatch.
*Primary interface needs to be removed if hosts on the original Layer 2 primary network needs to be reachable.
Option 2: Use the API upon failover to duplicate the primary site configuration to the failover site.
*Advantages:
*No maintenance after initial failover address space metadata has been populated.
*Address mapping can be done and allocated in advance.
*Disadvantages:
*Need to have failover address metadata specified to work.
*Address size needs match to simplify mapping.
*Address pool size needs to match to simplify mapping.
Leveraging VXLAN can greatly simplify the deployment of vCloud Director DR solutions in the absence of stretched Layer 2 networking. Furthermore, this type of networking topology is complimentary to the solution defined in the vCloud DR Solution Tech Guide and can be implemented with relatively few additions to the existing vCloud DR Recovery Process.
Following the successful recovery of a vCloud Director management cluster, some additional steps need to be included in the recovery of resource clusters to facilitate the recovery of Edge Gateway appliances and vApps. See the VXLAN Example in Implementation Examples.