A VM can be protected as part of a group of associated VMs known as a Recovery Group (RG) or by itself independently. When protected as an RG, all VMs within the group are replicated and recovered to a single consistent point in time. For independent VMs, all attached disks are replicated and recovered together to the same consistent point in time, preserving data integrity within the VM.

To ensure consistent recovery, AROVA uses a single Consistency Group. This mandates that all disks of a VM be either zonal or regional, and they all reside within the same zone (for zonal disks) or the same pair of zones (for regional disks). The same requirement applies to every VM and disk within an RG. AROVA automatically validates these conditions when VM protection is initiated or when a new disk is attached. The following types of VM protection are supported:

    • Cross-project protection and recovery of VMs.
    • VMs with disk types:
      • Balanced Persistent Disk
      • Performance (SSD) Persistent Disk
      • Hyperdisk Balanced
      • Hyperdisk Extreme
      • Hyperdisk Balanced High Availability (If multiple VMs have the same Hyperdisk Balanced or Hyperdisk Balanced High Availability disk attached in multi-writer mode, only one of the VMs can be protected.)
    • VMs configured with zonal or regional disks.
    • VMs with disks configured using CMEK encryption.
    • VM instances configured with CMEK encryption.
    • VMs configured with zonal or global DNS.

Make sure all VM disks meet the requirements listed in the Google Asynchronous Replication guide. https://cloud.google.com/compute/docs/disks/async-pd/configure#disk_requirements

Considerations for VM Protection

    • VMs using local SSD cannot be protected.
    • A disk's snapshot schedule will not be preserved after VM recovery.
    • If a primary VM's machine type is not supported on the secondary region, a warning will be issued before starting VM protection. If the user chooses to continue with protection they will be given the option to update the VM’s properties to set a valid machine type before performing failover.
    • If a primary VM has a specific reservation configured but no reservation was configured for it in the runbook, it will be restored in the secondary region using its existing reservation.
    • If a primary VM has sole-tenancy configured, its properties will have to be updated and a corresponding node-group set before failover can be performed.
    • All disks of an independent protected VM will be assigned to a Consistency Group and all disks of VMs under the same Recovery Group will be grouped together in a Consistency Group. Limitations for assigning disks to Consistency Groups are described in this article https://cloud.google.com/compute/docs/disks/async-pd/manage-consistency-groups#limitations.

Note: It is possible for protection requests to be rejected for various reasons. For example, if a user attempts to start protection for a VM under a Recovery Group and AROVA detects the Consistency Group already contains its maximum number of allowed disks or the VM’s disks do not match the corresponding RG’s disks zones or scope, protection will not be allowed.

Follow the links below to learn more about protecting VMs.

See:

Protected Domain

Recovery Group

Protecting VMs with Disk Encryption

Protecting Independent VMs

Monitoring Protection

Managing Protected Domain and VM Protection

Run-time VM Configuration Changes