Important business decisions for VMware SRM: RTO and RPO

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

    Requires Free Membership to View

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.

This was first published in May 2011

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.