在 Azure 中， 区域 资源是固定到单个区域的资源。 由于区域资源位于单个可用性区域中，因此它不具有区域复原能力。 如果包含资源的区域有问题，则资源可能会遇到停机。
某些 Azure 服务需要或允许部署区域资源。 可能会因延迟注意事项或特定服务要求而选择以区域方式部署资源。 可以将单个资源或相关资源集固定到单个区域。
本文概述了可以选择部署区域资源而不是区域冗余资源的方案。 它还重点介绍了确保解决方案在发生区域中断时保持复原所需的注意事项和职责。
资源部署类型
在 Azure 中，只有某些部署类型提供区域复原能力。 下表比较了三种资源部署类型，并描述了其区域复原能力、区域分布、配置选项和建议。
| 资源部署类型 | 区域复原支持 | 区域分布 | 配置方式 | 建议 |
|---|---|---|---|---|
| Zone-redundant | 始终具有区域复原能力 | 可用区冗余资源分布在多个可用区，并且能够抵御可用区故障。 如果一个区域中发生故障，服务可以继续在其他区域中运行。 | 某些区域冗余资源跨可用性区域提供自动区域冗余，而其他资源则要求手动启用区域冗余。 查看服务的可靠性指南，了解服务在启用弹性所需的要求。 | 尽可能始终使用区域冗余资源，尤其是在生产部署中。 |
| Zonal | 不自动。 如果你选择，你有责任启用区域复原能力。 区域资源与其他区域中的故障隔离，但自己的区域发生故障可能会导致停机。 |
为资源选择区域。 | 如果有多个资源需要 区域对齐 （放置在同一区域中），则必须 在每个 资源上配置同一区域。 | 仅当需要 明确需要时，才使用区域资源。 若要使解决方案区域具有复原能力，你有责任设计和实现多区域解决方案。 |
| 非区域（区域） | None | 如果区域提供可用性区域支持，Azure 可能会使用该区域中的任何区域。 | 没有可用于非区域资源的区域配置。 | 由于无法使非区域资源具有区域复原能力，因此请避免对具有可用性区域的区域中的所有生产工作负荷进行非区域部署。 |
有关可用性区域和资源部署的详细信息，请参阅 可用性区域。
合并区域冗余和区域资源的工作负荷
许多工作负荷将区域冗余和区域资源组合在一起。 例如，工作负荷可能包括数据库层的一组区域虚拟机（VM），一个托管在 Azure 应用服务上的区域冗余 Web 服务器，以及一个区域冗余的负载均衡器，用于将流量发送到数据库 VM。
在工作负荷中合并区域和区域冗余资源时，请考虑每个资源和整体解决方案在可用性区域出现问题时的行为方式。 通常，区域冗余服务会自动从区域中断中恢复，但几乎不会丢失数据，Azure 会管理整个过程。 对于区域资源，你负责配置自动故障转移或执行手动恢复活动。 若要了解每个服务在区域关闭方案中的行为方式、了解职责与 Azure 职责，并在区域关闭事件期间监视服务的运行状况，请参阅服务的可靠性指南。
何时使用区域部署
仅当需要明确时，才使用区域资源。 单区域部署的典型原因包括：资源必须是区域性的、仅在特定区域中可用的服务，或者工作负荷对区域间延迟高度敏感。
重要
某些 Azure 服务允许在可用区域部署和区域冗余部署之间进行选择。 如果没有使用区域部署的强烈原因，建议使用区域冗余部署。
需要区域部署的资源
少数 Azure 服务仅支持区域部署，不提供区域冗余部署。
VM 是区域资源。 可以使用虚拟机规模集创建 VM 集。 虚拟机规模集可以设为跨区域，这意味着集中的虚拟机分布在多个区域中。 规模集是实现许多 VM 工作负载区域弹性的好方法。
小窍门
如果部署多个执行类似函数的 VM，建议使用跨区域规模集而不是单独部署的单实例 VM。
某些服务提供仅在特定区域中可用的选项。 例如，使用高级图形处理单元（GPU）的特定 VM 类型可能仅在区域中的特定区域中可用，这意味着不能跨多个区域部署它们。 若要检查哪些区域和区域支持所需的 VM 类型，请使用以下资源：
若要查看每个区域中可用的 VM 类型，请参阅 可用产品（按区域）。
若要检查特定区域的每个区域中支持的 VM 类型和大小，请参阅 “检查 VM SKU 可用性”。
如果您所需的虚拟机类型仅在使用的区域的单个可用区中可用，您可以考虑在该区内进行部署，然后寻找其他方法以增强虚拟机在区域中断时的恢复能力。 但应继续确保解决方案的其他部分具有区域复原能力。
有关详细信息，请参阅支持可用性区域的 Azure 服务。
区域间延迟
如果工作负荷对延迟异常敏感，则即使服务支持区域冗余部署，也可能会使用单区域资源而非区域冗余资源。
低延迟网络连接可用性区域，区域间往返延迟通常不到两毫秒。 对于大多数工作负荷，区域间延迟并没有影响。 跨可用性区域分布资源的复原优势比在区域之间发送流量的最小性能影响更重要。 但一些工作负荷对区域间延迟高度敏感。 这些工作负载可能包括以下情境：
遗留本地部署应用程序： 某些遗留工作负载可能包含最初为本地部署环境设计的应用程序。 这些工作负荷假定组件（如数据库和其他应用程序和服务）并置在同一主机上或接近物理邻近。
非常大规模的同步复制： 有状态应用程序和数据库偶尔会使用 同步复制执行大量写入。 同步复制意味着在写入作被视为完成之前将数据写入多个 副本 。 跨可用性区域分发副本可提高复原能力，但在使用同步复制时，区域间延迟可能会增加工作负荷的写入延迟。 这种增加的延迟通常并不重要，但由于某些应用程序的设计方式，有时在大规模上可能会变得有问题。
重要
工作负荷对区域间延迟敏感是不寻常的。 不要假设工作负荷受到影响，除非测试特定工作负荷和需求的延迟。
如果怀疑区域间延迟正在影响工作负荷，请按照以下步骤针对特定工作负荷测试其在现实环境中的影响：
定义可接受的性能要求。 区域间流量会增加少量延迟，但对于大多数工作负荷而言，这可以忽略不计。 请定义 您的 工作负荷可接受的性能。
在单个可用性区域中运行性能测试。 建立一组基线性能指标。
重要
测试工作负荷，包括应用程序、协议、配置和 Azure 区域。 使用实际负载。 基准测试和综合测试是不够的，因为它们不显示解决方案的实际行为。
启用区域间复制。 根据所使用的组件，可以启用区域冗余或在区域之间移动副本。
重新运行性能测试。 收集之前收集的相同指标。
将性能影响与要求进行比较。 根据要求和性能数据，明智地在延迟和可用区中断弹性之间做出权衡决策。
如果测试表明延迟对于您的工作负载不可接受的高，请考虑执行以下措施：
请尝试使用另一组区域。 不同区域之间的延迟可能会略有变化，因为它们可以彼此具有不同的物理距离。
小窍门
如果跨 Azure 订阅进行测试，请查看 逻辑到物理可用区映射，以确保测试预期的物理可用区集。
如果有另一个 Azure 区域满足数据驻留的总体需求和其他因素，请尝试在该区域中使用多个区域。
请考虑是否可以重新设计应用程序，以最大程度地减少所需的区域间通信。 例如，你可能能够将多个小型数据库操作整合到单个操作中。 此方法可以减少对工作负荷的延迟影响。
如果上述任何作都无帮助，请考虑使用区域 VM 和其他受支持的 Azure 服务在单个可用性区域中运行特定的工作负荷或组件。 然后，你将负责使区域组件具备弹性以应对区域中断。 请查看本文的其余部分，了解职责和一些要考虑的方法。
你对区域部署的责任
当区域资源遇到中断时，其可用性区域面临停机的风险。 在部署区域资源时，您有责任确保您的工作负载能够抵御区域级故障。
重要
区域资源本身不具备抵御区域故障的能力。 必须设计一种方法，通过制定包含区域关闭方案的计划来缓解区域故障的风险。
若要使分区资源具有区耐受性，请考虑以下职责：
部署和配置多个资源： 将单独的区域资源手动部署到不同的区域或区域。 确定如何使配置在每个资源之间保持一致。 使用基础结构即代码（IaC）是最佳做法，因为它支持快速部署多个相同的资源。
流量路由和分发： 必须选择负载均衡器组件，确保其具有区域弹性，并将其配置为在不同区域中的资源之间发送流量。 通常配置路由策略（例如主动-主动或主动-被动）、自动运行状况检查和故障转移过程。 有关详细信息，请参阅 负载均衡选项。
复制或数据备份： 对于有状态资源，你负责保护它们存储的数据，并确保数据安全地保存在多个区域中。 一种常见方法是将复制配置为复制到其他可用性区域中的另一个服务实例。 在某些情况下，可能会依赖于备份。 但在区域故障期间，备份需要更长的恢复时间，这要求你具有更高的恢复时间目标（RTO）。 它们还会导致更多的数据丢失，这需要更高的恢复点目标（RPO）。
区域故障检测和响应过程实现：必须确定如何监视区域资源的运行状况，定义将它们标记为不健康的条件，并触发响应措施，例如在其他区域或地区中还原操作。
区域恢复过程：在区域恢复后，您负责执行任何必需的恢复操作，例如故障切换回主区域中的资源。
区域部署复原的常见方法
若要为区域资源实现区域复原做出明智的决策，请考虑以下因素：
查看整个工作负荷。 了解每个组件在区域关闭事件期间的表现，包括区域冗余、区域性和非区域性资源。 使用每个服务的可靠性指南来了解服务在区域关闭方案中的工作原理，以及如何监视服务运行状况以了解区域关闭事件。
了解区域故障期间可接受的数据丢失。 RPO 指定可以接受多少数据丢失。
许多 Azure 区域冗余资源为区域故障提供零的 RPO，这意味着不会发生数据丢失。 它们通常通过跨区域同步复制所有更改来实现此 RPO。
规划区域部署时，必须确保在区域发生故障时满足工作负荷的 RPO 要求。
了解区域故障期间的可允许停机时间。 RTO 指定可以接受的停机时间。
Azure 区域冗余资源通常在区域故障时提供非常低的恢复时间目标 (RTO)，通常仅需要几秒钟的停机时间。
规划区域部署时，必须确保满足工作负荷的 RTO 要求。 如果 RTO 较低，则可能需要依赖于自动检测和恢复过程。 更高的 RTO 为响应过程提供了更大的灵活性。
了解成本。 区域资源通常单独计费，因此部署多个区域资源会增加资源成本。
设计用于复原能力的区域性部署
设计区域部署以实现复原能力时，请考虑是使用可用性区域来实现 高可用性 还是 灾难恢复。 这些概念的区别取决于您的 RTO 和 RPO 的要求。
如果你有较低的 RTO 和较低的 RPO 要求，则需要将可用性区域视为 高可用性 构造。 但是，如果 RTO 和 RPO 更高，可以选择将可用性区域视为 灾难恢复 构造。 有关详细信息，请参阅 业务连续性、高可用性和灾难恢复。 工作负荷层可帮助你确定需求和必要的行动。
为高可用性而设计
请考虑跨多个区域部署自己的高可用性体系结构。 高度可用的体系结构要求跨多个区域部署的组件进行自动和频繁的数据复制，并在发生区域故障时在这些组件之间实现自动故障转移。
在区域 VM 上部署的某些应用程序提供内置的高可用性支持，例如，可以识别副本。 例如，如果在 Azure VM 上使用 SQL Server， 可用性组 将提供流量路由和故障转移功能。 可以选择是使用同步复制还是异步复制。 有关详细信息，请参阅 Azure VM 上 SQL Server 的业务连续性、高可用性和灾难恢复。
灾难恢复设计
灾难恢复不同于高可用性，因为在灾难方案中可以接受更高的停机时间和数据丢失。 RTO 和 RPO 通常以小时或更长时间进行度量。
灾难恢复计划可帮助你准备不同的方案，并定义如何使用自动化和手动过程的组合做出响应。
规划区域部署时，以下灾难恢复方法会有所帮助：
Azure Site Recovery 区域到区域灾难恢复： 当需要不同区域中 VM 之间的磁盘级异步复制时，此方法非常有用。 有关详细信息，请参阅 在可用性区域之间启用 Azure VM 灾难恢复。
Site Recovery 区域到区域灾难恢复： Site Recovery 支持区域到区域灾难恢复，并依赖于异步复制。 此方法允许你故障转移到另一个 Azure 区域中的区域，而不是主要区域中的另一个区域。 有关详细信息，请参阅 将 Azure VM 复制到另一个 Azure 区域。
基于备份的灾难恢复： 如果解决方案可以容忍较高的 RTO 和高 RPO，请考虑将备份用作灾难恢复策略。 如果区域遇到服务中断，则可以将备份还原到另一个区域或区域。 还需要考虑是在解决方案中预先创建其他 Azure 资源，还是在故障转移过程中创建它们。
在区域体系结构中，通常负责存储和复制这些备份。
Azure 备份 是广泛使用的托管备份服务。 它支持跨配对 Azure 区域的区域冗余备份和异地复制备份。 某些应用程序（如 Azure VM 上的 SQL Server）还包括特定于应用程序的内置备份功能。