Asynchronous Replication provides low recovery point objective(RPO) andlow recovery time objective(RTO) blockstorage replication for cross-region active-passive disaster recovery (DR).

Asynchronous Replication is a storage option that provides asynchronous replicationof data between two regions. In the unlikely event of a regional outage,Asynchronous Replication lets you failover your data to a secondary region andrestart your workload in that region.

You can use Asynchronous Replication to manage replication for Compute Engineworkloads at the infrastructure-level, instead of the workload-level.

Overview

Asynchronous Replication replicates data from a disk that is attached to a runningworkload, theprimary disk, to a separate disk located in anotherregion. The disk receiving replicated data is referred to as thesecondary disk.

The region that the primary disk is located in isreferred to as theprimary region and the region that the secondary disk islocated in is referred to as thesecondary region. The primary and secondaryregions are referred to as aregion pair.

Any disk that meets thedisk requirementscan be used as a primary disk. After you have a primary disk, you cancreate a secondary diskthat references the primary disk andstart replicationfrom the primary disk to the secondary disk.

If you stop replication from the primary disk at any point, and want to restartreplication at a later point, then you must create a new secondary disk torestart replication.

Consistency groups

Consistency groups enable you to perform DR and DR testingacross multiple disks. A consistency group is a resource policy that does thefollowing:

• Aligns replication across primary disks and ensures that all disks containreplication data from a common point in time, which is used for DR.
• Aligns disk clones from secondary disks and ensures that all disk clonescontain data from a common point in time, which is used for DR drills.

If you want to align the replication period across multiple disks, add primarydisks to a consistency group. If you want to clone multiple disksand ensure those clones have data from a common point in time, add secondarydisks to a consistency group. A consistency group can be used forreplication or cloning, but not both simultaneously.

If you want to add primary disks to a consistency group, you mustadd disks to the consistency groupbefore you start replication. You can add secondary disks to a consistency groupat any time.

Failover and failback

In the event of an outage in the primary region, it is your responsibilityto identify the outage and failover restart your workload using the secondarydisks, in the secondary region. Asynchronous Replication doesn'toffer outage monitoring. You can identify an outage usingRPO metrics,health checks,application-specific metrics, and by contacting Cloud Customer Care.

Thefailover processinvolves the following tasks:

1. Stop replication.
2. Attach the secondary disks to VMs in the secondary region.

After you failover disks, it is your responsibility to validate and restart yourapplication workload in the secondary region and reconfigure the networkaddresses that are used to access your application to point to the secondary region.

Following a failover from the primary region to the secondary region, thesecondary region becomes the acting primary region. After the outage or disastergets resolved, you can initiate failback to start replication from theoriginal secondary region (the acting primary region) to the original primaryregion. You can optionally repeat the process to move the workload back to theoriginal primary region.

Thefailback process involves the following tasks:

1. Configure replication between the new primary region and the originalprimary region.

   • The original secondary disk is now the new primary disk, and you configureit to replicate to a new secondary disk in the original primary region.
   • You can create a new consistency group resource policy in the new primaryregion so that the new primary disks (the original secondary disks) canreplicate consistently to a new set of secondary disks in the originalprimary region.

2. (Optional) After the initial replication has occurred, you can repeat thefailover process to return the workload to the original primary region.

Disk encryption

Primary and secondary disks don't support customer-supplied encryption keys(CSEK). UseGoogle-owned and Google-managed encryption keys orcustomer-managed encryption keys (CMEK)instead. If you use CMEK on the primary disk, you must also use CMEK on thesecondary disk. You can use different CMEKs on both disks.

Customize a secondary disk

When you create a secondary disk, Compute Engine automatically copiesthe properties of the primary disk to the secondary disk. You can change certainproperties of the secondary disk so that they differ from the primary disk. Forexample, the primary and secondary disk must have the same size and encryptionkey, but you might assign additional labels to the secondary disk.

If the primary disk is a boot disk, the secondary disk is created with the bootconfiguration of the primary disk. The boot configuration includes informationabout the OS architecture, OS licenses, and its guest OS features.

For boot disks, you can enable additionalsecurity or networking options on the secondary disk by specifying additionalguest OS features. However, you can't remove any of the primary disk's guest OSfeatures. Compute Engine merges the new features you specify with theexisting guest OS features of the primary disk.

For more information on how to customize a secondary disk, seeCreate a custom secondary disk.

Example

Suppose you have a boot disk calleddisk-1, with the followingguest OS features:[GVNIC, UEFI_COMPATIBLE].

If you create a secondary disk fromdisk-1, you can only specify additionalfeatures. You can't remove theUEFI_COMPATIBLE andGVNIC features.So, if you specifyMULTI_IP_SUBNET when you create the secondary disk,the new feature is merged with those of the primary disk, so the resultingguest OS features for the secondary disk are[GVNIC,UEFI_COMPATIBLE, andMULTI_IP_SUBNET].

Modify a primary disk

After you create the secondary disk, you might want to modify the properties ofthe primary disk. For someproperties, if you make a change on the primary disk, Compute Engineautomatically updates the property on the secondary disk.

Compute Engine monitors and automatically updates the followingproperties:

• Access mode (Hyperdisk only)
• Disk size
• Provisioned IOPS and throughput (Hyperdisk only)
• Replication status

If you modify any other properties of the primary disk, youmust manually update the secondary disk.

• To learn how to modify the properties of a Hyperdisk volume,seeModify a Hyperdisk.
• To learn how to modify the properties of a Persistent Disk, seeModify a Persistent Disk.

Asynchronous Replication and regional disks

You can use Asynchronous Replication withregional disks to achieve highavailability (HA) and DR.

Regional persistent disks can be used as the primary or secondary diskin a Asynchronous Replication disk pair. A disk pair is a primary disk thatreplicates to a secondary disk.

When using a regional disk as the primary disk, replication remains uninterrupted evenif one of its zones experiences an outage. The regional primary disk continues replicatingdata from the healthy zone to the secondary disk. Similarly, when a regional diskserves as a secondary disk, replication persists despite an outage in one of itszones. Using a regional disk as a secondary disk prepares your workload for highavailability across zones in the event of a failover, where the secondary disktransitions to become the new primary disk.

Limitations

• Asynchronous Replication is supported only for the followingdisk types:
  • Balanced Persistent Disk
  • Performance (SSD) Persistent Disk
  • Hyperdisk Balanced
  • Hyperdisk Balanced High Availability
  • Hyperdisk Extreme
• Read-only disks aren't supported.
• Multi-writer disks are supported only for Hyperdisk Balanced and Hyperdisk Balanced High Availability.
• Not all changes to Hyperdisk properties automaticallyapply to the secondary disk. For more information on which propertiesautomatically apply to the secondary disk, seeSecondary disk customization.
• Each disk can have a maximum size of 64 TiB.
• You must stop replication before you can delete a primary or secondary disk.
• If replication is ongoing for a VM's boot disk, then you can't delete the VM untilyou stop replication.
• If a primary disk is attached to a VM as a non-boot disk,and the disk is configured to be deleted with the VM, you can't deletethe VM or the disk until you stop replication or detach the primary disk fromthe VM. Attempts to delete the VM will fail until you stop replication.

• Each project can have at most 1000 disk pairsin each region pair.

  For example, a given project,project-1 can have up to1000 disk pairs in the Iowa-Oregon regionpair.project-1 can also have up to 1000disk pairs in the Belgium-Frankfurt region pair.

Supported regions

Asynchronous Replication is available in all regions in the following continents:

• Asia, except Indonesia
• Europe
• North America
• Oceania
• South America

You can replicate a primary disk in a given region to a secondary disk in anyavailable region within the same continent. This means that you can create a region pairfrom any two regions within the same continent.

For example, suppose you have a primary disk in Frankfurt (europe-west3).You can replicate that disk to a secondary disk anywhere in Europe,but you can't replicate it to a region in North America.

For a full list of all regions in Compute Engine, seeAvailable zones and regions.

Performance

The recovery point objective(RPO), or the time delay for when data is available at the secondary site,depends on disk change rates. Asynchronous Replication typically replicates data witha target RPO of one minute, for up to 12.5 GB ofcompressed changed blocks per minute withdisk blocks replicated with 4 KB block granularity. If a given block ischanged multiple times between replication events, only the most recent changeis replicated to the secondary disk. At higher disk change rates, RPO may begreater than one minute and typically increases as disk change rates grow. RPOis not configurable.

RPO might exceed one minute in the following scenarios:

• When disk replication starts. During the initial replication,Asynchronous Replication replicates all the used blocks on the primary disk to thesecondary disk. The initial replication is complete when thedisk/async_replication/time_since_last_replication metricis available in Cloud Monitoring.
• If the disk change rate is greater than12.5 GB of compressed changedblocks per minute. After a spike in disk changes, the RPO for laterreplication cycles might exceed one minute while replication catches up.
• If you detach a disk from a VM or restart a VM while the disk isreplicating. Disks that are undergoing replication that are detached from aVM might see RPO increase up to five minutes for a short period of time.

To learn how to view the RPO for your disks, seeAsynchronous Replication performance metrics.

The recovery time objective (RTO) duringfailoverdepends on the time it takes to complete the various tasks involved in failingover your workload to a new region. Tasks such as stopping replication andattaching disks to VMs in the secondary region should take only a few minutes tocomplete. You can speed up RTO by ensuring that you have VMs running in the secondaryregion so that if failover occurs, you don't have to wait for VMs to start up.

What's next

• Learn how toconfigure replication.
• Learn how tomanage replication.
• Learn how tomanage consistency groups.
• Learn how tofailover and failback.
• Learn how tomanage disks that use Asynchronous Replication.
• Learn how toMonitor Asynchronous Replication performance.