Specifications

9 Deploying VMware vCenter Site Recovery Manager with NetApp FAS/V-Series Storage Systems
SRM and the NetApp adapter will support connecting to a datastore over a private storage network rather
than the network or ports used for system administration, virtual machine access, user access, and so on.
This support is provided by the addition of a new field, called NFS IP Addresses, in the NetApp adapter
setup screen in the SRM array manager configuration wizard.
To support private back end NFS storage networks, addresses of the storage controller that are used to
serve NFS from that controller to the ESX hosts must be entered in the NFS IP Addresses field. If the
controller uses multiple IP addresses to serve NFS data, these IP addresses are entered in the NFS IP
Addresses field and are separated by commas.
If specific IP addresses are not entered in the NFS IP Addresses field to use for NFS datastore connections,
then the disaster recovery NAS adapter returns all available IP address of the storage controller to SRM.
When SRM performs a DR test or failover, it will attempt to make NFS mounts to every IP address on the
controller, even ones that the ESX hosts would be unable to access from the VMkernel ports such as
addresses on other networks.
Below is a simple diagram showing the IP addresses used in the DR site of the NAS environment. In a later
section of this document we will see the NFS IP addresses shown here entered into the NAS adapter in the
SRM array configuration wizard.
Figure 4 Dual NFS Storage Networks Example
4.4 DR TESTING NETWORK CONSIDERATIONS
When a DR test is performed, a private test bubble network is created on the ESX host for the virtual
machines, however this network is not automatically connected to any physical network adapters and so
provides no connectivity between ESX hosts. To allow communication among virtual machines running on
different ESX hosts during DR testing, a physical private network has been created between the ESX hosts
at the DR site. To accomplish this, the test bubble network can be separated physically or by using VLANs
or VLAN tagging. Segregating this network from the production network is required.
4.5 ACTIVE DIRECTORY SERVICES CONSIDERATIONS
The Active Directory/DNS architecture plays an important role in successful failover, DR test, and failback
scenarios. AD servers should not be recovered from replicas created by unsupported processes because
this could create a USN rollback scenario. See MS KB888794
http://support.microsoft.com/kb/888794/ for information regarding supported methods of creating
backups of AD servers in virtual server environments.
PROVIDING ACTIVE DIRECTORY SERVICES FOR SRM DR TESTING
To provide name resolution and user authentication services in the private DR test network an AD server at
the DR site may be cloned prior to running the DR test. Before powering on the VM reconfigure the VMs
network connections to connect the cloned AD server only to the DR test network. The AD server chosen to
clone must be one that was configured as a global catalog server. Some applications and AD functions
require FSMO roles in the Active Directory forest. To seize the roles on the cloned AD server in the private
test network use the procedure described in Microsoft KB: http://support.microsoft.com/kb/255504. After the