The first thing that you will need to do is make sure that your array is supported by VMware and licensed for an array-based replication by the array vendor. This is not a VMware license but a licensed feature from the storage vendor.

Now, to enable replication, you have a couple of approaches that you could employ, which are as follows:

Approach-1 is used in scenarios where the array does not have the spare capacity to provide a separate LUN to host-protected VMs. This approach adds an administrative overhead if the virtual machines are spread across multiple datastores. It also contributes to wastage of replication bandwidth and storage space since the LUNs that are replicated will contain unprotected virtual machine data.

Approach-2 is used in scenarios where you have ample spare capacity. This approach is the best as it reduces complexity, avoids replication bandwidth wastage, and reduces space wastage, as compared to Approach-1. However, this approach will have an impact on the size of the LUNs required at both the protected and replication sites.

If you are involved in a new implementation, then you will have to plan how the ESXi hosts are zoned to the array at both the protected and recovery sites. This means that LUNs should be correctly zoned at the fabric. The details for protected site and recovery site arrays are as follows:

VCenter SRM has to be installed at both the protected and recovery sites for the disaster recovery setup to work. The installation process is identical regardless of the site it is being installed on; the only difference is that at each site, you will be registering the SRM installation to the vCenter Server managing that site.

SRM can either be installed on the same machine that has vCenter Server installed or on a different machine. The decision to choose either one of the installation models depends on how you want to size or separate the service-providing machines in your infrastructure. The most common deployment model is to have both vCenter and SRM on the same machine. The rationale behind this is that SRM will not work in a standalone mode; this means that if your vCenter Server goes down, there is no way you could access SRM. Like vCenter Server, SRM can be installed on a physical or virtual machine.

Another factor that you must take into account is the installation of SRA. SRAs have to be installed on the same machine where you already have SRM installed. Some SRAs need a reboot after installation. So, it is important to read through the storage vendor's documentation prior to proceeding to make a deployment choice for SRM. If the vCenter downtime is not feasible, then you will have to consider installing SRM on a separate machine.

Nevertheless, it is important to be aware of the software and hardware requirements of a software installation before it is actually installed. This is to make sure that you don't run into compatibility or supportability issues during the course of using the product. To understand the requirement of SRM, refer to page number 23 in Chapter 2, Site Recovery Manager System Requirements, in the Site Recovery Manager installation and configuration guide for SRM 5.5 document available at http://pubs.vmware.com/srm-55/topic/com.vmware.ICbase/PDF/srm-install-config-5-5.pdf.

The following flowchart depicts the processes involved in installing vCenter SRM:

The SRM functions are exposed in the vSphere Client UI with the help of the SRM plugin. The SRM installer does not install this plugin. This is because it is a plugin for the vSphere Client and not the vCenter Server. The plugin needs to be installed separately on the machine where you have vSphere Client installed.

This is how you do it:

Once SRM is installed on both the sites, the next step is to pair the sites together. The pairing process establishes a connection between the vCenter Servers at the protected and recovery sites, which in turn makes the SRM instances at both the sites aware of its counterpart at the other site (protected/recovery). Without the sites being paired, we can't proceed further with the configuration of the DR setup.

This is how the sites are paired:

Keep in mind that the pairing is done only from one of the sites. This is because the pairing process establishes reciprocity by configuring the connection in the reverse direction as well. However, when you open the site recovery solution at the remote vCenter Server, you will be prompted to enter the administrator credentials of the other site.

Once you have the SRM instances installed and paired, the next step is to install the Storage Replication Adapters. SRAs are coded and provided by the storage vendors. VMware certifies the SRAs and posts them as compatible with the SRM.

Once you have the SRA installed and discovered at both the sites, you will need to add an array manager at both the sites. An array manager is required to discover the replicated LUNs and perform other storage operations initiated by SRM.

This is how you add an array manager:

An array pair shows the replication relationship between two arrays. Before you enable an array pair, you need SRA installed and the array manager added at both the sites. For the array manager to detect an array pair, there should be a replication schedule already created between the arrays. Refer to the vendor documentation to understand what a replication schedule means for the vendor's array and the procedure to create it.

This is how you enable an array pair:

In the next chapter, you will learn how to create Protection Groups. For every virtual machine that becomes part of a Protection Group, SRM creates a shadow virtual machine. A placeholder datastore is used to store the files for the shadow virtual machines. The datastore used for this purpose should be accessible to all the hosts in the datacenter/cluster serving the role of a recovery-host. We will learn more about Protection Groups and shadow virtual machines in the next chapter. For now, understand that configuring placeholder datastores is an essential step in forming an SRM environment.

Assuming that each of these paired sites is geographically separated, each site will have its own placeholder datastore. The following figure shows the site and placeholder datastore relationship:

This is how you configure placeholder datastores:

Creating resource, folder, and network mappings facilitates further orchestration of the Recovery Plan that will be executed for either a Planned Migration or a Failover. Without these mappings, you won't be able to configure protection on the virtual machines, and the protection status will indicate that these mapping are missing. We will learn more about Protection Groups in the next chapter.

Apart from being a requirement for creating Protection Groups, there are other use cases as well. The following table shows a few common ones:

With SRM implementations, there is a common argument about the placement of the virtual machine swap files. Some would suggest maintaining a separate datastore for the virtual machine swap files, while some are against it. Before we try to understand the rationale behind either of the design choices, it is important to know what a virtual machine swap file is.

Every virtual machine will have a swap file (.vswp). This swap file is created every time a virtual machine is powered on. The size of the swap file is equal to the size of the memory assigned to the virtual machine, unless there is a reservation. If there is a memory reservation, then the size of the swap file will be equal to the size of the unreserved memory. Although rare, some environments use limits on memory as well.

So, the ideal formula to calculate the size of the swap file is as follows:

Swap file size = memory limit – memory reservation

The default memory reservation is 0 MB, and the default limit is equal to the configured size of the memory. By default, the swap file is stored along with the virtual machine in its working directory.