The Asynchronous Replication Virtual Appliance ("AROVA") is a virtual appliance used to manage disk and VM recovery from catastrophic partial zonal, zonal and regional failures. 

AROVA is a “privileged” VM running within a service project. It has elevated control over selected projects/VMs. AROVA is deployed from Google Cloud Console using instructions generated by the JetStream for GCE Disaster Recovery Orchestration Management Site portal. The following figure illustrates the AROVA design.

Figure: Architecture of AROVA.


The AROVA contains two disks: (1) a boot disk and (2) a data disk called the AROVA Configuration Disk ("ACD"). The ACD is a regional disk protected by PDAR. The ACD contains AROVA metadata (primary/secondary regions and groups of independent and dependent VMs representing virtual applications) and the properties of VMs being protected during failover and failback.

A secondary region AROVA must be deployed and used for orchestration in case of primary region failure or in the case of failure of both ACD zonal disks. If needed, an active AROVA running in either region can manage VMs running on both sites. For AROVA failover or failback, ACD content is completely sufficient for resuming orchestration.

Replication Pair ("RP") is a basic ARO concept. This is a primary-secondary pair of regions used for asynchronous replication. A single primary region may have multiple RPs. However, each RP maintains a dedicated AROVA instance running on the primary or secondary region. The following figure illustrates the RP concept. All such AROVA instances will be managed under the same Marketplace subscription.

Figure: Replication Pairs.

Each AROVA has the following hierarchy of protection components.

Figure: Component hierarchy.

Typically, a Protected Domain ("Domain") represents a multi-VM virtual application. It may or may not require cross-VM replication consistency. A Domain is a failover and failback unit. However, in case of partial or full zonal failure, the administrator may choose to split the Domain and perform failover only for a subset of VMs in the Domain. The Domains can then be merged back later. The best practice is to implement user-friendly naming conventions for such Domains (e.g., Using the original Domain name with a numeric suffix).

A Domain can contain multiple independent VMs that belong to the same virtual application but do not require cross-VMs replication consistency. Independent VMs can be stand-alone and not belong to any virtual application. All independent VM disks will be configured to reside in a single, dedicated Consistency Group ("CG"). (See: https://cloud.google.com/compute/docs/disks/async-pd/manage-consistency-groups)

A Recovery Group ("RG") contains dependent VMs that require cross-VM replication consistency. All RG disks from all VMs will be configured to participate in a single CG. The RG may have a Runbook assigned. Runbooks define VM creation, boot order and pauses between boots.

To ensure consistent recovery, AROVA uses single Consistency Groups that require all VM disks to be either zonal or regional, and they must all belong to the same single or dual zones depending upon disk type – zonal or regional. This same requirement is applicable to all RG VMs and disks. AROVA checks for this condition when starting VM protection or attaching new disks. (See: https://cloud.google.com/compute/docs/disks/async-pd/manage-consistency-groups#rest_4)

The following figure illustrates the typical data flow for VM protection (prior to any failure).

Figure: VM protection data flow.

Also see:

View: Introduction

View: Definitions, Acronyms and Abbreviations

View: Google Compute Engine and JetStream DR

View: Persistent Disk Storage Scopes and ARO