Google ACE: 可靠性、备份和灾难恢复 — 学习指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

属于 Google Associate Cloud Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Google Cloud 上的可靠性、备份和灾难恢复需要在故障域、数据保护机制、流量管理和运维准备方面进行周密的设计。本节将说明如何在可用区和区域之间构建服务，如何保护和恢复有状态数据，以及如何通过规范的运行手册和持续的弹性测试来验证恢复目标。本节还将概述灾难恢复 (DR) 策略的权衡取舍和容量规划，以确保平台能够在定义的恢复时间目标 (RTO) 和恢复点目标 (RPO) 内恢复。

故障域和区域设计

可用区、区域和多区域服务
- 可用区是最小的独立故障域。单个可用区的故障不应中断区域级服务。
- 区域将多个独立的可用区通过低延迟链路组合在一起。区域级设计可以承受可用区故障，但不一定能承受整个区域的事件。
- 多区域服务跨区域复制数据，可以防止区域性损失，但成本更高，且可能带来更高的写入延迟。
- 设计原则：在您关注的最小故障域中避免单点故障。如果您的 RTO/RPO 要求能够承受可用区故障，则应至少跨两个可用区进行部署。为了实现区域级的生存能力，应在多个区域中部署活动组件或使用多区域服务。
Managed instance groups (MIG) 和自我修复
- 首选区域级 MIG，以便将实例分布在同一区域内的多个可用区。这可以在无需额外工具的情况下缓解可用区中断造成的影响。
- 负载均衡器的健康检查会将不健康的虚拟机从流量中移除。MIG 的自动修复功能会替换不健康或无响应的虚拟机。两者应结合使用。
- 使用应用级的 HTTP(S) 健康检查来验证就绪端点和依赖项。TCP 检查只能验证端口的可达性。
- 自动修复的错误配置故障模式：如果仅使用负载均衡器的健康检查，虽然可以阻止流量流向故障实例，但不会重新创建该实例。应为 MIG 本身配置健康检查以实现实例替换，并设置初始延迟以避免在实例启动期间过早重启。

示例：

创建一个应用健康检查，间隔为 10 秒，不健康阈值为 3 次，这样大约在 30 秒后会触发自我修复： gcloud compute health-checks create http hc-app
–check-interval=10s –timeout=5s
–unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz
将健康检查附加到区域级 MIG 以实现自动修复： gcloud compute instance-groups managed update my-rmig
–region=us-central1 –health-check=hc-app –initial-delay=60
多区域注意事项
- Global external HTTP(S) Load Balancing 支持位于多个区域的后端，并可根据健康检查自动进行故障切换。
- 跨区域的状态同步是关键的权衡点。双活 (Active-active) 模式的吞吐量高，但必须精心设计一致性和冲突解决方案。主备 (Active-passive) 模式更简单，但故障切换速度较慢，且可能导致更大的 RPO。

数据保护：数据库、存储和计算

Cloud SQL 高可用性与副本
- 高可用性配置将备用实例放置在不同可用区，并采用同步复制。主实例发生故障时会自动进行故障切换。RTO 通常为几分钟；在区域内 RPO ≈ 0，但需考虑正在处理的事务。
- 读取副本用于分流读取负载，并且可以跨区域部署以实现灾难恢复 (DR)。它们是异步的；预计会有复制延迟和非零的 RPO。
- 备份和 PITR
  - 启用自动备份和时间点恢复 (PITR)。对于 MySQL，启用二进制日志；对于 PostgreSQL，启用 PITR 保留。
  - 恢复流程：对于数据损坏或用户错误，将数据恢复到指定时间点的新实例，将应用程序或副本指向恢复后的实例，并验证数据。
- 故障模式与权衡
  - 高可用性 (HA) 无法防止逻辑数据损坏，但备份和 PITR 可以。
  - 跨区域副本可以防止区域性故障，但可能存在延迟；请测试您可接受的 RPO。

示例：

启用二进制日志 (MySQL) 和自动备份： gcloud sql instances patch my-mysql
–enable-bin-log
–backup-start-time=03:00 –retained-backups=7
Persistent disk (PD) 快照和机器映像
- PD 快照是磁盘的增量、崩溃一致性备份。它们的存储位置可配置，并可用于在快照位置范围内的任何可用区创建新磁盘。
- 为实现应用一致性备份，请静默文件系统和应用程序，或将快照与特定于数据库的备份机制相协调。
- 机器映像会捕获磁盘和实例元数据（启动磁盘、挂载的磁盘、实例属性）。使用机器映像可以更快地恢复实例集群或克隆黄金服务器配置。
- 快照时间表策略可自动执行备份、强制执行保留策略；请相应地为关键磁盘添加标签。
- 恢复工作流：从快照创建磁盘，将其挂载到新实例，更新启动脚本和服务账号，然后在重新引入流量之前验证应用程序的完整性。

示例：

创建快照并恢复到新磁盘： gcloud compute disks snapshot vm-boot –snapshot-names=boot-2024-09-01 gcloud compute disks create restored-boot –source-snapshot=boot-2024-09-01 –zone=us-central1-a
Cloud Storage 复制、版本控制和保留策略
- 存储类别选择：Standard 用于热数据；Nearline 用于每月不频繁访问；Coldline 用于每季度访问（推荐用于备份和灾难恢复）；Archive 用于长期、极少访问的数据。
- 区域、双区域和多区域存储桶通过复制提供持久性。具有 Turbo Replication 的双区域可以缩短新写入对象的复制 RPO；多区域提供广泛的地理弹性。
- 对象版本控制通过保留非当前版本来防止意外删除和覆盖。与保留策略和存储桶锁定结合使用，以强制执行 WORM（一次写入，多次读取）保留。
- 防止意外删除的保护措施：启用对象版本控制，使用带锁定的保留策略，为法律或处理关卡实施基于事件的保留，通过 IAM 和统一存储桶级访问权限限制删除操作。对于有时间限制的外部访问，请使用具有严格过期时间的签名 URL。

示例生命周期，在 90 天后移至 Coldline 并在 365 天后删除：

lifecycle.json { “rule”: [ { “action”: { “type”: “SetStorageClass”, “storageClass”: “COLDLINE” }, “condition”: { “age”: 90 } }, { “action”: { “type”: “Delete” }, “condition”: { “age”: 365 } } ] }
应用： gsutil lifecycle set lifecycle.json gs://my-bucket

流量、容量和依赖项弹性

DNS 和流量管理故障切换
- 对于面向互联网的服务，首选全球外部 HTTP(S) 负载均衡；它使用任播 IP，并跨区域执行基于健康检查的故障切换。
- 对于私有服务，使用内部 HTTP(S) 或 TCP/UDP 负载均衡器。通过多个后端实现可用区独立性设计。
- DNS TTL 权衡：低 TTL 可以加快故障切换速度，但会增加查询负载，并且由于缓存行为可能被某些解析器忽略。
- 基于健康检查的负载均衡器故障切换比纯 DNS 故障切换更快、更具确定性。
- 加权或故障切换 DNS 策略可以作为区域疏散的最后手段控制平面，但依赖于缓存过期。
容量规划和配额设计
- 确定每个可用区和区域的最低健康容量。为故障切换应用余量缓冲区（“N+1 可用区”容量）。
- 为关键的 Compute Engine 实例类型使用区域级预留，以保证在扩缩容事件或故障切换期间的容量。
- 预先配置 IP 地址、转发规则、Cloud NAT 容量、连接跟踪和 SSL 证书，以避免恢复期间的控制平面延迟。
- 在需要之前尽早申请增加配额；验证备用区域以及所有依赖项的配额（例如，每个区域的 Cloud SQL 实例数、每个 VPC 的转发规则数、Pub/Sub 吞吐量、Cloud KMS QPS）。
- 自动扩缩容注意事项：配置冷却期，如果需要可使用预测性自动扩缩容，并设置最小/最大边界以在策略要求时精确保留一个实例。
依赖项弹性
- 盘点上游和下游服务。为每个服务定义故障行为和回退策略：缓存配置、降级模式、熔断器、带死信主题的队列以及背压。
- 在恢复区域验证 IAM 和服务账号的范围。角色缺失通常会在灾难恢复 (DR) 事件中导致静默失败。
- 加密密钥：确保 Cloud KMS 密钥副本或多区域密钥与数据位置保持一致。规划备用区域的密钥环位置和 IAM。

弹性运营与持续改进

RTO、RPO、恢复计划和运行手册
- RTO (恢复时间目标) 定义了服务必须多快恢复；RPO (恢复点目标) 定义了可接受的数据丢失量。这些指标应通过业务影响分析得出。
- 将每个系统组件映射到满足 RTO/RPO 的特定机制：使用 HA 应对可用区级故障，使用跨区域复制应对区域级故障，使用备份应对数据损坏，使用存储类别/复制策略保障持久性。
- 维护运行手册 (runbook)：包含精确的步骤、命令、凭证访问方式、健康状况验证检查和决策树。将其存储在有版本控制和访问控制的代码库中，并定期演练。
- 恢复验证：安排演练以衡量实际的 RTO/RPO，验证数据完整性，并收集改进措施。测试应包括小范围恢复（如表、磁盘）和全站恢复。
灾难恢复 (DR) 策略与权衡
- 双活 (Active-active)：所有区域都提供流量服务；如果数据同步设计得当，可实现最小的 RTO 和较低的 RPO。复杂度与成本较高；需要冲突解决机制和全局负载均衡。
- 主备 (Active-passive)：主区域处于活动状态；备用区域为温备状态，接收复制的数据。成本适中；RTO 为数分钟到数十分钟；RPO 不为零，具体取决于复制延迟。
- 引导灯 (Pilot-light)：在备用区域运行最少的核心服务（如数据库复制、最小化的应用实例）。RTO 为数小时；成本效益高；故障切换期间需要精心的编排来扩展计算资源。
- 冷备 (Cold-standby)：基础设施以代码形式定义，但未预置。RTO 为数天；成本最低；存在因配置漂移、配额和容量稀缺等意外情况带来的风险。
混沌测试与故障模拟
- 定期模拟实例崩溃、进程挂起、健康检查失败、磁盘写满和依赖项中断等情况。使用工具或脚本终止实例、阻止到后端的出口流量，或在代理层注入延迟。
- 通过故意让健康检查端点失败来验证 MIG 的自动修复和 LB 的实例移除功能。确认替换行为和恢复时间线。
- 演练区域疏散：排空一个区域中的后端服务，观察全局负载均衡器的故障切换，并验证备用区域中的有状态依赖项。
- 持续改进：在测试期间记录平均检测时间 (MTTD)、故障切换时间和数据丢失等指标。优先修复那些能降低 RTO/RPO 和减少手动步骤的问题。

实际问题场景

Brightlane Retail 在 us-central1 运营一个电子商务平台，对可用性有严格要求，且订单数据的 RPO 为四小时。管理层要求能够在可用区中断时无停机，在区域中断时对客户影响最小。

方法：

部署区域级 MIG，配置 HTTP 自动修复和全局 HTTP(S) 负载均衡器
- 理由：区域级 MIG 将实例分布在多个可用区，而应用级的 HTTP 健康检查能在连续 3 次（每次 10 秒）检查失败后触发自我修复。全局负载均衡器会自动移除不健康的虚拟机，并将流量故障切换到健康的可用区。
- 命令： gcloud compute health-checks create http app-hc –check-interval=10s –timeout=5s –unhealthy-threshold=3 –request-path=/healthz gcloud compute instance-groups managed update web-rmig –region=us-central1 –health-check=app-hc –initial-delay=60
启用 Cloud SQL HA，配置跨区域只读副本和 PITR
- 理由：区域级 HA (高可用性) 通过自动故障切换提供可用区级别的生存能力。在 us-east1 中的只读副本提供了区域级灾难恢复能力，其 RPO 不为零但有界。启用 PITR（对 MySQL 而言即启用二进制日志）允许恢复到特定时间点，以解决逻辑数据损坏问题。
- 命令： gcloud sql instances patch orders-mysql –enable-bin-log –backup-start-time=03:00 gcloud sql instances create orders-replica –master-instance-name=orders-mysql –region=us-east1
使用双区域 Cloud Storage 和生命周期策略保护对象资产
- 理由：产品图片和静态资产存储在双区域存储桶中，以实现区域级弹性。生命周期转换规则将较旧的工件移动到 Coldline 以优化成本，而版本控制和保留策略可防止关键资产被意外删除。
- 步骤：启用对象版本控制，为关键存储桶设置 30 天的保留策略，并应用生命周期规则，将非关键的构建工件在 90 天后转换到 Coldline，并在一年后删除。
为有状态服务安排 PD 快照并创建机器映像
- 理由：虚拟机磁盘的增量快照提供了快速的崩溃一致性恢复选项。机器映像捕获启动和配置信息，以在区域故障切换期间加速应用服务器的重建。快照时间表确保了基于策略的一致性备份。
- 命令： gcloud compute resource-policies create snapshot-schedule daily-2am –max-retention-days=14 –on-source-disk-delete=apply-retention-policy –start-time=02:00 gcloud compute disks add-resource-policies app-disk-1 –resource-policies=daily-2am gcloud compute machine-images create app-mi-2024-09-01 –source-instance=app-vm-template
定义 RTO/RPO 并将 DR 运行手册和 IaC 代码化
- 理由：为 Web/API 服务设置 15 分钟的 RTO，为订单数据设置 4 小时的 RPO。运行手册详细说明了流量故障切换流程、Cloud SQL 只读副本的提升、DNS 应急预案以及验证步骤。基础设施即代码 (IaC)（如 Terraform/Deployment Manager）可确保确定性的重建过程并减少手动错误。
在备用区域预配容量和配额
- 理由：为关键的虚拟机规格创建预留，预先配置备用负载均衡器后端、SSL 证书、NAT 容量，并验证 us-east1 中 Compute、SQL、转发规则和 KMS 的配额。这可以防止在故障切换期间因容量不足而导致失败。
通过混沌演练验证恢复能力并记录改进点
- 理由：每季度进行可用区故障演练，以验证 MIG 和 LB 的行为；每半年进行区域疏散演练，将 us-east1 中的只读副本提升为主实例，将全局 LB 指向 us-east1 的后端，并衡量 RTO/RPO。演练的发现将推动改进，例如减少手动步骤或增加副本容量。