When using VMware Site Recovery Manager 5 to protect your vSphere environment, you need to carefully consider several storage configuration options. Two of the earliest decisions an organization needs to make are whether to utilize vSphere Replication or array-based replication, and how the array should be configured at the recovery site.
More on Site Recovery Manager
Demystifying VMware Site Recovery Manager and its role in DR
Site Recovery Manager: Getting schooled in disaster recovery
FAQ: Creating a VMware disaster recovery plan
Using vSphere Replication with Site Recovery Manager
VSphere Replication enables replication between two different types of arrays, which can significantly reduce the cost of the solution by implementing an older or less expensive array at the recovery site. It will also enable a simpler storage-design process, because it is enabled on an individual virtual machine (VM) basis.
With vSphere Replication, no special storage configuration is necessary, other than ensuring the destination array has the proper capacity and performance. On the other hand, vSphere Replication limits the replication frequency to between 15 minutes and 24 hours. This limitation may not fit with the recovery point objective (RPO) needs of all applications.
Site Recovery Manager with array-based replication
Array-based replication technologies will offer more advanced replication features, such as synchronous replication, which guarantees zero data loss by waiting for acknowledgement from the remote storage that a write has been committed. Some arrays also have deduplication or compression capabilities that reduce the amount of bandwidth required during replications. Most array-based replication technologies are usually vendor specific and will often work only when the same array model exists at both the protected and recovery sites.
Using array-based replication also requires more work to properly place VMs onto the VMware Virtual Machine File System volumes. For most arrays, replication occurs at the logical unit number (LUN) level, so it takes planning to ensure that the VMs needing protection are properly replicated. This planning must start with defining the RPO for all of the applications in each VM. To set a VM’s RPO, you must consider the most stringent (shortest) RPO of all applications on that VM.
Next, you need to group VMs based on the order in which they will be recovered. For example, each tier of a multi-tiered application should be recovered together to ensure the entire application will function. At this step, consider VMs that may support multiple applications. These groups will translate directly into the storage configuration of the Site Recovery Manager protection groups, which is a set of VMs that will be recovered together and is based on LUN-level replication. Therefore, VMs that have similar RPOs and will need to be recovered as a group should be placed on a LUN or set of LUNs together. You can then configure each LUN with the proper replication schedule to ensure that you meet the required RPO of each application.
Sizing remote storage arrays
The next storage configuration consideration for Site Recovery Manager, regardless of your replication method, is the size and performance needed for the array at the recovery site. First, determine which VMs will need to be failed over for both long- and short-term disasters. To save money, VMs with long RPOs (longer than a month) may be recovered off tape-based backups by loading them onto additional storage that you acquire after the failover occurs. This recovery approach allows organizations to hold off on buying storage for test and development environments that they won’t need during short outages. At this point, you can calculate the capacity you need for the recovery array by adding up the disk space required by VMs, but make sure to size for growth.
The second consideration for sizing the recovery array is to evaluate the performance needed during a failover. If most applications need the same level of performance that they had at the protected site, the recovery array will need to support the same number of I/O operations per second. If performance is less of a concern during a disaster, then you could utilize fewer disks or slower disks in the recovery array as a potential cost saving measure.
Once an organization makes these decisions, it should have a solid storage infrastructure on which to build a VMware Site Recovery Manager-based disaster recovery solution.