Microsoft AZ-305: 高可用性、灾难恢复与业务连续性 — 学习指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

属于 Microsoft Azure Solutions Architect Expert AZ-305 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

在 Azure 中实现高可用性 (HA)、灾难恢复 (DR) 和业务连续性 (BC) 需要跨计算、数据和网络层进行精心设计。弹性始于明确的恢复时间目标 (RTO) 和恢复点目标 (RPO)，然后将平台功能——可用区、全局路由、数据复制、备份和故障转移编排——组合成经过测试的自动化策略。Azure 提供区域和地区级别的故障隔离、基于 DNS 和任播 (anycast) 的全局分发、多区域数据持久性以及策略驱动的备份/恢复，旨在满足严苛目标的同时，控制成本和运营复杂性。

由 RTO/RPO 驱动的架构以及区域/全局弹性

设计始于 RTO 和 RPO。RTO 决定了服务在故障后必须多快恢复；RPO 决定了可接受的最大数据丢失量。满足低 RTO 需要自动故障转移和预先预配的容量；满足低 RPO 需要同步或近同步复制以及频繁的一致性恢复点。

可用区是区域内独立的数据中心故障域。区域性服务（例如，Virtual Machines、托管磁盘、Standard 公共 IP）固定在单个区域。区域冗余服务（例如，Azure Load Balancer Standard 区域冗余前端、区域冗余存储产品和区域冗余 Azure SQL 层）自动跨越多个区域。一个典型的弹性模式是在至少两个区域中部署区域性 VM，将它们放置在单个虚拟网络中，并公开一个区域冗余的负载均衡前端。这消除了单区域故障作为停机原因的可能性。

在全局边缘，可以在基于 DNS 和基于任播代理的负载分发之间进行选择：

• Azure Traffic Manager 是基于 DNS 的。它使用多种路由方法将客户端定向到终结点：性能（最低延迟）、权重（A/B 测试和渐进式流量转移）、优先级（主动/被动故障转移）、地理位置（从区域合规的终结点为用户提供服务）、多值（为简单客户端返回多个健康的 IPv4/IPv6 记录）和子网（将客户端 IP 范围映射到特定终结点）。由于它是基于 DNS 的，Traffic Manager 不会加速内容或代理流量；客户端直接连接到所选终结点，并遵循本地 DNS 缓存行为。
• Azure Front Door (Standard/Premium) 是一个全局任播 HTTP/HTTPS 反向代理，具有智能路由、TLS 卸载和集成的 Web 应用程序防火墙 (WAF)。路由规则根据域、路径、方法和标头进行匹配，然后路由到源组；规则引擎操作可以重写 URL/标头并强制执行重定向。健康探测通过可配置的路径和协议持续评估源的健康状况；不健康的源会从轮换中移除。源组支持跨区域的优先级（主动/被动）和加权分发。WAF 策略附加在终结点或路由上，通过托管规则集、自定义规则和速率限制来缓解 OWASP 威胁和恶意客户端。当您需要具有加速、边缘安全和应用程序感知故障转移的全局负载均衡时，请使用 Front Door；仅当您需要非 HTTP 终结点或 DNS 级别的控制时，才将其与 Traffic Manager 结合使用。

在第 4 层，Azure Load Balancer 为 TCP/UDP 提供超低延迟的负载分发。Standard Load Balancer 支持区域性和区域冗余前端、HA 端口、出站规则和默认安全行为（需要显式的 NSG 和后端池配置）。健康探测（TCP/HTTP）确定后端健康状况；发生故障时会将实例从轮换中移除。Basic Load Balancer 缺乏区域感知、高级功能和 SLA——应避免在生产环境中使用。Cross-region Load Balancer 增加了一个全局任播前端，可在区域性 Standard 负载均衡器之间进行均衡，从而为非 HTTP 工作负载实现主-主多区域设计，并根据健康状况提供快速的区域性故障转移。

综合实践：满足特定的恢复目标

根据 RTO/RPO 和故障域，将每个层级映射到其连续性机制：

• 区域内可用性：使用 Availability Zones。将可用区计算资源部署到至少两个可用区；使用区域冗余前端（Standard Load Balancer、具有区域冗余的 Application Gateway v2 或位于边缘的 Front Door）。在支持的情况下启用 SQL 区域冗余，并对需要可用区和区域双重弹性的存储使用 GZRS。
• 跨区域灾难恢复 (DR)：对于有状态层，优先选择原生异地复制（SQL 自动故障转移组、Cosmos DB 多区域帐户、Storage GRS/GZRS）以实现低 RPO。对于有状态的 IaaS 或没有原生复制功能的工作负载，使用 Azure Site Recovery 及精心调整的复制策略和恢复计划。对于临时计算资源，使用基础设施即代码 (Infrastructure as Code) 从镜像或 VM Scale Sets 中重新构建。
• 全球路由和故障转移：对于 HTTP/S，Azure Front Door 提供由健康探测驱动的应用感知故障转移和 WAF 保护。对于非 HTTP 或混合协议，酌情添加 Traffic Manager (DNS) 或 Cross-region Load Balancer (L4 任播)。对严格的主动/被动 RTO 目标使用优先级路由；对分阶段部署使用加权路由；为实现最低延迟的用户体验使用性能路由。
• 备份作为最后一道防线：即使有复制机制，也要保留 Azure Backup，其保留策略需满足合规性要求，启用软删除以防止清除事件，并为使用异地冗余存储的保管库配置跨区域还原。备份可以防范逻辑损坏、勒索软件和操作员错误——这些风险可能会通过复制机制传播。

测试是必须执行的环节。安排定期的 ASR 测试故障转移，执行 Front Door/Traffic Manager 健康演练测试，在负载下验证 SQL 故障转移组的行为，并在沙箱环境中执行存储故障转移模拟。对 RTO 进行测量，并使用 Runbook 自动化回滚/故障恢复过程。编写并演练操作手册 (Runbook)，以便待命响应人员在压力下能够一致地执行操作。

实际问题场景

Expedia Group 必须对其全球旅行预订平台进行现代化改造，以满足核心预订业务 RTO ≤ 15 分钟和 RPO ≤ 5 分钟的目标，同时在重大旅行活动期间能够承受 10 倍的流量高峰。该平台为全球的 Web 和移动客户端提供服务，包含混合的 HTTP 和非 HTTP 工作负载。

1. 在主区域构建可用区弹性

• 将无状态微服务作为可用区 VM Scale Sets 部署到两个或更多 Availability Zones，并配备 Standard Load Balancer 区域冗余前端。这消除了单可用区故障风险，并确保了低延迟的区域内流量。
• 使用启用了自动故障转移组和区域冗余的 Azure SQL Database。自动故障转移组提供协调的数据库故障转移和稳定的侦听器，以最小的运维负担满足 15 分钟的 RTO 要求。
• 将会话工件和镜像存储在 GZRS 存储帐户中，以结合可用区持久性和异步区域保护。当与应用侧的幂等性结合使用时，这可以满足 5 分钟的 RPO 要求。

2. 添加具有主动/主动读取能力的跨区域灾难恢复

• 在两个配对区域中配置预订网站/API 源站，并将其置于 Azure Front Door Standard 之后。健康探测和优先级路由可根据应用健康状况实现快速故障转移，而任播 (anycast) 则可加速用户流量。带有托管规则集和速率限制的 WAF 策略可防范容量攻击和应用层攻击，这在流量高峰期间至关重要。
• 为行程和个性化服务启用 Cosmos DB 多区域写入，以降低全球用户的写入延迟并提供 99.999% 的可用性。自动故障转移会优先切换到次要区域，无需人工干预即可保持低 RTO。
• 对事务性预订在相同的两个区域使用 SQL 自动故障转移组，从而能够在辅助副本上进行读取扩展以用于报告，同时确保快速、协调的故障转移。

3. 保护状态并支持从损坏中恢复

• 如果仍有任何遗留组件，请使用 Recovery Services 保管库进行 Azure VM 备份（在支持的情况下实现应用一致性）和虚拟机内 SQL 备份。应用具有分层保留的备份策略，并启用软删除以防范意外或恶意删除。
• 对于托管专门工作负载的 Azure Disks，添加基于备份保管库的 Azure Disk Backup，以捕获独立于来宾操作系统代理的增量快照。这使恢复选项多样化。
• 在使用异地冗余存储的保管库上启用跨区域还原，允许在部分控制平面中断期间从次要区域进行数据平面还原。

4. 编排灾难恢复并验证 RTO

• 为任何非原生复制的服务（例如，遗留的 Windows 服务）配置 Azure Site Recovery。创建恢复计划，该计划按顺序安排数据库就绪、然后是 API、然后是 Web，并包含 Azure Automation Runbook 以更新 Key Vault 引用、通过 Front Door 规则清除 CDN 缓存，以及为非 HTTP 终结点切换 Traffic Manager 优先级。
• 安排季度性测试故障转移到使用脱敏数据的隔离 VNet 中，以验证 Runbook、测量实际故障转移持续时间并优化容量预留。测试后，清理工件并根据 15 分钟的 RTO 目标审查指标。

5. 混合协议的全球路由

• 对于 HTTP/S，Front Door 负责处理由健康状况驱动的故障转移和边缘安全。对于非 HTTP 协议（例如，合作伙伴的 TCP 集成），部署 Cross-region Load Balancer，并将区域性 Standard Load Balancer 作为其子终结点。健康探测会立即移除故障区域，从而在没有 DNS TTL 依赖的情况下保持连接。在需要 DNS 级别的地理围栏（如监管要求的终结点）时，可在特定区域的终结点前增加一层 Azure Traffic Manager 地理路由。

为何选择这些服务

• Availability Zones 和区域冗余前端消除了单可用区故障，且对延迟影响最小。Azure SQL 故障转移组抽象化了连接管理并自动化了故障转移，与 15 分钟的 RTO 目标保持一致。Cosmos DB 多区域写入满足了全球范围内的超高可用性和低延迟写入要求。GZRS 和 RA 选项提供了可用区加区域的双重持久性，并伴有可控的 RPO 权衡。Front Door 在边缘提供全球加速、应用感知故障转移和 WAF。Cross-region Load Balancer 和 Traffic Manager 满足了非 HTTP 和地理路由的需求。Azure Backup 和 ASR 提供了独立的恢复路径——从时间点还原到全栈故障转移——确保平台能够从基础设施故障和逻辑数据损坏中恢复。

← 网络与连接 · 所有领域 · 安全架构与零信任 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →