【Azure云】Azure上的多区域N层应用程序
视频号
微信公众号
知识星球
此参考体系结构显示了一组行之有效的做法，用于在多个Azure区域中运行N层应用程序，以实现可用性和强健的灾难恢复基础架构。
架构
Azure N层应用程序的高可用网络架构”
Download a Visio file of this architecture.
流
初级和次级区域。使用两个区域以实现更高的可用性。一个是主要地区。另一个区域用于故障切换。
- Azure流量管理器。Traffic Manager将传入请求路由到其中一个区域。在正常操作期间，它将请求路由到主区域。如果该区域不可用，Traffic Manager将故障转移到辅助区域。有关更多信息，请参阅“流量管理器配置”一节。
- 资源组。为主要区域、次要区域和Traffic Manager创建单独的资源组。这种方法使您能够灵活地将每个区域作为一个资源集合进行管理。例如，您可以重新部署一个区域，而不删除另一个区域。链接资源组，以便运行查询以列出应用程序的所有资源。
- 虚拟网络。为每个区域创建一个单独的虚拟网络。确保地址空间不重叠。
- SQL Server始终可用组。如果您使用SQL Server，我们建议使用SQL始终开启可用性组以获得高可用性。创建一个可用性组，其中包括两个区域中的SQL Server实例。
笔记
还可以考虑Azure SQL数据库，它将关系数据库作为云服务提供。使用SQL数据库，您不需要配置可用性组或
管理故障切换。- 虚拟网络对等。对等两个虚拟网络以允许数据从主区域复制到辅助区域。有关详细信息，请参阅虚拟网络对等。
组件
- 【Availability sets 】可用性集确保您在Azure上部署的虚拟机分布在群集中的多个独立硬件节点上。如果Azure中发生硬件或软件故障，则只有您的虚拟机的一个子集受到影响，并且您的整个解决方案仍然可用且可操作。
- 【Availability zones】可用性区域可保护您的应用程序和数据免受数据中心故障的影响。可用性区域是Azure区域内的独立物理位置。每个区域由一个或多个配备独立电源、冷却和网络的数据中心组成。
- 【Azure Traffic Manager 】Azure流量管理器是一个基于DNS的流量负载均衡器，可优化分配流量。它提供跨全球Azure区域的服务，具有高可用性和响应能力。
- 【Azure Load Balancer 】Azure负载平衡器根据定义的规则和运行状况探测来分发入站流量。负载均衡器提供低延迟和高吞吐量，可为所有TCP和UDP应用程序扩展到数百万个流。在此场景中使用公共负载均衡器，将传入的客户端流量分配到web层。在此场景中使用内部负载均衡器，将流量从业务层分配到后端SQL Server集群。
- 【Azure Bastion 】Azure Bastion为其提供的虚拟网络中的所有虚拟机提供了安全的RDP和SSH连接。使用Azure Bastion保护您的虚拟机不向外部世界暴露RDP/SSH端口，同时仍然使用RDP/SSH提供安全访问。
建议
多区域体系结构可以提供比部署到单个区域更高的可用性。如果区域中断影响主区域，则可以使用Traffic Manager故障转移到辅助区域。如果应用程序的单个子系统出现故障，这种体系结构也会有所帮助。
实现跨区域高可用性有几种通用方法：
- 【Active/passive】主动/被动，带热备用。流量流向一个区域，而另一个区域则处于热备用状态。热备用意味着辅助区域中的虚拟机已分配并且始终在运行。
- 【Active/passive 】主动/被动，冷待机。流量流向一个区域，而另一个区域则处于冷备用状态。冷备用意味着在需要进行故障切换之前，不会分配辅助区域中的虚拟机。这种方法运行成本较低，但在出现故障时通常需要更长的时间才能联机。
- 【Active/active】主动/主动。这两个区域都是活动的，请求在它们之间是负载平衡的。如果某个区域不可用，则该区域将退出旋转。
此参考体系结构侧重于使用Traffic Manager进行故障切换的带热备用的主/被动体系结构。您可以部署一些虚拟机进行热备用，然后根据需要进行扩展。
区域配对
每个Azure区域都与同一地理区域内的另一个区域配对。通常，从同一区域对中选择区域（例如，美国东部2和美国中部）。这样做的好处包括：
- 如果出现大范围停电，则优先恢复每对中至少一个区域。
- 计划中的Azure系统更新按顺序推出到成对的区域，以最大限度地减少可能的停机时间。
- 成对驻留在同一地理位置，以满足数据驻留要求。
但是，请确保这两个地区都支持应用程序所需的所有Azure服务（请参阅按地区提供的服务）。有关区域配对的更多信息，请参阅业务连续性和灾难恢复（BCDR）：Azure配对区域。
Traffic Manager配置
配置Traffic Manager时，请考虑以下几点：
- 路由。Traffic Manager支持多种路由算法。对于本文中描述的场景，请使用优先级路由（以前称为故障转移路由）。使用此设置，Traffic Manager会将所有请求发送到主区域，除非主区域无法访问。此时，它会自动故障转移到次要区域。请参阅配置故障转移路由方法。
- 健康探头。Traffic Manager使用HTTP（或HTTPS）探测来监控每个区域的可用性。探测器检查指定URL路径的HTTP 200响应。作为最佳实践，创建一个报告应用程序总体运行状况的端点，并将此端点用于运行状况探测。否则，当应用程序的关键部分实际发生故障时，探测器可能会报告一个健康的端点。有关详细信息，请参阅运行状况端点监视模式。
当Traffic Manager发生故障转移时，客户端会有一段时间无法访问应用程序。持续时间受以下因素影响：
- 运行状况探测器必须检测到主区域已无法访问。
- DNS服务器必须更新IP地址的缓存DNS记录，这取决于DNS生存时间（TTL）。默认TTL为300秒（5分钟），但您可以在创建Traffic Manager配置文件时配置此值。
有关详细信息，请参阅关于流量管理器监控。
如果Traffic Manager发生故障切换，我们建议执行手动故障切换，而不是执行自动故障切换。否则，您可以创建应用程序在区域之间来回翻转的情况。请验证所有应用程序子系统是否正常，然后再进行故障恢复。
Traffic Manager默认情况下会自动故障恢复。若要防止此问题，请在发生故障切换事件后手动降低主区域的优先级。例如，假设主要区域为优先级1，次要区域为优先级2。故障切换后，将主区域设置为优先级3，以防止自动故障回复。当您准备切换回时，将优先级更新为1。
以下Azure CLI命令更新优先级：
Azure CLI
az network traffic-manager endpoint update --resource-group <resource-group>
--profile-name <profile>
--name <endpoint-name> --type azureEndpoints --priority 3
另一种方法是暂时禁用端点，直到您准备好进行故障恢复：
Azure CLI
az network traffic-manager endpoint update --resource-group <resource-group>
--profile-name <profile>
--name <endpoint-name> --type azureEndpoints --endpoint-status Disabled
根据故障切换的原因，您可能需要在区域内重新部署资源。在故障恢复之前，请执行操作准备测试。测试应验证以下内容：
- 虚拟机配置正确。（所有必需的软件都已安装，IIS正在运行，等等。）
- 应用程序子系统是健康的。
- 功能测试。（例如，可以从web层访问数据库层。）
配置SQL Server始终可用组
在Windows Server 2016之前，SQL Server始终开启可用性组需要域控制器，并且可用性组中的所有节点必须位于同一Active Directory（AD）域中。
要配置可用性组，请执行以下操作：
- 在每个区域中至少放置两个域控制器。
- 为每个域控制器提供一个静态IP地址。
- 对等两个虚拟网络以实现它们之间的通信。
- 对于每个虚拟网络，将域控制器（来自两个区域）的IP地址添加到DNS服务器列表中。您可以使用以下CLI命令。有关详细信息，请参阅更改DNS服务器。
Azure CLI
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"- 创建一个包含两个区域中的SQL Server实例的Windows Server故障转移群集（WSFC）群集。
- 创建一个SQL Server始终可用组，该组包括主区域和辅助区域中的SQL Server实例。有关步骤，请参阅将始终可用性组扩展到远程Azure数据中心（PowerShell）。
- 将主复制副本放在主区域中。
- 在主区域中放置一个或多个辅助复制副本。将这些复制副本配置为使用同步提交和自动故障切换。
- 将一个或多个辅助复制副本放在辅助区域中。出于性能原因，将这些复制副本配置为使用异步提交。（否则，所有T-SQL事务都必须等待通过网络到辅助区域的往返。）
笔记
异步提交复制副本不支持自动故障切换。
注意事项
这些注意事项实现了Azure架构良好的框架的支柱，这是一套可用于提高工作负载质量的指导原则。有关详细信息，请参阅Microsoft Azure架构良好的框架。
可利用性
使用复杂的N层应用程序，您可能不需要在辅助区域中复制整个应用程序。相反，您可以只复制支持业务连续性所需的关键子系统。
Traffic Manager可能是系统中的一个故障点。如果Traffic Manager服务失败，客户端将无法在停机期间访问您的应用程序。查看Traffic Manager SLA，并确定单独使用Traffic Manager是否满足高可用性的业务要求。如果没有，请考虑添加另一个流量管理解决方案作为故障回复。如果Azure流量管理器服务失败，请更改DNS中的CNAME记录以指向其他流量管理服务。（此步骤必须手动执行，在传播DNS更改之前，您的应用程序将不可用。）
对于SQL Server群集，有两种故障切换方案需要考虑：
- 主区域中的所有SQL Server数据库副本都会失败。例如，这种故障可能发生在区域停电期间。在这种情况下，即使Traffic Manager在前端自动进行故障切换，您也必须手动对可用性组进行故障切换。请按照“对SQL Server可用性组执行强制手动故障切换”中的步骤进行操作，该部分介绍了如何在SQL Server 2016中使用SQL Server Management Studio、Transact-SQL或PowerShell执行强制故障切换。
警告
通过强制故障切换，存在数据丢失的风险。一旦主区域恢复在线，请获取数据库的快照，并使用tablediff查找差异。- Traffic Manager故障转移到辅助区域，但主SQL Server数据库副本仍然可用。例如，前端层可能会出现故障，而不会影响SQL Server虚拟机。在这种情况下，Internet流量被路由到辅助区域，并且该区域仍然可以连接到主复制副本。但是，会增加延迟，因为SQL Server连接是跨区域的。在这种情况下，您应该执行手动故障切换，如下所示：
- 临时将辅助区域中的SQL Server数据库复制副本切换到同步提交。此步骤可确保在故障切换过程中不会丢失数据。
- 故障转移到该复制副本。
- 当故障返回到主区域时，恢复异步提交设置。
可管理性
更新部署时，一次更新一个区域，以减少因配置错误或应用程序中的错误而导致全局故障的几率。
测试系统对故障的恢复能力。以下是一些需要测试的常见故障场景：
- 关闭VM实例。
- 压力资源，如CPU和内存。
- 断开/延迟网络。
- 崩溃过程。
- 证书过期。
- 模拟硬件故障。
- 关闭域控制器上的DNS服务。
测量恢复时间并验证它们是否满足您的业务需求。测试故障模式的组合。
成本优化
成本优化是指寻找减少不必要费用和提高运营效率的方法。有关更多信息，请参阅成本优化支柱概述。
使用Azure定价计算器来估计成本。以下是一些其他考虑因素。
虚拟机规模集
虚拟机规模集可用于所有Windows虚拟机大小。您只需对部署的Azure虚拟机以及所消耗的任何添加的底层基础设施资源（如存储和网络）收费。虚拟机规模集服务不收取任何增量费用。
有关单个虚拟机定价选项，请参阅Windows虚拟机定价。
SQL服务器
如果您选择Azure SQL DBaas，您可以节省成本，因为不需要配置始终可用性组和域控制器计算机。有几个部署选项，从单个数据库到托管实例或弹性池。有关更多信息，请参阅Azure SQL定价。
有关SQL服务器虚拟机定价选项，请参阅SQL虚拟机定价。
负载平衡器
您只会根据配置的负载平衡和出站规则的数量收费。入站NAT规则是免费的。在未配置规则的情况下，标准负载平衡器不收取每小时费用。
Traffic Manager定价
Traffic Manager计费基于收到的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架构良好的框架中的卓越运营部分。
Next steps
Related resources
The following architecture uses some of the same technologies:
- 5 次浏览