Scenario:  

For some of my VMware SRM customers, the network allows production VLANs and subnets to be extended to the recovery site, which allows us to keep the IP settings of VMs during a planned migration or disaster recovery.   This certainly simplifies our DR planning.  For example, DNS records do not have to be updated during a disaster recovery or planned migration, because the IP addresses of the VMs will not be changed.  We can run a set of Active Directory (AD) controllers and Domain Name Service (DNS) servers at the recovery site, where they stay synchronized with their counterparts that run at the protected site. This means that current AD and DNS data is available at the recovery site and that SRM does not have to recover AD and DNS during a real disaster recovery.

However, some challenges may exist while performing non-disruptive test recoveries in this scenario, which typically requires isolated test network networks.  The first concern is whether or not the IP settings for VMs must be changed during non-disruptive tests, to allow the original VMs and applications to continue to run undisturbed.    Preferably, the test networks will allow us to keep the original IP settings of  the VMs without being visible to the production network, where the IP addresses are currently in use.   If this can be achieved, then the next issue is how to provide the required AD controllers and DNS servers for test purposes.  Ideally, the AD controllers and DNS servers would provide current data (current at the moment the test began), would run in the test network with no concern that they can be seen by the production network, and would be easily removed after the test is complete.

Proposal:

To facilitate non-disruptive testing, we could use vSphere Replication (VR), a recovery plan, and the Test Recovery option in SRM to failover AD, DNS, and other required infrastructure severs to the test network, prior to using Test Recovery to failover any other test plan. This ensures that the test network has access to recently updated AD, DNS and other infrastructure servers, which are isolated from production networks during the test, but are available to the VMs being tested. These infrastructure servers can harmlessly be modified in any manner during the test period. After the test is complete, the Cleanup operation in SRM can be used to clean up the VMs involved both recovery plans.

NOTE-1:

The infrastructure (AD, DNS, DHCP, etc) VMs should Not be recovered when performing actual Disaster Recovery migrations. Instead, peers of these servers, which are kept consistent via the application (such as AD synchronization), should reside at the recovery site.

NOTE-2:

In some cases, the state of the AD controller could be inconsistent and produce errors when it is brought up at the recovery site during a Test Recovery operation. This could occur if the AD controller was in the midst of an AD synchronization when the VR replication occurred. In this rare case, just use the Cleanup operation and repeat the Test Recovery operation.

NOTE-3:

This proposal should only be implemented if the Test Network is completely isolated from the Production Network. It is acceptable that the test network be comprised of multiple networks (VLAN / subnets) that communicate with each other, as long as none of these networks can communicate with any production network.

 Note-4:  In most cases, only a single AD controller should be included in the test recovery.  VR does not quiesce multiple VMs simultaneously, even if they are part of the same protection group, so two or more domain controllers may not be in sync if recovered together.

The post Proposal for Providing AD and DNS for SRM Test Failover appeared first on New Age Technologies.

Planning

The first key is planning.  The main difference in planning for a shared recovery site versus a standard recovery site is that SRM must be installed twice at the recovery site (once for each protected site).  SRM must be installed into separate Windows servers at the shared recovery site.  These two SRM instances represent a single site, but will have unique SRM-IDs.   The SRM-ID can be thought of as the name of an SRM instance at the shared recovery site.  A common convention is to set each SRM-ID value to a string that combines the recovery site name and the site that the instance it protects.

For example, consider a case where the shared recovery site is called Dallas, which protects two sites called Denver and Seattle.   At the Dallas site, SRM must be installed in two Windows servers.  One SRM instance will be used to protect the Denver site and the other instance will protect the Seattle site.  In this case, a sensible choice for the SRM-IDs may be DAL-DEN and DAL-SEA.

Custom Installation

The second key is to perform the custom installation.  To perform the custom installation:

• Using one of the Windows servers at the shared recovery site, where an SRM instance will be implemented to protect one specific site, download the SRM installer.
• In a command prompt, change the default directory to the location of the installer.
• Run this command to launch the wizard for the custom installer:VMware-srm-5.1.1-1082082.exe /V”CUSTOM_SETUP=1”
• The custom installation wizard should look much like the standard installation wizard, except that it includes some extra pages and options.  The first additional page is the VMware SRM Plugin Identifier page.   On this page, select Custom_SRM Plugin Identifier.
• The second additional page prompts the user to provide the SRM ID, Organization, and Description.  The critical value to provide is the SRM_ID, which should be set to the value that is planned for one of the SRM instances at the shared recovery site.  (For example, DAL-DEN).
• The remainder of the installation process is identical to a standard installation.  Be sure to repeat these steps for the second SRM instance at the shared recovery site.

Connecting the Protected Site to the Correct SRM Instance

The third key is to connect each protected site to the correct SRM instance at the shared recovery site.  The main difference in connecting each protected site to shared recovery site versus connecting to a standard recovery site is to select the appropriate SRM-ID.  Begin by performing the typical steps to connect the protected site to the recovery site, which requires using the SRM plugin for the vSphere Client to select the first protected site and click Configure Connection.  In the Connection wizard, an extra page will appear after selecting the vCenter Server at the recovery site.  The extra page identifies the two SRM instances at the recovery site by displaying a list providing the SRM-ID, Organization, and Description of each SRM instance.  Choose the SRM-ID that corresponds to the SRM instance that should be used to protect the first site.   Naturally, this process should be repeated for the second protected site.

The post VMware SRM Custom Install – Shared Recovery Site appeared first on New Age Technologies.