多区域 N 层应用程序

此参考体系结构展示了在多个 Azure 区域中运行 N 层应用程序以实现可用性和强健的灾难恢复基础结构的一组经过实践检验的做法。

体系结构

下载此体系结构的 Visio 文件。

工作流

• 主要和次要区域。 使用两个区域来实现更高的可用性。 其中一个是主要区域。 另一个区域用于故障转移。

• Azure 流量管理器。 流量管理器将传入请求路由到其中一个区域。 在正常运行期间，它将请求路由到主要区域。 如果该区域变得不可用，则流量管理器将故障转移到次要区域。 有关详细信息，请参阅流量管理器配置部分。

• 资源组。 为主要区域、次要区域和流量管理器创建单独的资源组。 此方法允许你将每个区域作为单个资源集合灵活进行管理。 例如，可以重新部署一个区域而无需关闭另一个区域。 链接资源组，以便可以运行查询来列出应用程序的所有资源。

• 虚拟网络。 为每个区域创建一个单独的虚拟网络。 请确保地址空间不重叠。

• SQL Server Always On 可用性组。 如果使用的是 SQL Server，建议使用 SQL Always On 可用性组以实现高可用性。 创建同时包含两个区域中的 SQL Server 实例的单个可用性组。

  注意

  另外请考虑使用 Azure SQL 数据库，它以云服务形式提供关系数据库。 使用 SQL 数据库，不需要配置可用性组或管理故障转移。

• 虚拟网络对等互连。 将两个虚拟网络对等互连，以允许将数据从主要区域复制到次要区域。 有关详细信息，请参阅虚拟网络对等互连。

组件

• 可用性集确保在 Azure 上部署的 VM 能够跨群集中多个隔离的硬件节点分布。 如果 Azure 中发生硬件或软件故障，只有一部分 VM 会受到影响，而整个解决方案将保持可用且正常运行。
• 数据中心发生故障时，可用性区域可以保护应用程序和数据。 可用性区域是 Azure 区域中独立的物理位置。 每个区域由一个或多个数据中心组成，这些数据中心配置了独立电源以及散热和网络设备。
• Azure 流量管理器是一种基于 DNS 的流量负载均衡器，以最佳方式分配流量。 它跨全球 Azure 区域提供服务，具有高可用性和响应能力。
• Azure 负载均衡器根据定义的规则和运行状况探测分配入站流量。 负载均衡器提供低延迟和高吞吐量，可纵向扩展到数百万个流，以满足所有 TCP 和 UDP 应用程序的需求。 本方案使用公共负载均衡器将传入的客户端流量分配到 Web 层。 本方案使用内部负载均衡器将来自业务层的流量分配到后端 SQL Server 群集。
• Azure Bastion 为预配它的虚拟网络中的所有 VM 提供安全的 RDP 和 SSH 连接。 使用 Azure Bastion 可防止虚拟机向外部公开 RDP/SSH 端口，同时仍然使用 RDP/SSH 提供安全访问。

建议

与部署到单个区域相比，多区域体系结构可以提供更高的可用性。 如果区域性故障影响了主要区域，则可以使用流量管理器故障转移到次要区域。 当应用程序的单个子系统出现故障时，此体系结构可能也比较有用。

有多种常规方法可跨区域实现高可用性：

• 主动/被动（采用热备用模式）。 流量将前往一个区域，而另一个区域将以热备用模式等待。 “热备用模式”意味着次要区域中的 VM 已被分配并总是处于运行状态。
• 主动/被动（采用冷备用模式）。 流量将前往一个区域，而另一个区域将以冷备用模式等待。 “冷备用”意味着只有故障转移需要用到次要区域中的 VM 时才分配这些 VM。 此方法的运行成本较低，但是当发生故障时通常需要花费更长时间才能联机。
• 主动/主动。 两个区域都处于活动状态，并且会在它们之间对请求进行负载均衡。 如果某个区域不可用，该区域将被取出轮用阵容。

此参考体系结构侧重于“主动/被动（采用热备用模式）”，使用流量管理器进行故障转移。 可以为热备用模式部署少量 VM，然后根据需要横向扩展。

区域配对

每个 Azure 区域都与同一地域内的另一个区域配对。 通常，请选择同一区域对中的区域（例如“美国东部 2”和“美国中部”）。 这样做的好处包括：

• 如果发生大范围的故障，会优先恢复每个区域对中的至少一个区域。
• 计划内 Azure 系统更新会按顺序提供给配对的区域，以尽可能减少停机时间。
• 区域对位于同一地域内，以满足数据驻留要求。

但请确保两个区域都支持应用程序所需的所有 Azure 服务（请参阅每个区域的服务）。 有关区域对的详细信息，请参阅业务连续性和灾难恢复 (BCDR)：Azure 配对区域。

流量管理器配置

配置流量管理器时，请考虑以下几点：

• 路由。 流量管理器支持多个路由算法。 对于本文中所述的情况，请使用“优先级”路由（以前称为“故障转移”路由）。 使用此设置时，流量管理器将所有请求都发送到主要区域，除非主要区域变得无法访问。 那时，它将自动故障转移到次要区域。 请参阅配置故障转移路由方法。
• 运行状况探测。 流量管理器使用 HTTP（或 HTTPS）探测来监视每个区域的可用性。 探测检查指定 URL 路径的 HTTP 200 响应。 作为最佳做法，请创建一个用于报告应用程序整体运行状况的终结点，并使用此终结点进行运行状况探测。 否则，探测可能会在应用程序的关键部分实际上已出现故障时报告终结点运行状况正常。 有关详细信息，请参阅 运行状况终结点监视模式。

当流量管理器进行故障转移时，一段时间内客户端将无法访问应用程序。 持续时间受以下因素影响：

• 运行状况探测必须检测主要区域是否变得无法访问。
• DNS 服务器必须更新 IP 地址的已缓存 DNS 记录，这取决于 DNS 生存时间 (TTL)。 默认 TTL 为 300 秒（5 分钟），但可以在创建流量管理器配置文件时配置此值。

相关详细信息，请参阅关于流量管理器监视。

如果流量管理器进行故障转移，我们建议执行手动故障回复，而不是实施自动故障回复。 否则，可能会造成应用程序在区域之间来回转移的情况。 在进行故障回复之前，请验证是否所有应用程序子系统的运行状况都正常。

默认情况下，流量管理器会自动进行故障回复。 若要禁止此问题，请在发生故障转移事件后手动降低主要区域的优先级。 例如，假设主要区域的优先级为 1，次要区域的优先级为 2。 在故障转移后，请将主要区域的优先级设置为 3，以禁止自动故障回复。 当准备好切换回来时，请将优先级更新为 1。

以下 Azure CLI 命令更新优先级：

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --priority 3

另一种方法是暂时禁用终结点，直到你准备好进行故障回复：

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --endpoint-status Disabled

可能需要重新部署某个区域中的资源，具体取决于故障转移原因。 在进行故障回复之前，请执行操作准备情况测试。 测试应当验证的事项如下所示：

• VM 是否已正确配置。 （所有必需的软件是否已安装、IIS 是否正在运行，等等。）
• 应用程序子系统运行状况是否正常。
• 功能测试。 （例如，是否可以从 Web 层访问数据库层。）

配置 SQL Server Always On 可用性组

在 Windows Server 2016 之前，SQL Server Always On 可用性组需要一个域控制器，并且可用性组中的所有节点必须在同一 Active Directory (AD) 域中。

若要配置可用性组，请执行以下操作：

• 至少在每个区域中放置两个域控制器。

• 为每个域控制器提供一个静态 IP 地址。

• 将两个虚拟网络对等互连，以便启用它们之间的通信。

• 针对每个虚拟网络，将两个区域中的域控制器的 IP 地址添加到 DNS 服务器列表。 可以使用以下 CLI 命令。 有关详细信息，请参阅更改 DNS 服务器。

  az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
  

• 创建一个 Windows Server 故障转移群集 (WSFC) 群集，使其包括两个区域中的 SQL Server 实例。

• 创建一个 SQL Server Always On 可用性组，使其包括主要区域和次要区域中的 SQL Server 实例。 有关步骤，请参阅将 Always On 可用性组扩展到远程 Azure 数据中心 (PowerShell)。

  • 将主要副本放置在主要区域中。

  • 将一个或多个次要副本放置在主要区域中。 配置这些副本以将同步提交与自动故障转移一起使用。

  • 将一个或多个次要副本放置在次要区域中。 出于性能方面的原因，请配置这些副本以使用异步提交。 （否则，所有 T-SQL 事务必须等待通过网络到次要区域的往返旅程。）

    注意

    异步提交副本不支持自动故障转移。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。

可用性

使用复杂的 N 层应用时，可能不需要在次要区域中复制整个应用程序。 相反，可能只需复制支持业务连续性所需的关键子系统。

流量管理器是系统中的一个潜在故障点。 如果流量管理器服务出现故障，则客户端在停机期间无法访问应用程序。 查看流量管理器 SLA，然后确定仅使用流量管理器是否能满足业务对高可用性的需求。 如果不能，请考虑添加另一个流量管理解决方案作为故障回复机制。 如果 Azure 流量管理器服务出现故障，请将 DNS 中的 CNAME 记录更改为指向其他流量管理服务。 （此步骤必须手动执行，并且在 DNS 更改被传播之前，应用程序将不可用。）

对于 SQL Server 群集，有两个故障转移方案需要考虑：

• 主要区域中的所有 SQL Server 数据库副本都失败。 例如，在发生区域性中断期间可能会出现此故障。 在这种情况下，必须手动故障转移可用性组，尽管流量管理器在前端会自动进行故障转移。 请按照执行可用性组的强制手动故障转移 (SQL Server) 一文中的步骤进行操作，该文章介绍了如何在 SQL Server 2016 中使用 SQL Server Management Studio、Transact-SQL 或 PowerShell 执行强制故障转移。

  警告

  使用强制故障转移时存在数据丢失风险。 在主要区域恢复联机状态后，创建数据库快照并使用 tablediff 查明差异。

• 流量管理器故障转移到次要区域，但主要 SQL Server 数据库副本仍然可用。 例如，前端层可能会失败，但不会影响 SQL Server VM。 在这种情况下，Internet 流量将路由到次要区域中，并且该区域仍可以连接到主要副本。 但是，延迟将有所增加，因为 SQL Server 连接是跨区域的。 在此情况下，应当执行手动故障转移，如下所述：

  1. 暂时将次要区域中的 SQL Server 数据库副本切换为同步提交。 此步骤可确保在故障转移期间不会丢失数据。
  2. 故障转移到该副本。
  3. 在故障回复到主要区域后，还原异步提交设置。

可管理性

更新部署时，请一次更新一个区域，以减少由于错误配置或应用程序中的错误而导致全局故障的可能性。

测试系统在发生故障时的复原能力。 下面是要测试的一些常见故障方案：

• 关闭 VM 实例。
• 对 CPU 和内存等资源进行压力测试。
• 断开网络连接/使网络传输出现延迟。
• 使进程崩溃。
• 使证书过期。
• 模拟硬件错误。
• 关闭域控制器上的 DNS 服务。

测量恢复时间，并验证它们是否满足你的业务要求。 另外还测试故障模式的组合。

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。

使用 Azure 定价计算器估算成本。 下面是一些其他注意事项。

虚拟机规模集

虚拟机规模集适用于所有 Windows VM 大小。 只需为部署的 Azure VM 以及消耗的任何已添加的底层基础结构资源（例如存储和网络）付费。 虚拟机规模集服务不收取额外费用。

有关单个 VM 定价选项，请参阅 Windows VM 定价。

SQL Server

如果选择 Azure SQL DBaas，可以节省成本，因为无需配置 Always On 可用性组和域控制器计算机。 从单一数据库到托管实例或弹性池，有多种部署选项。 有关详细信息，请参阅 Azure SQL 定价。

有关 SQL Server VM 定价选项，请参阅 SQL VM 定价。

负载均衡器

你只需为配置的负载平衡和出站规则的数量付费。 入站 NAT 规则是免费的。 如果未配置规则，则标准负载均衡器不按小时收费。

流量管理器定价

流量管理器计费基于收到的 DNS 查询数量，每月收到超过 10 亿次查询的服务可享受折扣。 你还需要为每个受监视的终结点付费。

有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。

VNET 对等互连定价

利用多个 Azure 区域的高可用性部署将使用 VNET 对等互连。 同一区域中的 VNET 对等互连和全局 VNET 对等互连的费用不同。

有关详细信息，请参阅虚拟网络定价。

DevOps

使用单个 Azure 资源管理器模板来预配 Azure 资源及其依赖项。 使用同一模板将资源同时部署到主要区域和次要区域。 包括同一虚拟网络中的所有资源，以便它们隔离在同一基本工作负载中。 通过包括所有资源，可以更轻松地将工作负载的特定资源关联到某个 DevOps 团队，使该团队能够独立管理这些资源的所有方面。 这种隔离可使 DevOps 团队和服务执行持续集成和持续交付 (CI/CD)。

你还可使用不同的 Azure 资源管理器模板并将它们与 Azure DevOps Services 集成，以便在几分钟内预配不同的环境，例如仅在需要时复制类似生产环境的场景或负载测试环境，从而节省成本。

请考虑使用 Azure Monitor 来分析和优化基础结构的性能，在不登录到虚拟机的情况下监视和诊断网络问题。 Application Insights 实际上是 Azure Monitor 的组件之一，为你提供丰富的指标和日志来验证整个 Azure 环境的状态。 Azure Monitor 有助于跟踪基础结构状态。

确保不仅要监视支持应用程序代码的计算元素，还要监视你的数据平台，特别是数据库，因为应用程序数据层的低性能可能会产生严重后果。

为了测试运行应用程序的 Azure 环境，应采用与应用程序代码相同的机制进行版本控制和部署，然后也可以使用 DevOps 测试范例进行测试和验证。

有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的卓越运营部分。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

• Donnie Trumpower | 高级云解决方案架构师

若要查看非公开领英个人资料，请登录领英。

后续步骤

• 在 Azure 中部署流量管理器
• 部署 Azure 负载均衡器

相关资源

以下体系结构使用了一些相同的技术：

• Azure 上可实现高可用性和灾难恢复的多层 Web 应用程序
• 多区域负载均衡