Google PCA: 可靠性、灾难恢复与业务连续性 — 学习指南
属于 Google Professional Cloud Architect — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.
概述
可靠性、灾难恢复 (DR) 和业务连续性确保服务在发生组件、可用区或区域性故障时，仍能持续满足既定目标。在 Google Cloud 上，可靠性是通过理解故障域（可用区级、区域级和全球级）、定义恢复目标 (RTO/RPO)、选择弹性服务架构（例如，双活）以及严格测试恢复计划来设计的。您的设计必须将服务的关键性映射到明确的可用性目标、持久性保证和经过验证的恢复路径，同时平衡可用性、一致性、成本和运维复杂性。关键主题包括隔离单点故障、尽可能使用托管复制、自动化故障切换决策，以及在类生产环境中持续验证假设是否成立。
故障域、位置和多区域服务
- 可用区和区域：
- 可用区是区域内独立的故障域。可用区级故障是您设计时需要应对的最常见的大规模事件。
- 区域是由低延迟链路连接的多个可用区的集合。区域性故障较为罕见，但对于高关键性系统必须予以考虑。
- 设计模式：
- 区域内：通过区域级托管实例组 (MIG) 将无状态计算资源部署在至少两个可用区。
- 跨区域：为无法容忍区域性损失的关键服务复制状态并进行流量故障切换。
- 多区域和全球服务：
- 全球控制平面：VPC 网络、Cloud DNS、全球外部 HTTP(S) 负载均衡和 Cloud IAM 是用于减少区域耦合的全球范围服务。
- 数据平面的位置至关重要：
- Cloud Storage：根据访问模式和 DR 需求，选择区域级、双区域或多区域存储桶。
- BigQuery：数据集位于单个区域或多区域；多区域可提高分析服务的可用性，但需考虑数据驻留和外部联接的出口流量问题。
- Spanner：实例配置（区域级或多区域级）定义了副本拓扑和一致性行为。
- 故障域分析：
- 将每个组件映射到其爆炸半径。例如：
- 可用区级：单个 VM、可用区级 GKE 节点池、可用区级 SSD PD。
- 区域级：Cloud SQL HA 的主备实例是区域性的；某些维护事件可能会影响整个区域。
- 全球级：配置错误的 IAM 或 Cloud DNS 会影响所有区域。
- 识别相关性故障，例如共享依赖项（例如，一个 NAT 网关、一个 Memorystore 实例）或人为风险（共享的服务账号、单一的 Terraform 状态）。
- 将配额视为故障域；如果自动扩缩器达到区域配额上限，功能上等同于宕机。
- 将每个组件映射到其爆炸半径。例如：
权衡取舍：
- 跨可用区复制可减少停机时间，但会增加跨可用区流量和成本。
- 跨区域设计可降低 RTO，但会增加延迟、复杂性和开销。
- 全球任播负载均衡简化了故障切换，但只有在健康检查足够精确时才能屏蔽不健康的后端。
目标、依赖关系映射和 DR 验证
- RTO 和 RPO：
- 恢复时间目标 (RTO)：恢复服务的目标时间。它决定了自动化深度、备用资源状态和运行手册的详细程度。
- 恢复点目标 (RPO)：可接受的数据丢失窗口。它决定了复制和备份的策略与频率。
- 服务关键性与分级：
- 定义服务级别（例如，Tier 0：影响安全/财务；Tier 1：影响收入；Tier 2：内部工具），并为每个级别设定目标 SLO、RTO/RPO 和测试频率。
- 将开销和复杂性与服务级别挂钩；并非所有服务都需要跨区域部署。
- 依赖关系映射：
- 盘点上游和下游依赖项：身份（Cloud IAM、SAML IdP）、密钥（Secret Manager、KMS）、网络（DNS、Cloud Interconnect/VPN）、存储和数据库、可观测性、CI/CD 以及第三方 API。
- 为每个依赖项记录其所在区域、可用区和 SLA；为薄弱环节定义补偿性控制措施。
- 恢复计划：
- 为故障切换/故障恢复、数据恢复和配置提升（DNS、负载均衡器后端、防火墙）创建运行手册和自动化流程。
- 预先配置权限和服务账号；准备好基础设施定义，以消除手动门控环节。
- 保留可审计的紧急访问权限（break-glass access）。
- 恢复测试：
- 为有状态系统（例如 Cloud SQL HA）安排例行故障切换，以验证主实例提升和连接重新协商的过程。
- 进行故障演练（game days），模拟可用区或区域性中断；演练应包括上游提供商以及 IAM/KMS 故障场景。
- 使用故障注入来验证熔断器、超时和重试机制；验证自动扩缩和背压机制是否按预期工作。
- 在测试期间持续测量 RTO/RPO；当未达到目标时，调整架构。
弹性计算、数据库和存储模式
- 使用区域级 MIG 和负载均衡实现自愈计算：
- 使用区域级 MIG 将实例分布到多个可用区，并启用自动扩缩和自动修复功能。
- 前端使用全局外部 HTTP(S) 负载均衡器，并配置与真实就绪状态一致的后端服务健康检查（例如，/healthz 检查依赖项）。
- 允许健康检查流量通过防火墙，以避免虚拟机不断重启：
gcloud compute firewall-rules create allow-lb-health-checks \
--network=prod-vpc --action=ALLOW --direction=INGRESS \
--rules=tcp:80,tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=web-backend
```
- 避免本地状态；将 Session 外部化到 Memorystore 或数据库中；在后端启用连接排空，以在缩容期间保留进行中的请求。
- 常见故障模式：健康检查不匹配（检查过多或过少）、缺少防火墙规则，以及引导过程依赖于不健康的下游服务。
- Cloud SQL 的弹性设计：
- 高可用性：主实例和备用实例位于不同可用区，通过同步磁盘复制和自动故障切换实现；选择维护窗口并测试故障切换。
- 只读副本：添加同区域或跨区域的只读副本以分流读取负载，并降低区域性事件的 RTO；在灾难恢复 (DR) 期间提升副本。
- 备份和时间点恢复 (PITR)：
- 通过二进制/事务日志启用每日自动备份和时间点恢复 (PITR)，并设置足够的保留期以满足合规性和 RPO 要求。
- 在非生产环境中验证恢复操作，并演练副本提升流程及应用程序连接字符串的更新。
- 网络：生产环境优先使用私有 IP；确保故障切换测试能验证 DNS 和连接池的行为。
- 运维提示：定期执行受控的故障切换，以验证应用程序连接池能够干净地重新连接。
gcloud sql instances failover prod-sql
```
- Spanner 的配置与弹性：
- 区域级实例使用 Paxos 协议跨可用区提供区域内的低延迟、强一致性读/写。
- 多区域实例通过同步法定人数写入（实现全球强一致性）在多个区域间复制数据，并提供可选的只读副本；选择靠近写入者的领导者区域。
- 权衡：多区域配置能改善 RTO/RPO 和读取可用性，但会增加写入延迟和成本。适用于需要强一致性的全球分布式、写入密集型工作负载；否则，请考虑使用区域级 Spanner 或带副本的 Cloud SQL。
- Cloud Storage 的持久性和恢复模式：
- 位置策略：区域级适用于计算本地性，双区域适用于跨两个区域的主-主架构，多区域适用于为全球用户提供广泛可用性。
- 版本控制：启用对象版本控制以从删除或损坏中恢复；结合生命周期规则来管理成本。
- 保留策略：应用存储桶级别的保留政策，并在需要时为满足合规性要求应用保留锁定；使用基于事件的保留以进行记录管理。
- 备份模式：使用跨项目、独立管理员的存储桶来降低意外删除和权限升级的风险。对于数据库，将逻辑备份导出到另一个项目中的 Cloud Storage。
- 删除超过 90 天的旧版本对象的生命周期规则示例：
{
"rule": [
{
"action": { "type": "Delete" },
"condition": { "age": 90, "isLive": false }
}
]
}
```
使用以下命令应用：
gsutil lifecycle set lifecycle.json gs://prod-backups
```
- 恢复：维护关键对象的目录并测试恢复操作；对于大型数据集，将恢复操作分阶段到临时存储桶中，以避免名称冲突并验证完整性。
流量管理、多站点策略与持续弹性
- 多站点策略：
- 主-主 (Active-active)：同时从多个区域提供流量；需要对称的数据复制和无冲突写入。RTO/RPO 最佳；成本和复杂性最高。
- 主-备 (Active-passive)：一个活跃的主站点和一个就绪的备用站点；数据持续复制，故障时切换流量。在成本和 RTO 之间取得了良好平衡。
- 温备 (Warm standby)：一个缩减规模、已预同步数据的备用站点；故障切换时需要扩容；RTO 和成本中等。
- 引导灯 (Pilot light)：仅复制最关键的数据和基础设施定义；大部分组件在故障切换时才进行置备；RTO 较长，稳定状态成本低。
- 冷备 (Cold standby)：仅有定期备份；故障时进行数据恢复；RTO 最长，成本最低。
- DNS 和流量管理故障切换：
- 优先使用全球外部 HTTP(S) 负载均衡器在第 7 层进行基于健康的路由。它会对每个后端执行健康检查，并将流量从不健康的可用区或区域移开，无需更改 DNS。
- 仅将低 TTL 的 DNS 记录用作粗粒度的故障切换控制，或用于在不相交的负载均衡器 VIP 之间切换；要理解 DNS 缓存意味着故障切换不是瞬时的。
- 对于私有服务，使用内部 HTTP(S) 负载均衡及其区域性故障切换模式，并结合可在需要时以编程方式更新的私有 DNS。
- 优雅降级模式：
- 实施功能标志，以便在压力下禁用非关键功能。
- 使用熔断器、超时、带抖动的重试和舱壁隔离来局部化故障。
- 当写入路径受损时，提供只读模式；将写入操作排入队列以便后续协调处理。
- 对客户端进行速率限制并施加反压，以防止级联故障。
- 混沌测试与持续改进：
- 在网络层（延迟、丢包）和应用层进行故障注入，以验证弹性控制措施是否按设计触发。
- 演练日 (Game days) 使跨团队的恢复流程操作化；包括告警、操作手册执行以及包含具体纠正措施的事后复盘。
- 跟踪错误预算和 SLO；根据数据情况调整容量、重试策略和复制配置。
- 在可用性、一致性、成本和复杂性之间的权衡：
- 可用性 vs. 一致性：强全局一致性（例如，多区域 Spanner）可能会增加写入延迟；最终一致性（例如，异步副本）可能会改善延迟，但有读取到陈旧数据的风险。
- 成本 vs. RTO/RPO：双区域存储和多区域数据库会增加开销，但能最大限度地减少数据丢失和停机时间。
- 复杂性 vs. 可靠性：每个故障切换机制、复制流和路由规则都必须进行操作和测试；设计应保持满足目标所需的最低复杂度。
实际问题场景
Acme Tickets 是一家快速发展的在线票务公司，必须确保其购买 API 和活动目录在区域性中断期间能够持续运营，同时满足严格的 RTO/RPO 要求（RTO ≤ 5 分钟，RPO ≤ 1 分钟）。其技术栈包括无状态微服务、一个关系型订单数据库、一个分析管道和静态媒体资产。
- 定义服务层级、SLO 和恢复目标
- 理由：将购买 API 和订单数据库划分为 Tier 0（RTO 5分钟，RPO 1分钟），将目录划分为 Tier 1（RTO 15分钟，RPO 5分钟），将分析系统划分为 Tier 2（尽力而为）。这使得成本和复杂性与业务影响相匹配。
- 选择区域部署和多站点策略
- 理由：为无状态服务在 us-central1 和 us-east1 之间部署主-主 (active-active) 模式以最小化 RTO；为订单数据库使用主-备 (active-passive) 模式以平衡写入延迟和成本。
- 实施区域 MIG 和全球 HTTP(S) 负载均衡
- 理由：部署两个区域 MIG（每个区域一个），每个 MIG 至少跨越两个可用区。一个单一的全球任播 VIP 通过经过健康检查的后端服务来路由流量，自动将流量从不健康的区域切走。
- 外部化状态并配置自我修复
- 理由：将会话存储在 Memorystore 中，并为目录配置跨区域只读副本，同时保持服务无状态，以便 MIG 的自动修复和滚动更新是安全的。健康检查指向 /healthz，该端点会验证关键的下游依赖。
- 置备带高可用性 (HA) 和跨区域只读副本的 Cloud SQL for PostgreSQL
- 理由：在主区域使用 HA 以实现可用区级弹性，并启用具有足够保留期的 PITR。在备用区域创建一个跨区域只读副本，并准备一个经过测试的操作手册，以便在区域故障时将其提升为主实例，从而在最小化写入丢失的情况下满足 RPO ≤ 1 分钟的要求。
- 安排常规的数据库故障切换测试
- 理由：每月运行受控的故障切换，以验证应用程序的重连行为和副本提升流程。这解决了在真实事件中副本从未被成功提升这一常见的故障模式。
- 将静态媒体放置在启用版本控制和保留策略的双区域 Cloud Storage 存储桶中
- 理由：双区域可确保对象在两个区域间的可用性；版本控制可防止意外覆盖/删除。应用生命周期规则来过期旧版本并控制成本。
- 使用防火墙和配额保护健康检查和出口流量
- 理由：为负载均衡器的健康检查创建明确的防火墙规则，并监控区域实例配额，以防止自动扩缩容器在故障切换期间停滞。
- 将 DNS 作为一种具有低 TTL 的粗粒度控制手段
- 理由：虽然全球负载均衡器处理基于健康的路由，但仍应维护一个指向备用 VIP 的低 TTL A 记录，用于紧急手动切换，同时要理解 DNS 缓存的限制。
- 自动化灾备操作手册并通过演练日进行验证
- 理由：在每季度的演练日中，使用 Cloud Scheduler 触发合成流量，并利用 Cloud Monitoring SLO 来确认在注入故障（例如，阻止区域间流量、终止节点）时的行为。捕获 RTO/RPO 指标并优化流程。
- 保护并分离备份
- 理由：将订单数据库的每日逻辑备份导出到一个带有保留锁定的、位于独立项目中的 Cloud Storage 存储桶；定期恢复到预演实例以验证其完整性和恢复耗时。
- 实施优雅降级
- 理由：如果订单数据库性能下降，将目录切换为只读模式，将写入操作排入队列以便后续协调处理，并削减非关键功能。这可以防止级联故障并维持部分服务可用。
该架构为无状态服务提供了自动化的区域故障切换，为有状态组件提供了受控且经过测试的故障切换，以及满足 Acme Tickets 业务连续性目标的、经过验证的恢复流程。
← 安全、合规性与数据保护架构 · 所有领域 · 迁移、现代化与混合云策略 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →