The business decisions for VMware vCenter Site Recovery Manager (SRM) are usually more complex than the technical components. In fact, much of the technical configuration is highly dependent on the business decisions made, at least in part, outside of IT.
Many business-driven SRM design elements are standard disaster-recovery planning decisions, which include the designation of mission-critical servers and how long to keep backups. Unfortunately, some of these VMware SRM business decisions involve internal politics, difficult compromises and meticulous planning.
Recovery time objective for VMware SRM
The recovery time objective (RTO) is the duration of time in which a system must be restored after a disaster. This variable determines the order in which virtual machines (VMs) are powered on during a VMware SRM Recovery Plan. SRM makes the technical aspects of VM prioritization very easy. But until a business lays out the proper order, the IT team can only guess which VMs need to be recovered first.
Once the business has determined the overall system's RTO, IT must translate that information into RTOs for specific servers. Most business systems are comprised of multiple servers with many dependencies. A company, for example, may not define RTOs for domain controllers or antivirus management systems, but every server in the infrastructure probably has a dependency on them in some way. It's the job of the SRM implementation team to make sure these servers are prioritized properly.
Recovery point objective
Another business decision is the recovery point objective (RPO), which defines the acceptable amount of data loss for a system, measured in time, after a disaster. Traditionally, RPO also determines how frequently servers are backed up. But when applied to an SRM implementation, RPO determines the frequency of replication between the arrays in the primary and recovery sites.
Before designing the VM data stores and storage replication, one important business decision is defining the RPO for each application. Virtualization administrators can then group servers with similar RPOs onto the same set of storage volumes, and they can configure the proper replication schedule for each volume based on the common RPO. Be aware that, when introducing VMware SRM into an existing vSphere infrastructure, this process may require a storage redesign and migrations.
Don't have RTOs or RPOs?
If your organization doesn't have regular disaster-recovery planning exercises to define the RTOs and RPOs for all your systems, then prepare for a long process. Defining RTOs and RPOs can be time-consuming, because it incorporates internal politics, technical limitations, personnel decisions and system-interaction diagrams.
It is equally important to maintain these RTO and RPO definitions and communicate regularly with the business side of your organization to keep updated on any changes to system priorities. The VMware SRM and storage administrators must have the proper time to reflect these changes on their end.
It's paramount that IT and business units work together throughout the VMware SRM design process to ensure a smooth and reliable implementation.