通过

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

针对 HA/DR 生成的多层 Web 应用程序

Azure
Azure Arc
SQL Server
Windows

本示例方案适用于需要部署可实现高可用性和灾难恢复的可复原多层应用程序的任何行业。 在本方案中，应用程序由三个层组成。

  • Web 层：包含用户界面的最上层。 此层分析用户交互，并将操作传递到下一层进行处理。
  • 业务层：处理用户交互，并针对后续步骤做出逻辑决策。 此层连接 Web 层和数据层。
  • 数据层：存储应用程序数据。 通常使用数据库、对象存储或文件存储。

常见应用程序方案包括 Windows 或 Linux 上运行的任何任务关键型应用程序。 这可能是现成的应用程序（例如 SAP 和 SharePoint），也可能是自定义的业务线应用程序。

可能的用例

其他相关用例包括：

  • 部署 SAP 和 SharePoint 等高度可复原的应用程序
  • 为业务线应用程序设计业务连续性和灾难恢复计划
  • 配置灾难恢复并出于合规目的执行相关的演练

体系结构

该图显示了高度可复原的多层 Web 应用的体系结构概述。

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

Workflow

  • 在支持局部区域的区域中，将每个层中的 VM 分布在两个可用性区域之间。 在其他区域，将每个层中的 VM 部署到一个可用性集内。
  • 可以将数据库层配置为使用 Always On 可用性组。 使用此 SQL Server 配置，可用性组中的一个主要读/写副本最多配置八个辅助只读副本。 如果主要副本出现问题，可用性组会将主要读/写活动故障转移到辅助副本之一，从而使应用程序保持可用状态。 有关详细信息，请参阅适用于 SQL Server 的 Always On 可用性组概述。
  • 对于灾难恢复方案，可以配置 SQL Always On 异步本机复制，以复制到用于灾难恢复的目标区域。 还可以配置 Azure Site Recovery 复制，以便在数据更改率处于 Azure Site recovery 支持的限制范围内时复制到目标区域。
  • 用户通过流量管理器终结点访问前端 ASP.NET Web 层。
  • 流量管理器将流量重定向到主要源区域中的主要公共 IP 终结点。
  • 公共 IP 通过公共负载均衡器将调用重定向到某个 Web 层 VM 实例。 所有 Web 层 VM 实例位于一个子网中。
  • 在 Web 层 VM 中，每个调用将通过内部负载均衡器路由到业务层中的某个 VM 实例进行处理。 所有业务层 VM 位于独立的子网中。
  • 操作将在业务层中进行处理，ASP.NET 应用程序通过 Azure 内部负载均衡器连接到后端层中的 Microsoft SQL Server 群集。 这些后端 SQL Server 实例位于独立的子网中。
  • 流量管理器的辅助终结点配置为用于灾难恢复的目标区域中的公共 IP。
  • 如果主要区域发生中断，则你可以调用 Azure Site Recovery 故障转移，应用程序将在目标区域中变为活动状态。
  • 流量管理器终结点自动将客户端流量重定向到目标区域中的公共 IP。

组件

  • 可用性集 是一项容错功能，可确保 VM 分布在群集中的多个独立硬件节点之间。 在此体系结构中，可用性集通过确保只有一部分 VM 在中断期间受到影响来保护硬件和软件故障。 此方法维护多层应用程序的应用程序可用性和作连续性。

  • 可用性区域 是 Azure 区域中的单独物理位置，可保护应用程序和数据免受数据中心故障的影响。 在此体系结构中，可用性区域通过独立电源、冷却和网络基础结构跨多个数据中心分配 VM 来提供更高的复原能力。

  • Azure 负载均衡器 是一个第 4 层负载均衡器，它根据定义的规则和运行状况探测分配入站流量，以确保高吞吐量和低延迟。 在此体系结构中，公共负载均衡器将传入客户端流量分布到 Web 层 VM，而内部负载均衡器将流量从 Web 层路由到业务层，从业务层路由到后端 SQL Server 群集。

  • Azure 流量管理器 是基于域名系统（DNS）的流量负载均衡器，用于跨全球 Azure 区域分配流量。 在此体系结构中，流量管理器通过在正常作期间将用户流量路由到主要区域，并在中断期间自动将流量重定向到灾难恢复区域，从而提供全局负载均衡。

  • Site Recovery 是一种灾难恢复服务，允许 VM 复制到另一个 Azure 区域，实现业务连续性和灾难恢复。 在此体系结构中，Site Recovery 通过将 VM 复制到目标区域，以便在源区域中断期间进行应用程序恢复，从而启用灾难恢复功能。 它还通过定期灾难恢复演练支持合规性要求。

备选方法

  • 可以使用其他操作系统来替换 Windows，因为基础结构中没有任何组件依赖于操作系统。
  • SQL Server for Linux 可替代后端数据存储。
  • 可以使用任何可用的标准数据库应用程序替换数据库。

方案详细信息

本方案演示一个使用 ASP.NET 和 Microsoft SQL Server 的多层应用程序。 在支持可用性区域的 Azure 区域中，可以在跨可用性区域的源区域中部署虚拟机 (VM)，并将 VM 复制到用于灾难恢复的目标区域。 在不支持可用性区域的 Azure 区域中，可在可用性集内部署 VM，并将 VM 复制到目标区域。

若要在区域之间路由流量，需要一个全局负载均衡器。 有两种主要的 Azure 产品/服务：

  • Azure Front Door
  • Azure 流量管理器

选择负载均衡器时，请考虑你的要求和这两款产品/服务的功能集。 你希望以多快的速度进行故障转移？ 你能否承担 TLS 管理的开销？ 是否有任何组织成本约束？

Front Door 提供第 7 层功能（SSL 卸载、基于路径的路由、快速故障转移、缓存等），来提高应用程序的性能和高可用性。 由于基础结构更快地加入 Azure 网络，数据包传输时间可能更短。

Front Door 添加了一个新跃点，因此增加了安全操作。 如果体系结构符合法规要求，则可能有关于其他流量 TLS 终止点的限制。 Front Door 选择的 TLS 密码套件必须满足你组织的安全要求。 此外，Front Door 还要求后端服务使用属于 Microsoft受信任 CA 列表一部分的证书。

另一个考虑因素是成本。 体系结构应利用广泛的功能集（而不仅仅是故障转移）来证明增加的成本是合理的。

流量管理器是基于 DNS 的负载均衡服务。 它仅在 DNS 级别进行均衡和故障转移。 出于此原因，它无法像 Front Door 一样快速进行故障转移，因为存在 DNS 缓存和系统不采用 DNS TTL 的常见挑战。

如果需要，可合并这两个负载均衡器。 例如，你需要基于 DNS 的故障转移，但希望在该流量管理的基础结构前面添加 POP 体验。

此体系结构使用流量管理器，因为它是轻量级的。 故障转移计时已足够用于演示目的。

注意事项

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

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅可靠性设计审查检查表。

进入前端应用层的所有虚拟网络流量受网络安全组的保护。 规则会限制流量的流动，只有前端应用程序层 VM 实例可以访问后端数据库层。 不允许业务层或数据库层发出的出站 Internet 流量。 为了减少受攻击面，请勿打开直接远程管理端口。 有关详细信息，请参阅 Azure 网络安全组。

若需安全方案的通用设计指南，请参阅 Azure 安全性文档。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。

使用 Azure Site Recovery 为 Azure VM 配置灾难恢复会持续产生以下费用。

  • 每个 VM 的 Azure Site Recovery 许可费用。
  • 将数据更改从源 VM 磁盘复制到另一个 Azure 区域时产生的网络出口费用。 Azure Site Recovery 使用内置压缩，可将数据传输要求减少约 50%。
  • 恢复站点上的存储费用。 此存储通常相当于源区域存储加上将恢复点保留为恢复快照所需的任何附加存储。

我们提供了一个示例成本计算器，用于计算使用六个虚拟机为某个三层应用程序配置灾难恢复所需的费用。 成本计算器中已预配置所有服务。 若要了解特定用例的定价变化情况，请更改相应的变量来估算费用。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅性能效率设计评审核对清单。

可以根据缩放要求，在每个层中添加或删除 VM。 由于本方案使用负载均衡器，因此你可以在某个层中添加更多的 VM，而不会影响应用程序的运行时间。

作者

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

主要作者：

后续步骤

有关其他高可用性和灾难恢复体系结构，请参阅：