We want to talk about synchronous disk replication. Regional Persistent Disk and Hyperdisk Balanced High Availability volumes are designed for workloads that require a lower Recovery Point Objective (RPO) and Recovery Time Objective (RTO). To learn more about RPO and RTO, see Basics of disaster recovery planning. This document provides an overview of how to build HA services with Regional Persistent Disk and Hyperdisk Balanced High Availability volumes.
When you decide to use Regional Persistent Disk or Hyperdisk Balanced High Availability, make sure that you compare the different options for increasing service availability and the cost, performance, and resiliency for different service architectures.
About Synchronous Disk Replication
A Regional Persistent Disk or Hyperdisk Balanced High Availability (Preview) volume, also referred to as a replicated disk, has a primary and a secondary zone within its region where it stores disk data. Compute Engine maintains replicas of your disk in both these zones. When you write data to your disk, Compute Engine synchronously replicates that data to the disk replicas in both zones to ensure HA. The data of each zonal replica is spread across multiple physical machines within the zone to ensure durability. Zonal replicas ensure that the data of the disk remains available and provide protection against temporary outages in one of the disk zones.
Replica State for Zonal Replicas
Disk replica state for Regional Persistent Disk or Hyperdisk Balanced High Availability (Preview) shows you the state of a zonal replica in comparison to the content of the disk. Zonal replicas for your disks are in one of the following disk replica states at all times:
Synced: Both replicas are up-to-date.
Catching up: One replica is not fully updated.
Degraded: One replica is significantly out-of-date.
To learn how to check and track the replica states of your zonal replicas, see Monitor the disk replica states.
Replication States for Synchronously Replicated Disks
Depending on the state of the individual zonal replicas, your Regional Persistent Disk or Hyperdisk Balanced High Availability (Preview) volume can be in one of the following replication states:
Fully replicated: Both replicas are in sync.
Catching up: One replica is being updated.
Degraded: One replica is significantly out-of-date.
If the disk replication status is catching up or degraded, then one of the zonal replicas is not updated with all the data. Any outage during this time in the zone of the healthy replica results in an unavailability of the disk until the healthy replica zone is restored. Google recommends that you wait for the affected zonal replica to catch up with the data on the disk, at which point its status changes to Synced.
Replica Recovery Checkpoint
A replica recovery checkpoint is a disk attribute that represents the most recent crash-consistent point in time of a fully replicated disk. Compute Engine automatically creates and maintains a single replica recovery checkpoint for each replicated disk. When a disk is fully replicated, Compute Engine keeps refreshing its checkpoint approximately every 10 minutes to ensure that the checkpoint remains updated.
In rare scenarios, when your disk is degraded, the zonal replica that is synced with the latest disk data can also fail before the out-of-sync replica catches up. You won't be able to force-attach your disk to compute instances in either zone. Your replicated disk becomes unavailable and you must migrate the data to a new disk. In such scenarios, if you don't have any existing standard snapshots available for your disk, you might still be able to recover your disk data from the incomplete replica by using a standard snapshot created from the replica recovery checkpoint.
Replicated Disk Failover
In the event of an outage in a zone, the zone becomes inaccessible and the compute instance in that zone can't perform read or write operations on its disk. To allow the instance to keep performing read and write operations for the replicated disk, Compute Engine allows migration of disk data to the other zone where the disk has a replica. This process is called failover.
The failover process involves detaching the zonal replica from the instance in the affected zone and then attaching the zonal replica to a new instance in the secondary zone. Compute Engine synchronously replicates the data on your disk to the secondary zone to ensure a quick failover in case of a single replica failure.
Failover by Application-Specific Regional Control Plane
The application-specific regional control plane is not a Google Cloud service. When you design HA service architectures, you must build your own application-specific regional control plane. This application control plane decides which instance must have the replicated disk attached and which instance is the current primary instance. When a failure is detected in the primary instance or database of the replicated disk, the application-specific regional control plane of your HA service architecture can automatically initiate failover to the standby instance in the secondary zone.
Failover by Force-Attach
One of the benefits of Regional Persistent Disk and Hyperdisk Balanced High Availability (Preview) is that in the unlikely event of a zonal outage, you can manually failover your workload to another zone. When the original zone has an outage, you can't complete the disk detach operation until that zonal replica is restored. In this scenario, you might need to attach the secondary zonal replica to a new compute instance without detaching the primary zonal replica from your primary instance. This process is called force-attach.
Compute Engine executes the force-attach operation in less than one minute. The total recovery time objective (RTO) depends not only on the storage failover (the force attachment of the replicated disk), but also on other factors, including the following:
Network latency
Instance startup time
Application recovery time
For more information about how to failover your compute instance using force-attach, see Failover your replicated disk using force-attach.
Limitations
The following sections list the limitations that apply for Regional Persistent Disk and Hyperdisk Balanced High Availability (Preview).
General Limitations for Replicated Disks
You can attach regional Persistent Disk only to VMs that use E2, N1, N2, and N2D machine types.
You can attach Hyperdisk Balanced High Availability only to supported machine types.
You cannot create a regional Persistent Disk from an image, or from a disk that was created from an image.
When using read-only mode, you can attach a regional balanced Persistent Disk to a maximum of 10 VM instances.
The minimum size of a regional standard Persistent Disk is 200 GiB.
You can only increase the size of a regional Persistent Disk or Hyperdisk Balanced High Availability volume; you can't decrease its size.
Limitations for Replica Recovery Checkpoints
A replica recovery checkpoint is part of the device metadata and doesn't show you any disk data by itself. You can only use the checkpoint as a mechanism to create a snapshot of your degraded disk. After you create the snapshot by using the checkpoint, you can use the snapshot to restore your data.
You can create snapshots from a replica recovery checkpoint only when your disk is degraded.
Compute Engine refreshes the replica recovery checkpoint of your disk only when the disk is fully replicated.
Compute Engine maintains only one replica recovery checkpoint for a disk and only maintains the latest version of that checkpoint.
You can't view the exact creation and refresh timestamps of a replica recovery checkpoint.
You can create a snapshot from your replica recovery checkpoint only by using the Compute Engine API.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License.For details, see the Google Developers Site Policies.
Remember these 3 key ideas for your startup:
High Availability (HA) and Disaster Recovery: Implementing Regional Persistent Disk and Hyperdisk Balanced High Availability volumes ensures that your data is synchronously replicated across multiple zones, providing robust protection against temporary outages and ensuring data durability. This is crucial for maintaining business continuity and minimizing downtime.
Failover Mechanisms: Utilize failover strategies such as application-specific regional control planes and force-attach processes to ensure that your applications can continue to operate seamlessly in the event of a zonal outage. This flexibility allows you to maintain service availability and meet your Recovery Time Objectives (RTO).
Cost and Performance Considerations: While implementing these high-availability solutions, it's essential to balance the cost, performance, and resiliency of your service architectures. Regularly monitor the state of your disk replicas and be prepared to take snapshots or create new disks to maintain data integrity and meet your Recovery Point Objectives (RPO).
Edworking is the best and smartest decision for SMEs and startups to be more productive. Edworking is a FREE superapp of productivity that includes all you need for work powered by AI in the same superapp, connecting Task Management, Docs, Chat, Videocall, and File Management. Save money today by not paying for Slack, Trello, Dropbox, Zoom, and Notion.
For more details, see the original source.
