From 5021bf44b9554fb0184c4e2825da558ebd84aa1e Mon Sep 17 00:00:00 2001 From: Laiba Zaman Date: Wed, 22 Mar 2023 14:07:01 +0000 Subject: [PATCH 1/5] fixed title --- en/google/compute/persistent-disks-auto-delete.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/google/compute/persistent-disks-auto-delete.md b/en/google/compute/persistent-disks-auto-delete.md index 849a05bd4..f452168e7 100644 --- a/en/google/compute/persistent-disks-auto-delete.md +++ b/en/google/compute/persistent-disks-auto-delete.md @@ -1,12 +1,12 @@ [![CloudSploit](https://cloudsploit.com/img/logo-new-big-text-100.png "CloudSploit")](https://cloudsploit.com) -# GOOGLE / Compute / Persistent Disk Auto Delete +# GOOGLE / Compute / Persistent Disks Auto Delete ## Quick Info | | | |-|-| -| **Plugin Title** | Persistent Disk Auto Delete | +| **Plugin Title** | Persistent Disks Auto Delete | | **Cloud** | GOOGLE | | **Category** | Compute | | **Description** | Automatically delete read/write zonal persistent disks when the associated VM instance is deleted | From e933735dfbb112454fa7443de1163266f03d28eb Mon Sep 17 00:00:00 2001 From: Laiba Zaman Date: Thu, 23 Mar 2023 14:03:01 +0000 Subject: [PATCH 2/5] new rem guide --- en/google/compute/disk-multiaz.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 en/google/compute/disk-multiaz.md diff --git a/en/google/compute/disk-multiaz.md b/en/google/compute/disk-multiaz.md new file mode 100644 index 000000000..9d0784533 --- /dev/null +++ b/en/google/compute/disk-multiaz.md @@ -0,0 +1,31 @@ +[![CloudSploit](https://cloudsploit.com/img/logo-new-big-text-100.png "CloudSploit")](https://cloudsploit.com) + +# GOOGLE / Compute / Disk MultiAz + +## Quick Info + +| | | +|-|-| +| **Plugin Title** | Disk MultiAz | +| **Cloud** | GOOGLE | +| **Category** | Compute | +| **Description** | Building HA database services using regional persistent disks | +| **More Info** | You can use regional persistent disks (PDs) to build high availability (HA) services. | +| **GOOGLE Link** | https://cloud.google.com/compute/docs/disks/high-availability-regional-persistent-disk | +| **Recommended Action** | Build HA solutions for stateful database services. | + +## Detailed Remediation Steps +This section covers high level concepts for building HA solutions for stateful database services (MySQL, Postgres, etc.) using regional persistent disks and Compute Engine. + +If there are broad outages in Google Cloud, for example, if a whole region becomes unavailable, your application might become unavailable. Depending on your needs, consider [cross-regional replication techniques](https://cloud.google.com/architecture/disaster-recovery#how_to_leverage_zones_and_regions_to_achieve_reliability) for even higher availability. + +Database HA configurations typically have at least two VM instances. Preferably these instances are part of one or more [managed instance groups](https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances): + +- A primary VM instance in the primary zone +- A standby VM instance in a secondary zone + +A primary VM instance has at least two persistent disks: a boot disk, and a regional persistent disk. The regional persistent disk contains database data and any other mutable data that should be preserved to another zone in case of an outage. + +A standby VM instance requires a separate boot disk to be able to recover from configuration-related outages, which could result from an operating system upgrade, for example. You cannot force attach a boot disk to another VM during a failover. + +The primary and standby VM instances are configured to use a load balancer with the traffic directed to the primary VM based on health check signals. This configuration is also known as a hot standby. The [disaster recovery scenario for data](https://cloud.google.com/solutions/dr-scenarios-for-data) outlines other failover configurations, which might be more appropriate for your scenario. \ No newline at end of file From b8628744744ea4aff452ee2f8232281d981375ea Mon Sep 17 00:00:00 2001 From: Amanda Reed <96201528+areed42@users.noreply.github.com> Date: Fri, 24 Mar 2023 10:08:29 -0400 Subject: [PATCH 3/5] Delete persistent-disks-auto-delete.md --- .../compute/persistent-disks-auto-delete.md | 30 ------------------- 1 file changed, 30 deletions(-) delete mode 100644 en/google/compute/persistent-disks-auto-delete.md diff --git a/en/google/compute/persistent-disks-auto-delete.md b/en/google/compute/persistent-disks-auto-delete.md deleted file mode 100644 index f452168e7..000000000 --- a/en/google/compute/persistent-disks-auto-delete.md +++ /dev/null @@ -1,30 +0,0 @@ -[![CloudSploit](https://cloudsploit.com/img/logo-new-big-text-100.png "CloudSploit")](https://cloudsploit.com) - -# GOOGLE / Compute / Persistent Disks Auto Delete - -## Quick Info - -| | | -|-|-| -| **Plugin Title** | Persistent Disks Auto Delete | -| **Cloud** | GOOGLE | -| **Category** | Compute | -| **Description** | Automatically delete read/write zonal persistent disks when the associated VM instance is deleted | -| **More Info** | This behavior is controlled by the autoDelete property on the VM instance for a given attached zonal persistent disk and can be updated at any time. | -| **GOOGLE Link** | https://cloud.google.com/compute/docs/disks | -| **Recommended Action** | Set the auto-delete state of a zonal persistent disk. | - -## Detailed Remediation Steps -1. In the Google Cloud console, go to the VM instances page. - - [Go to VM instances](https://console.cloud.google.com/compute/instances) - -2. Select the instance that has the disks associated with it. - -3. Click the instance name. The VM instance details page appears. - -4. Click Edit. - -5. In the Storage section, under the heading Additional disks, click the pencil icon mode_edit to change the disk's Deletion Rule. - -6. Click Save to update your instance. \ No newline at end of file From a28f0e8c9d5262775eb9c1817ca084a95d216fef Mon Sep 17 00:00:00 2001 From: laiba-zaman <122311250+laiba-zaman@users.noreply.github.com> Date: Tue, 28 Mar 2023 10:28:21 -0400 Subject: [PATCH 4/5] Update disk-multiaz.md --- en/google/compute/disk-multiaz.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/en/google/compute/disk-multiaz.md b/en/google/compute/disk-multiaz.md index 9d0784533..cb17131a8 100644 --- a/en/google/compute/disk-multiaz.md +++ b/en/google/compute/disk-multiaz.md @@ -9,23 +9,21 @@ | **Plugin Title** | Disk MultiAz | | **Cloud** | GOOGLE | | **Category** | Compute | -| **Description** | Building HA database services using regional persistent disks | -| **More Info** | You can use regional persistent disks (PDs) to build high availability (HA) services. | +| **Description** |Ensure that Compute disks have regional disk replication feature enabled for high availability.| +| **More Info** | Enabling regional disk replication will allow you to force attach a regional persistent disk to another VM instance in a different zone in the same region in case of a zonal outage. | | **GOOGLE Link** | https://cloud.google.com/compute/docs/disks/high-availability-regional-persistent-disk | -| **Recommended Action** | Build HA solutions for stateful database services. | +| **Recommended Action** | Ensure that all Google compute disks have replica zones configured. | ## Detailed Remediation Steps -This section covers high level concepts for building HA solutions for stateful database services (MySQL, Postgres, etc.) using regional persistent disks and Compute Engine. +For synchronous and asynchronous application replication: -If there are broad outages in Google Cloud, for example, if a whole region becomes unavailable, your application might become unavailable. Depending on your needs, consider [cross-regional replication techniques](https://cloud.google.com/architecture/disaster-recovery#how_to_leverage_zones_and_regions_to_achieve_reliability) for even higher availability. +- Use two instances of the database and VM. In this case the following items determine the total cost: -Database HA configurations typically have at least two VM instances. Preferably these instances are part of one or more [managed instance groups](https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances): + - VM instance costs + - Persistent disk costs + - Costs of maintaining application replication +- Use a single VM with regional persistent disks. To achieve high availability with a regional persistent disk, use the same VM instance and persistent disk components, but also include a regional persistent disk. Regional persistent disks are double the cost per byte compared to zonal persistent disks because they are replicated in two zones. -- A primary VM instance in the primary zone -- A standby VM instance in a secondary zone + However, using regional persistent disks might reduce your maintenance cost because the data is automatically replicated to two replicas without the requirement of maintaining application replication. -A primary VM instance has at least two persistent disks: a boot disk, and a regional persistent disk. The regional persistent disk contains database data and any other mutable data that should be preserved to another zone in case of an outage. - -A standby VM instance requires a separate boot disk to be able to recover from configuration-related outages, which could result from an operating system upgrade, for example. You cannot force attach a boot disk to another VM during a failover. - -The primary and standby VM instances are configured to use a load balancer with the traffic directed to the primary VM based on health check signals. This configuration is also known as a hot standby. The [disaster recovery scenario for data](https://cloud.google.com/solutions/dr-scenarios-for-data) outlines other failover configurations, which might be more appropriate for your scenario. \ No newline at end of file +- Do not start the second VM until failover is required. You can reduce host costs even more by starting the back-up VM only on demand during failover rather than maintaining the VM as a hot standby. From cb5fde2a3668e51ca66ae04f5941bc0b29d01250 Mon Sep 17 00:00:00 2001 From: laiba-zaman <122311250+laiba-zaman@users.noreply.github.com> Date: Tue, 4 Apr 2023 14:47:08 -0400 Subject: [PATCH 5/5] Update disk-multiaz.md --- en/google/compute/disk-multiaz.md | 33 +++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/en/google/compute/disk-multiaz.md b/en/google/compute/disk-multiaz.md index cb17131a8..3999542cf 100644 --- a/en/google/compute/disk-multiaz.md +++ b/en/google/compute/disk-multiaz.md @@ -15,15 +15,32 @@ | **Recommended Action** | Ensure that all Google compute disks have replica zones configured. | ## Detailed Remediation Steps -For synchronous and asynchronous application replication: +You must first create the regional Persistent Disk and then attach it to an existing instance. You can't create regional Persistent Disks as boot disks because they can't be force-attached during a failover. -- Use two instances of the database and VM. In this case the following items determine the total cost: +Create a regional Persistent Disk using the following steps: - - VM instance costs - - Persistent disk costs - - Costs of maintaining application replication -- Use a single VM with regional persistent disks. To achieve high availability with a regional persistent disk, use the same VM instance and persistent disk components, but also include a regional persistent disk. Regional persistent disks are double the cost per byte compared to zonal persistent disks because they are replicated in two zones. +1. In the Google Cloud console, go to the Disks page. - However, using regional persistent disks might reduce your maintenance cost because the data is automatically replicated to two replicas without the requirement of maintaining application replication. + [Go to Disks](https://console.cloud.google.com/compute/disks) -- Do not start the second VM until failover is required. You can reduce host costs even more by starting the back-up VM only on demand during failover rather than maintaining the VM as a hot standby. +2. Select the required project. + +3. Click Create disk. + +4. Specify a Name for your disk. + +5. Select the Region and Zone. You must select the same region when you create your VM. + +6. Select the Enable regional disk replication box. + +7. Select the Replicate zone. Make a note of the zones that you select because you must attach the disk to your VM in one of those zones. + +8. Select the Disk source type. + +9. Select the Disk type. + +10. Click Create to finish creating your disk. + +11. After you create your regional Persistent Disk, [attach it to your instance](https://cloud.google.com/compute/docs/disks/add-persistent-disk#create_disk). + + When attaching a disk to a VM, if the disk is already attached to another VM, you can force-attach the disk to the VM by selecting the Force-attach disk box on the Attach existing disk page. For more information on use cases for force-attaching regional Persistent Disks, see [Regional Persistent Disk failover](https://cloud.google.com/compute/docs/disks/repd-failover).