Background
It has been demonstrated how SRM, in conjunction with some complimentary custom automation, can be used to offer a vCloud DR solution that enables recovery of a vCloud Director solution at a recovery site.
In cases where stretched Layer 2 networks are present the recovery of vApps is greatly simplified because vApps can remain connected to the same logically defined virtual networks, regardless of the physical location in which the vApps are running.
The existing vCloud DR process, while theoretically capable of supporting designs that do not include stretched Layer 2 networks, does not lend itself well to this configuration. The primary issue is the requirement to update the network configuration of all vApps. The complexity associated with the reconfiguration of vApp networking is influenced by a number of factors including:
Type of networks to which a vApp is connected (organization
virtual datacenter, organization external, or vApp).
Routing configuration of the networks to which the vApp is connected (NAT routed or direct).
Firewall and/or NAT configuration defined on vCloud Networking and Security
Edge devices (NAT routed).
Quantity of networks to which the vApp is connected.
When connected to an organization virtual datacenter network there is little or no impact. The vApp can retain its initial configuration as there are no dependencies upon the physical network. This is not the case for organization external networks.
In the case of vApps connected to an organization external network that is direct connected, the current vCloud DR process would involve the vApps be disconnected from the network for the production site and connected to an equivalent network for the recovery site. For this, site-specific network configuration parameters such as netmask, gateway, and DNS must be defined. Following reconfiguration, external references to the vApps also need updating. This situation is further complicated when an organization external network has a routed connection. The complication arises from the multiple IP address changes taking place:
1. The vApp is allocated a new IP address from the new organization virtual datacenter network.
2. The associated external network has a different IP address.
The introduction of vApp networks can further compound this complication.
VXLAN makes it possible to simplify the DR and multi-location implementation of vCloud Director. This is achieved by creating a Layer 2 overlay network without changing the Layer 3 interconnects that are already in place. The following explains how to get an SRM-based vCloud Director implementation to failover without the need to re-IP the virtual machines, as well as the scripted changes that need to be done to simplify the process.