Before deciding on a disaster recovery strategy for an ISV application deployment, customers must have a business continuity plan. This plan is unique for a given business, and it should specify the metrics of recovery point objective (RPO) and recovery time objective (RTO). RPO refers to the amount of data you can afford to lose before business operations are impacted. RTO is the timeframe in which the application and systems must be restored after an outage. Both RPO and RTO are typically determined by negotiating a service level agreement (SLA) with the business.

Recovering from a disaster is generally accomplished by using alternative production sites or cloud services. These alternate locations may operate in an active/active or active/passive fashion. A VxRail ISV application deployment provides multiple data protection options for every level of protection. The Dynamic Resource Scheduling (DRS) and High Availability (HA) features of VxRail protect all components of the application stack, without complicated database or application-level cluster configurations.

If such a configuration is desired, application-level clusters can be configured. Such a configuration involves additional components and load balancers to create a clustered multisite environment. Beyond the integrated VxRail HA/DR configuration, the following options are available for a more robust disaster recovery solution.

A vSAN stretched cluster is a deployment model in which two or more ESXi host servers are part of the same logical cluster but are in separate geographical locations. The vSAN stretched cluster feature enables synchronous replication of data between sites, which allows a complete site failure to be tolerated. Stretched clusters extend the concept of fault domains to data center awareness domains.

Both server virtualization and vSAN are managed from a single vCenter Server platform. This single interface is used to enable capabilities such as Distributed Resource Scheduler (DRS). DRS is highly recommended when using stretched cluster functionality on VxRail. It provides the initial placement and migration of the VMs in accordance with the host and VM affinity rules.

Stretched clusters are deployed across two sites in an active/active configuration. Each stretched cluster must include one witness host. The witness must reside on a third site with independent paths to each data site. All three sites share the same vCenter, but the witness must not be on the same cluster as the data site hosts. Fault domains provide the core functionality of a vSAN stretched cluster. A fault domain consists of one or more vSAN hosts, grouped according to their physical location in the data center. The maximum number of fault domains in a vSAN stretched cluster is three. The first fault domain is referred to as the preferred site, the second is the secondary site, and the third fault domain is the witness host site. The witness host may be a VM or a physical host. This host monitors the datastore availability and makes decisions when the network connection between the two data sites is lost. The network latency between the two data sites must not exceed 5 milliseconds. The latency between the data sites and the witness site depends on the number of objects in the vSAN stretched cluster, however it must be less than or equal to 100 milliseconds. The following figure shows a basic stretched cluster deployment:

VMware Site Recovery Manager (SRM) is a dedicated disaster recovery and site migration solution. SRM is an extension to VMware vCenter that provides automated replication and supports policy-based management. It works with various replication solutions, including VMware vSphere Replication, to automate the process of migrating, recovering, and failing-back VM workloads. SRM coordinates the operations of vCenter Server at two sites. This allows the VMs at the recovery site to start up when the VMs of the protected site shut down.

Because the data is replicated between the two sites, the VMs at the recovery site assume responsibility and provide the same services as the protected site. SRM enables the testing of recovery plans without disrupting operations at either site. This is important, as multiple recovery plans can be configured and tested to determine what the final solution will look like, all with no interruption to operation at the production site.

VMware SRM is deployed in a paired configuration that includes a protected site and a recovery site. The SRM software appliance is deployed at both sites. A vCenter Server instance is required at both sites.

Requirements for SRM installation include the following:

• Install the same version of Platform Services Controller (PSC), vCenter Server, vSphere Replication, and Site Recovery Manager on the protected site and recovery site.
• Use Fully Qualified Domain Names (FQDN), rather than IP addresses, when you install and configure Platform Services Controller, vCenter Server, vSphere Replication, and Site Recovery Manager. Make Forward and Reverse DNS records for all the components.
• Use centralized Network Time Protocol (NTP) servers to synchronize the clock settings of the systems on all components.
• Site Recovery Manager requires a database. SRM can be installed either with an Embedded PostgreSQL Database or an external database source such as Microsoft SQL or Oracle.
• Obtain a Windows user account with the appropriate privileges to install and run SRM service.
• Obtain the vCenter Single Sign-On administrator username and password for both the protected site and recovery site.

The following figure shows a basic SRM deployment:

Thanks to VMware integration, VxRail includes integrated data protection capabilities. RecoverPoint for Virtual Machines (RP4VMs) provides continuous data protection for backup and disaster recovery. VM protection is available for single or multiple VMs, both locally and remotely. RP4VMs is a software-only data replication option that integrates with VMware vCenter. RP4VMs is managed directly from vCenter Server. It provides synchronous replication between sites, and its local replication capability makes it useful for testing and development environments. Replicated copies or snapshots can be repurposed for both short and long-term backup use cases. RP4VMs can also be used for cloud disaster recovery solutions. It is storage agnostic, so complete VxRail clusters can be replicated to cloud server providers.

A virtual RecoverPoint Appliance (vRPA) is installed in each vSphere cluster environment. The appliance manages all aspects of the data replication process. It uses IP protocol to communicate with the vSphere datastore. The vSphere Web Client is used to protect and recover VMs to any point in time with integrated orchestration and automation capabilities. The RP4VMs system consists of the following components:

• One or more RP4VMs clusters.
• A minimum of one virtual vRPA (maximum of eight) per RP4VMs cluster.
• An RP4VMs splitter is installed on every VMware ESXi host in the vSphere cluster that hosts the protected VMs. The splitter splits the writes coming from the hosts and sends them to the vRPA and the VMDK for the VM.
• The VMware vSphere Web Client plug-in manages the RP4VMs system. vSphere 6.7 U1 and later use an HTML 5 plug-in. Older releases used the vSphere Flex plug-in. The Flex plug-in is deprecated with 6.7 and above releases. The HTML5 plug-in is a dedicated server that provides replication management for one or more RP4VMs systems. Communication is handled using REST API.

The following figure shows the RP4VMs system architecture with the vSphere HTML5 plug-in:

(Source: Dell Integrated Data Protection Product Guide)

VMware vSphere Replication provides asynchronous replication for VMs. It comes fully integrated with vCenter Server and the vSphere Web Client. vSphere Replication provides local data protection, but it can also be used for disaster recovery between sites if some data loss can be tolerated. It can be combined with VxRail Site Recovery Manager (SRM) to provide automated failover and failback to minimize downtime.

For more information about VxRail availability solutions, see the Unmatched Availability Solution for VxRail article.