使用分布式可用性组实现多区域 SQL Server 部署

Original URL：https://thinkwithwp.com/cn/blogs/database/multi-region-sql-server-deployment-using-distributed-availability-groups/

在与客户的合作当中，SQL Server的多区域架构总是个有趣的话题。客户之所以希望在SQL Server部署当中采用多区域架构，根本原因在于：

• 业务连续性与灾难恢复。
• 服务于地理分布广泛的客户群体，并改善最终用户的延迟体验。

在本文中，我们将了解如何以有效的设计跨越两个甚至更多AWS区域，建立并部署高可用的SQL Server架构模式。此外，您还将了解如何使用多区域方法扩展读取工作负载，并改善全球分布的最终用户的延迟体验。

架构：传统与优化

本文将讨论两种架构选项：作为传统方案的多区域Always On可用性组，以及作为最佳方案的多区域分布式可用性组。

多区域Always On可用性组

使用传统方法，我们可以建立起区域间VPC对等连接，跨两个区域建立单一Windows Server故障转移集群（WSFC），也可以使用来位于这两个区域内的节点构建起Always On可用性组。下图所示，即为这样一套架构体系。

在这套架构中，区域A负责托管主副本。同步辅助副本同样位于区域A内。二者的区别在于，主副本位于区域A的可用区1中，同步辅助副本则位于可用区2中。副本之间保持数据传输同步，并配合自动故障转移以建立故障转移模式。一旦可用区1发生连接故障或者其他问题，自动故障转移将立即起效，将可用区2节点设为主副本。在基本原理方面，这种分布式架构与服务器Always On可用性组中单一数据库发生故障时的情况并无太大不同。

最佳实践建议，应用程序应该通过Always On可用性组的监听器配合最新的受支持驱动程序及关键参数（例如 MultiSubNetFailover=True）实现接入，借此促进故障转移，并保证应用程序以无缝方式对接新副本（且不存在任何错误或超时）。此外，我们还需要考虑与仲裁相关的设置，这部分内容将在后文中具体介绍。

架构中的区域B则被视为辅助区域。我们在该区域中配置有第二及第三个辅助副本，并与托管在区域A中的主副本保持异步同步。由于使用了异步数据传输模式，故障转移模式配置为手动。我们推荐在区域之间采取异步传输通信方法。如果区域A中发生灾难性区域故障，则可执行手动故障转移操作，而应用程序则可通过可用性组监听器接入区域B中新近提升的主副本。

这种方法的主要缺点之一，源自区域B内辅助副本的数据同步层面。区域A中的主副本负责为所有辅助副本提供数据源，而对于区域B中的所有辅助副本，主副本必须通过网络向其分别发送数据。这种重复进行的数据传输可能会增加总体数据传输费用，因此有违成本优化策略。

一种可行的解决办法，就是保证辅助区域B中只存在一个节点，并仅在发生区域故障转移时添加新的节点。另一个缺点则与安全性有关：当我们跨区域跨WSFC时，必须为安全组开启大量端口，其中包括用于集群服务的TCP/UDP端口、用于RPC的TCP端口、用于集群管理器的UDP、ICMP、用于SMB的TCP以及随机分配的高UDP端口等等。这自然会给内部安全团队带来巨大的工作压力。关于这些端口的更多详细信息，请参阅Windows支持网站上的Windows服务概述与网络端口要求。

多区域分布式可用性组

在多区域SQL Server部署当中，分布式可用性组架构堪称优化实现方法。分布式可用性组是一种特殊的可用性组类型，其直接跨越两个单独的可用性组。您可以将其视为可用性组的可用性组。其中的基础可用性组将通过两个不同的WSFC集群配置完成。

您也可以使用分布式可用性方法设计出一套混合型SQL Server部署架构，其中各SQL Server节点分别被部署在本地数据中心与AWS当中。关于更多详细信息，请参阅如何使用分布式可用性组构建混合型微软SQL Server解决方案。

下图所示，为多区域分布式可用性组架构。

在这套架构中，区域A负责托管主副本。架构中将存在一套与区域A对应的标准WSFC集群，名为WSFC1，且此集群无需像传统架构那样进行跨区域部署。同步辅助副本同样被托管在区域A内，但最好与主副本分属不同的可用区。主副本位于区域A的可用区1中，同步辅助副本则位于可用区2中。这两个整合都属于名为AG1的独立可用性组的组成部分。副本之间的数据以同步形式传输，且由自动故障转移功能作为故障转移模式。一旦发生故障，自动故障转移将立即启动并将可用区2节点提升为主副本。

最佳实践建议，应用程序应该通过Always On可用性组的监听器配合最新的受支持驱动程序及关键参数（例如 MultiSubNetFailover=True）实现接入，借此促进故障转移，并保证应用程序以无缝方式对接新副本（且不存在任何错误或超时）。此外，我们还需要考虑与仲裁相关的设置，这部分内容将在后文中具体介绍。

架构中的区域B则被视为辅助区域。我们在该区域中配置有第二个辅助副本，其与托管在区域A中的主副本保持异步同步。我们将这套副本命名为forwarder（转发副本）Forwarder是个全新的概念，也是分布式可用性组的核心功能之一。Forwarder负责同步区域B中的各其他副本。

Forwarder的存在，亦是这套优化架构中的关键优势之一。区域A中的主副本只需要将数据异步发送至forwarder，而forwarder又进一步将数据同步或异步发送至区域B中的其他副本。这就减少了存在多个节点时，从区域A到区域B的总体数据传输量；而且由于WSFC1与WSFC2属于相互独立的集群，我们也就不再需要开启大量端口，这将极大降低由此带来的安全风险。

读取扩展

您还可以进一步扩展分布式可用性组架构，以在区域B当中提供更多读取副本。更重要的是，如果您的两个不同区域都需要响应应用程序用户，那么用户将可以直接通过与自身地理距离更短的区域实现数据读取，从而改善读取SQL查询的延迟表现。下图所示为这套架构方案。

这套架构为区域B配置了三个额外副本。Forwarder负责对这三个副本进行数据同步。您也可以使用其他副本实现读取扩展。每个可用性组可支持1个主副本与最多8个辅助副本。在本质上，使用这套配置，您最多可以支持18个读取副本。

如果您希望为SQL Server构建一套更简单的高可用性单区域部署体系，也可以选择使用AWS Launch Wizard for SQL Server。AWS Launch Wizard for SQL Server是一套简单、直观且可免费使用的向导工具，可帮助您在AWS上轻松快捷地部署高可用性SQL Server解决方案。该向导中提供丰富的说明性引导，详尽阐述如何在Always On可用性组上建立起端到端部署。借助AWS Launch Wizard，您可以指定从SQL Server节点设置到AMI、再到Virtual Private Cloud（VPC）、Active Directory（AD）以及EC2实例等多种应用程序组件，借此轻松建立起可满足生产需求的部署方案。

注意事项

在选择部署策略时，您应仔细考虑带宽、仲裁设置与自动种子设定。

带宽

在多区域部署当中，带宽无疑是一项关键性考量因素。例如，如果您使用美国东部（北弗吉尼亚州）与美国西部（俄勒冈州）区域的分布式可用性组建立起多区域SQL Server部署，那么这两个区域之间的网络延迟一般在75到80毫秒范围内。如果您的工作负载属于高OLTP系统，则需要进行压力测试与性能基准测试，以确保辅助区域内辅助副本在同步过程中不会造成过高的延迟。一旦发生过高延迟，您的恢复点目标（RPO）SLA将受到不利影响。

仲裁设置

对于分布式可用性组，由于我们拥有两个不同的WSFC集群，因此需要分别处理其仲裁设置。您必须根据节点数量设置法定投票数。这里建议您选择文件共享见证作为见证类型，并使用全托管服务Amazon FSx for Windows File Server支持文件共享见证中的具体要求。

您也可以使用Amazon FSx来设计Always On故障转移集群实例（FCI）。若需了解更多详细信息，请参阅利用Amazon FSx for Windows File Server简化微软SQL Server高可用性部署。

自动种子设定

SQL Server 2016为可用性组引入了自动种子设定。在使用自动种子设定               创建可用性组时，SQL Server会自动为组内的各个数据库创建辅助副本。您不再需要手动备份及还原这些辅助副本。如果您处理的数据库集相对较少，那么这项功能将非常便捷好用。但如果您面对的数据库规模较大，我们不建议您使用自动种子设定。关于自动种子设定的更多详细信息，请参阅微软说明文档网站上的使用自动种子设定初始化Always On可用性组。

总结

在关键任务SQL Server的部署当中，多区域策略将成为决定项目成败的关键。本文的重点在于讲解如何使用分布式可用性组更好地实现这一目标。通过本文，您还了解到这种架构的其他优势，例如通过分布式可用性组实现读取副本的横向扩展等。

也欢迎继续关注SQL Server部署优化的更多系列文章。

本篇作者