你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure 可用性区域迁移基线

本文介绍如何评估应用程序的可用性区域就绪情况,确定它是否可以从非可用性区域迁移到可用性区域支持。 了解如何利用可用性区域支持,以及如何满足应用程序和复原能力的要求。 有关可用性区域以及支持它们的 Azure 区域的更详细信息,请参阅什么是 Azure 区域和可用性区域

在创建可靠的工作负载时,可以选择下列至少一个可用性区域配置:

  • 区域。 区域配置提供特定的、自我选择的可用性区域。

  • 区域冗余。 区域冗余配置提供跨区域自动复制或分配的资源。

除了区域和区域冗余这两个可用性区域选项之外,Azure 还提供全球服务,这意味着,无论位于全球的哪个 Azure 区域,都可以使用这些服务。 这些服务始终可在不同的 Azure 区域中使用,因此它们可灵活应对 Azure 区域和局部区域性的服务中断。

若要查看哪些 Azure 服务支持可用性区域,请参阅可用性区域服务和区域支持

注意

如果你没有为资源选择区域配置(区域或区域冗余),则该资源及其子组件将不具备区域复原能力,可能会在该区域发生区域性服务中断期间出现故障。

迁移到可用性区域支持时的注意事项

可以通过多种可行的方法使用符合 SLA 和可靠性目标的可用性区域创建可靠的 Azure 应用程序。 按照以下步骤,根据技术和法规考虑因素、服务功能、数据驻留、合规性要求和延迟选择符合需求的正确方法。

步骤 1:检查 Azure 区域是否支持可用性区域

在这第一个步骤,需要验证选择的 Azure 区域是否支持可用性区域以及应用程序所需的 Azure 服务。

如果该 Azure 区域支持可用性区域,我们强烈建议为工作负载配置可用性区域。 如果该 Azure 区域不支持可用性区域,则你需要遵循 Azure 资源转移器指南迁移到支持可用性区域的 Azure 区域。

注意

对于某些服务,只能在部署期间配置可用性区域。 如果你想要为现有服务配置可用性区域,可能需要重新部署。 请参阅 Microsoft Azure 产品和服务的可用性区域迁移指南概述中的服务特定文档。

步骤 2:检查 Azure 区域中的产品和 SKU 可用性

在此步骤,验证所需的 Azure 服务和 SKU 是否在所选 Azure 区域的可用性区域中可用。

若要检查服务的区域支持,请参阅在各区域中可用的产品

若要按 Azure 区域和局部区域列出可用的 VM SKU,请参阅查看 VM SKU 可用性

如果你所在的 Azure 区域不支持应用程序所需的服务和 SKU,则你需要回到步骤 1:检查 Azure 区域中的产品可用性,以查找支持应用程序所需的服务和 SKU 的新区域。 我们强烈建议为工作负载配置区域冗余。

要实现 Azure IaaS 虚拟机的多区域高可用性,请使用虚拟机规模集 Flex 将 VM 分散到多个可用性区域。

步骤 3:考虑应用程序要求

在这最后一个步骤,请根据应用程序要求,确定哪种可用性区域支持最适合你的应用程序。

以下三个重要问题可帮助你选择正确的可用性区域部署:

应用程序是否包含延迟敏感型组件?

同一 Azure 区域中的 Azure 可用性区域采用高性能网络进行连接,往返延迟小于 2 毫秒

如果不严格要求保证低延迟,实现高可用性的建议方法是使用区域冗余部署配置工作负载。

对于要求物理距离靠近且低延迟的关键应用程序组件,例如游戏、工程模拟和高频交易 (HFT),我们建议配置一个区域部署。 虚拟机规模集 Flex 提供与区域一致的计算以及附加的存储磁盘。

应用程序代码是否已准备好处理分布式模型?

对于分布式微服务模型,可以根据应用程序在不同区域中的微服务之间持续交换数据。 这种通过 API 进行的持续数据交换可能会影响性能。 为了提高性能并维持可靠的体系结构,可以选择区域部署。

对于区域部署,必须:

  1. 识别体系结构中的延迟敏感型资源或服务。

  2. 确认延迟敏感型资源或服务是否支持区域部署。

  3. 将延迟敏感型资源或服务放在同一区域。 体系结构中的其他服务可以继续保持区域冗余。

  4. 跨多个可用性区域复制延迟敏感型区域服务,以确保区域复原能力。

  5. 使用标准或全局负载均衡器在多个区域部署之间进行负载均衡。

如果 Azure 服务支持可用性区域,我们强烈建议通过跨区域分散节点来使用区域冗余,以获得更高的运行时间 SLA 和防范区域服务中断。

对于 3 层应用程序,必须了解应用程序、业务和数据层及其状态(有状态或无状态),以便根据工作负载类型遵循最佳做法和指导来架构该应用程序。

对于 Azure 上的专用工作负载(如以下示例所示),请参考相应的登陆区域体系结构指导和最佳做法。

你是否由于需要满足合规性、数据驻留或治理要求而要在同一 Azure 区域中实现业务连续性和灾难恢复?

若要在没有区域对的情况下在同一区域中实现业务连续性和灾难恢复,我们强烈建议为工作负载配置区域冗余。 单区域方法也适用于需要在同一 Azure 区域中满足严格数据驻留和治理要求的某些行业。 若要了解如何将 Azure 虚拟机从一个可用性区域复制、故障转移和故障回复到同一 Azure 区域中的另一个可用性区域,请参阅在可用性区域之间启用 Azure VM 灾难恢复

如果你需要使用多区域方法,或者你的 Azure 区域不支持可用性区域,我们建议使用区域对。 区域对彼此相隔很远的距离(大约 100 英里),在由于火灾、洪灾、地震和其他自然灾害或不可预见的灾难等情况而发生 Azure 区域级别的故障时,它们可以缩小故障影响范围。 有关详细信息,请参阅 Azure 中的跨区域复制:业务连续性和灾难恢复

注意

在某些情况下,最适合使用区域、区域冗余和全球服务的组合来满足业务和技术要求。

要考虑的其他要点

  • 若要了解如何测试应用程序的可用性和复原能力,请参阅测试应用程序的可用性和复原能力

  • Azure 区域中的每个数据中心将分配到一个物理区域。 物理区域映射到 Azure 订阅中的逻辑区域。 在创建订阅后,将自动为此映射分配 Azure 订阅。 可以使用专用的 ARM REST API listLocations 并将 API 版本设置为 2022-12-01,以列出订阅的逻辑区域到物理区域的映射。 此信息对于需要与归类为战略性服务的、并非在所有物理区域中都可用的 Azure 资源共置在一起的关键应用程序组件非常重要。

后续步骤