你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
针对区域复原能力设计 Azure 工作负荷有助于保护应用程序免受硬件故障、网络中断和自然灾害的影响。 通过在区域内的多个可用性区域中分配资源以实现可用性区域复原能力，可以降低影响关键服务的单区域中断的风险。
在初始规划和部署工作负载期间，区域复原能力最有效。 但是，可能尚未将许多现有工作负载配置为支持此级别的保护。 在大多数情况下，为部署的工作负载启用区域复原非常简单，并且 Microsoft 会继续改进，进一步简化该过程。 但是，由于对工作负荷的任何更改都可能会导致风险，因此必须仔细地进行规划。 评估并确定这些工作负载中的哪些工作负载和服务对业务至关重要。 然后首先将区域复原应用到影响最大的资源。
本文概述了在 Azure 工作负载中启用区域复原的关键注意事项。 它还有助于规划和实施成功过渡到更具弹性的体系结构。
小窍门
如果目前正在设计工作负载或计划对当前工作负载进行设计评审，请务必遵循有关在 Azure 架构良好的框架中设计冗余的建议。 链接的文章可帮助你跨多个级别设计工作负载冗余，重点介绍关键工作流。 为了支持采用可用性区域，架构良好的框架中的冗余建议指南还概述了多区域部署和部署戳等策略。
什么是区域复原能力？
Azure 服务可以通过两种主要方式实现针对可用性区域中断情况的复原能力：
区域冗余服务：许多 Azure 服务支持区域冗余。 这些服务会在可用性区域之间自动复制数据，分发传入请求，并在区域故障期间故障转移到不同的区域。 每项服务都以对每项服务有意义的方式支持这些功能。 某些服务默认是区域冗余的，而其他服务可能需要你配置区域冗余。
区域服务：某些 Azure 服务是区域性服务，这意味着它们可以固定到特定的可用性区域。 若要使用区域性服务实现区域复原，需要在多个可用性区域中部署服务的独立实例。 你可能还需要管理流量分布、数据复制以及实例之间的故障转移。
某些服务可以部署在区域冗余配置或区域性配置中。 大多数情况下，最好尽可能部署区域冗余服务。
有关详细信息，请参阅可用性区域支持类型。
区域启用过程
使用以下步骤系统地查看 Azure 工作负载、确定其区域复原能力优先级，并为每个组件启用区域复原能力。
先决条件
在开始之前，必须执行以下操作：
标识每个工作负荷。 工作负荷是指应用程序资源、数据和支持基础结构的集合，它们协同工作以实现定义的业务成果。 若要详细了解工作负载以及如何定义它们，请参阅架构良好的框架工作负载。
确定每个工作负荷的用户和系统流的优先级。 了解工作负载的关键路径和依赖项对于确定哪些组件首先获取区域复原能力至关重要。 若要详细了解如何使用关键流分析确定工作流优先级，请参阅确定工作负载的优先级以获取区域复原能力。
为每个工作负荷和流分配重要性分级。 此分级可帮助你了解潜在中断对业务的影响，并指导你决定哪些工作负荷优先用于区域复原能力。 还应考虑重新配置工作负荷时可接受的停机时间。
可以使用简单的分类方法，根据工作负载的关键性对工作负载进行分类。 此方法可帮助你将精力集中在最重要的服务上。
请考虑以下对工作负载进行分类的示例分类方法。
工作负荷类型 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 Cache for 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 Bastion |
|
|
重新部署 | 无成本影响 |
| Azure Batch |
|
重新部署 | 不会对相同数量的 VM 产生任何成本影响 | |
| Azure Blob 存储服务 |
|
启用 | 适度增加成本 | |
| Azure Cache for Redis - 企业版 |
|
重新部署 | 无成本影响 | |
| Azure Cache for Redis - 标准版和高级版 |
|
启用 | 最低所需等级 | |
| Azure 容器应用 |
|
重新部署 | 所需的最低副本数量 | |
| Azure 容器实例 |
|
重新部署 | 无成本影响 | |
| Azure 容器注册表 |
|
始终具有区域复原能力 | N/A | |
| 用于 NoSQL 的 Azure Cosmos DB |
|
修改 | 如果使用自动缩放或多区域写入，则为无 | |
| Azure 数据工厂 |
|
始终具有区域复原能力 | N/A | |
| Azure Data Lake Storage |
|
启用 | 适度增加成本 | |
| Azure Database for MySQL 灵活服务器 |
|
重新部署 | 需要主实例和 HA 实例 | |
| Azure Database for PostgreSQL 灵活服务器 |
|
启用 | 需要主实例和 HA 实例 | |
| Azure 磁盘存储（托管磁盘） |
|
|
启用 | 适度增加成本 |
| Azure 弹性 SAN |
|
重新部署 | 适度增加成本 | |
| Azure 事件中心：专用层 |
|
始终具有区域复原能力 | 所需的最少计算单元 | |
| Azure 事件中心：所有其他层 |
|
始终具有区域复原能力 | N/A | |
| Azure ExpressRoute |
|
|
修改 | 取决于级别 |
| Azure 文件 |
|
启用 | 适度增加成本 | |
| Azure 防火墙 |
|
|
修改 | 无成本影响 |
| Azure Functions |
|
重新部署 | 所需的最低层级和实例数量 | |
| Azure HDInsight |
|
重新部署 | 对相同数量的节点没有成本影响 | |
| Azure IoT 中心 |
|
始终具有区域复原能力 | N/A | |
| Azure Key Vault |
|
始终具有区域复原能力 | N/A | |
| Azure Kubernetes 服务 (AKS) |
|
重新部署 | 无成本影响 | |
| Azure 负载均衡器 |
|
|
修改 | 无成本影响 |
| Azure 逻辑应用 - 消耗层 |
|
始终具有区域复原能力 | N/A | |
| Azure 逻辑应用 - 标准层 |
|
重新部署 | 所需的最低层级和实例数量 | |
| Azure 托管 Grafana |
|
重新部署 | 适度增加成本 | |
| Azure Monitor：Log Analytics |
|
始终具有区域复原能力 | ||
| Azure NetApp 文件 |
|
重新部署 | 取决于复制配置 | |
| 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 |