针对区域复原能力设计 Azure 工作负荷有助于保护应用程序免受硬件故障、网络中断和自然灾害的影响。 通过在区域中的多个可用性区域分配资源以实现区域复原，可以降低影响关键服务的单区域中断的风险。
在初始规划和部署工作负荷期间，区域复原能力最有效。 但是，可能尚未将许多现有工作负荷配置为支持此级别的保护。 在大多数情况下，为部署的工作负载启用区域复原非常简单，Azure 将继续改进，进一步简化该过程。 但是，由于对工作负荷的任何更改都可能会导致风险，因此必须仔细地进行规划。 评估并确定这些工作负荷中的哪些工作负载和服务对业务至关重要。 然后首先将区域复原应用到影响最大的资源。
本文概述了在 Azure 工作负荷中启用区域复原的关键注意事项。 它还有助于规划和实施成功过渡到更具弹性的体系结构。
小窍门
如果目前正在设计工作负荷或计划对当前工作负荷进行设计评审，请务必遵循 有关在 Azure Well-Architected Framework 中设计冗余的建议。 链接的文章可帮助你跨多个级别设计工作负荷冗余，重点介绍关键工作流。 为了支持可用性区域采用，Well-Architected 框架中的冗余建议指南还概述了多区域部署和部署标记等策略。
什么是区域复原能力？
Azure 服务可以通过两种主要方式实现针对可用性区域中断情况的复原能力：
区域冗余服务： 许多 Azure 服务支持 区域冗余。 这些服务会在可用性区域之间自动复制数据，分发传入请求，并在区域故障期间故障转移到不同的区域。 每项服务都以对每项服务有意义的方式支持这些功能。 默认情况下，某些服务是区域冗余的，而其他服务可能需要配置区域冗余。
区域服务： 某些 Azure 服务是 区域性服务，这意味着它们可以固定到特定的可用性区域。 若要使用区域服务实现区域复原，需要在多个可用性区域中部署服务的独立实例。 你可能还需要管理流量分布、数据复制以及实例之间的故障转移。
某些服务可以部署在区域冗余配置或区域性配置中。 在大多数情况下，最好在可以时部署区域冗余服务。
有关详细信息，请参阅 可用性区域支持类型。
区域启用过程
使用以下步骤系统地查看 Azure 工作负荷，确定区域复原优先级，并为每个组件启用区域复原能力。
先决条件
在开始之前，必须执行以下作：
标识每个工作负荷。 工作负荷是指应用程序资源、数据和支持基础结构的集合，它们协同工作以实现定义的业务成果。 有关工作负荷以及如何定义它们的详细信息，请参阅 Well-Architected 框架工作负载。
确定每个工作负荷的用户和系统流的优先级。 了解工作负荷的关键路径和依赖项对于确定哪些组件要首先进行区域复原至关重要。 有关如何使用关键流分析确定工作流优先级的详细信息，请参阅 确定工作负荷的优先级以获取区域复原能力。
为每个工作负荷和流分配重要性分级。 此分级可帮助你了解潜在中断对业务的影响，并指导你决定哪些工作负荷优先用于区域复原能力。 还应考虑重新配置工作负荷时可接受的停机时间。
可以使用简单的分类根据工作负荷的关键性对工作负荷进行分类。 此方法可帮助你将精力集中在最重要的服务上。
请考虑以下示例分类，对工作负荷进行分类。
工作负荷类型 Description 中断的影响 任务关键型 必须高度可靠、始终可用、可复原故障和可作的关键流和工作负荷 对基本功能的任何中断都会立即造成灾难性的业务损害，或给人类生命带来风险。 业务关键型 运行重要业务功能的基本流和工作负载 中断可能会造成一些财务损失或品牌损失。 业务运营 提高业务运营效率，但对客户不直接提供服务 可以容忍某些级别的中断。 行政 内部生产流和工作负载与业务运营不一致 可以容忍中断。 有关如何根据关键性分级对工作负荷进行分类的详细信息，请参阅 为每个流分配关键性分级。
验证 Azure 资源所在的区域是否位于支持可用性区域中。 请参阅 Azure 区域列表。 如果某个区域不支持可用性区域，请考虑将资源重新定位到某个区域。 有关详细信息，请参阅 跨资源组、订阅或区域移动 Azure 资源。
步骤 1：确定 Azure 服务的区域复原优先级
确定哪些工作负荷流对业务至关重要后，可以专注于这些流所依赖的 Azure 服务。 某些 Azure 服务比其他服务对应用程序更为重要。 通过确定这些服务的优先级，可以帮助确保应用程序在发生区域故障时保持可用和复原能力。
根据 Azure 服务组对工作负荷的关键性，使用以下指南确定 Azure 服务组的优先级。 确定区域复原服务优先级时，请务必考虑特定的应用程序体系结构和业务需求。
从网络服务开始。 工作负荷倾向于共享网络服务，因此其复原能力的增加可以同时提高多个工作负荷的复原能力。
许多核心网络服务都是区域冗余的，但应该专注于 Azure ExpressRoute 网关、Azure VPN 网关、Azure 应用程序网关、Azure 负载均衡器和 Azure 防火墙等组件。
作数据存储 包含多个工作负荷经常使用的宝贵数据，这意味着提高这些数据存储的可用性可以帮助许多工作负荷。
若要实现作数据存储复原，请专注于 Azure SQL 数据库、Azure SQL 托管实例、Azure 存储、Azure Data Lake Storage、Azure Cosmos DB、Azure PostgreSQL 灵活服务器、Azure MySQL 灵活服务器和 Azure Redis 缓存等服务。
计算服务通常是下一个优先级。 计算服务通常易于在区域之间复制和分发，因为它们是无状态的。
计算服务包括 Azure 虚拟机、Azure 虚拟机规模集、Azure Kubernetes 服务（AKS）、Azure 应用服务、应用服务环境、Azure Functions 和 Azure 容器应用。
查看关键流中使用的所有剩余业务关键型资源。 这些资源可能不如前面列出的资源那么重要，但它们仍然在应用程序的功能中发挥作用，应该考虑进行区域复原。
查看 其余业务运营资源 ，并做出有关是否使其具有区域弹性的明智决策。 此评审包括的服务可能不直接绑定到关键工作负荷，但仍有助于整体应用程序性能和可靠性。
步骤 2：评估区域配置方法
确定工作负荷和 Azure 服务的优先级后，请务必了解可用于为每个服务启用可用性区域支持的方法，以及如何实现区域复原配置。
每个 Azure 可靠性服务指南都提供了一个部分，介绍如何为该服务启用区域复原能力。 本部分可帮助你了解使每个服务区域具有复原能力所需的工作量，以便可以相应地规划策略。 有关特定服务的详细信息，请参阅 Azure 可靠性服务指南。
使用 区域配置表 快速了解可用于常见 Azure 服务的方法。
重要
如果工作负荷包括部署在区域（或单区域）配置中的任何组件，则必须计划使这些组件能够复原到区域中断。 常见方法是将单独的实例部署到另一个可用性区域，并根据需要在它们之间进行切换。
步骤 3：测试延迟
使工作负荷能够进行区域复原时，请务必考虑可用性区域之间的延迟。 有时，某些旧系统不能容忍跨区域流量引入的少量额外延迟，尤其是在数据层中启用同步复制时。 如果怀疑跨区域延迟可能会影响工作负荷，请确保在启用区域复原之前和之后执行测试。
Azure 服务的区域配置方法
每个 Azure 服务都提供特定类型的可用性区域支持，该支持基于服务的预期用途和内部体系结构。 如果当前有一个资源未配置为使用可用性区域（或 非区域 资源），则可能需要使用可用性区域支持重新配置它。 该服务的可靠性指南提供了指向可用性区域配置说明的指导或链接。
本部分简要概述了不同类型的区域配置方法以及每个服务支持的方法。
重要
在资源上启用 区域冗余 时，该资源会自动具有抵抗区域故障的能力。 使用 区域 配置将资源固定到特定可用区时，资源不会自动实现可用区冗余，并且你负责使其能够应对区域故障。 针对可用区服务，本文档中的信息反映了将服务固定到特定区域的复杂性和成本。 可能需要进一步的工作才能使资源区域具有复原能力，因此 有关详细信息，请参阅服务的可靠性指南 。
下表描述了每个区域配置方法，包括启用可用性区域所需的工作量级别。 该表还指示在启用过程中是否需要停机。
区域配置表列出了许多 Azure 服务支持的区域配置方法，并包含指向该服务的每个可靠性指南的链接。 可靠性指南提供有关如何配置非区域服务资源以启用可用性区域支持的信息。
| 方法 | Description | 典型工作量级别 | 可能需要停机 |
|---|---|---|---|
| 始终具有区域复原能力 | 默认情况下，该服务在支持可用性区域的区域中已具有区域复原能力。 无需执行任何操作。 | None | 否 |
| 启用 | 所需的最小配置更改，例如在设置中启用区域冗余。 在此过程中对可用性没有影响，但请注意对成本或性能产生的任何影响。 | Low | 否 |
| 修改 | 可能需要一些配置更改，例如重新部署依赖资源或修改网络设置。 | 中等 | 是的 |
| 重新部署 | 需要进行重大更改，例如重新部署整个资源、应用程序或服务，或将数据迁移到新服务。 | High | 是的 |
了解为服务启用可用性区域支持的成本影响也很重要。 对于许多服务，启用可用性区域不会产生额外的成本影响。 但是，某些服务要求部署服务的特定层，或者为服务部署一定数量的容量单位，或者同时部署这两种容量单位。 使用可用性区域时，其他服务会收取不同的费率。 下表列出了每个服务的典型成本影响。
注释
本文中的信息汇总了可用于启用可用性区域支持和典型成本影响的典型方法。 然而，可能存在一些因素会影响它对特定解决方案的作用情况。 例如，某些服务可能 始终列为区域可复原，但此指定仅适用于特定区域或服务的特定层。 可以从这些表着手，但请务必查看链接的文档以了解具体的详细信息。
按区域配置方法划分的 Azure 服务
下表总结了许多 Azure 服务的可用性区域支持，并提供一种方法，包括成本影响，可用于为该服务启用可用性区域支持。
| 服务 | 可以是区域冗余的 | 可以是区域性的 | 典型的区域配置方法 | 典型的成本影响 |
|---|---|---|---|---|
| Azure AI 搜索 |
|
始终具有区域复原能力 | N/A | |
| Azure API 管理 |
|
|
修改 | 最低所需等级 |
| Azure 应用配置 |
|
始终具有区域复原能力 | N/A | |
| Azure 应用程序服务 |
|
启用 | 所需的最低层级和实例数量 | |
| Azure 应用服务 - 应用服务环境 |
|
启用 | 所需的最少实例数量 | |
| Azure 应用程序网关 |
|
|
始终具有区域复原能力 | N/A |
| Azure 备份 |
|
重新部署 | 适度增加成本 | |
| Azure Batch |
|
重新部署 | 不会对相同数量的 VM 产生任何成本影响 | |
| Azure Blob 存储服务 |
|
启用 | 适度增加成本 | |
| Azure Cache for Redis - 企业版 |
|
重新部署 | 无成本影响 | |
| Azure Cache for Redis - 标准版和高级版 |
|
启用 | 最低所需等级 | |
| Azure 容器应用 |
|
重新部署 | 所需的最低副本数量 | |
| Azure 容器注册表 |
|
始终具有区域复原能力 | N/A | |
| 用于 NoSQL 的 Azure Cosmos DB |
|
修改 | 如果使用自动缩放或多区域写入，则为无。 | |
| Azure Data Lake Storage |
|
启用 | 适度增加成本 | |
| Azure Database for MySQL - 灵活配置服务器 |
|
重新部署 | 需要主实例和 HA 实例 | |
| Azure Database for PostgreSQL-“灵活服务器” |
|
启用 | 需要主实例和 HA 实例 | |
| Azure 磁盘存储（托管磁盘） |
|
|
启用 | 适度增加成本 |
| Azure ExpressRoute |
|
|
修改 | 取决于级别 |
| Azure 文件 |
|
启用 | 适度增加成本 | |
| Azure 防火墙 |
|
|
修改 | 无成本影响 |
| Azure Functions |
|
重新部署 | 所需的最低层级和实例数量 | |
| Azure Key Vault |
|
始终具有区域复原能力 | N/A | |
| Azure Kubernetes 服务 (AKS) |
|
重新部署 | 无成本影响 | |
| Azure 负载均衡器 |
|
|
修改 | 无成本影响 |
| Azure 逻辑应用 - 消耗层 |
|
始终具有区域复原能力 | N/A | |
| Azure 逻辑应用 - 标准层 |
|
重新部署 | 所需的最低层级和实例数量 | |
| Azure 托管 Grafana |
|
重新部署 | 适度增加成本 | |
| Azure 队列存储 |
|
启用 | 适度增加成本 | |
| Azure 服务总线 |
|
始终具有区域复原能力 | N/A | |
| Azure Service Fabric |
|
|
重新部署 | 不会对相同数量的 VM 产生任何成本影响 |
| Azure Site Recovery |
|
重新部署 | Site Recovery 不会对成本造成影响，副本存储的成本会适中增加 | |
| Azure SQL 数据库：业务关键层 |
|
启用 | 无成本影响 | |
| Azure SQL 数据库：常规用途层 |
|
启用 | 适度增加成本 | |
| Azure SQL 数据库：超大规模层 |
|
重新部署 | 所需的最低副本数量 | |
| Azure SQL 数据库：高级层 |
|
启用 | 无成本影响 | |
| Azure SQL 托管实例 |
|
启用 | 适度增加成本 | |
| Azure 表存储 |
|
启用 | 适度增加成本 | |
| Azure 虚拟机规模集 |
|
|
重新部署 | 不会对相同数量的 VM 产生任何成本影响 |
| Azure 虚拟机 |
|
重新部署 | 不会对相同数量的 VM 产生任何成本影响 | |
| Azure 虚拟网络 |
|
始终具有区域复原能力 | N/A | |
| 公共 IP 地址 |
|
|
始终具有区域复原能力 | N/A |