亚马逊AWS官方博客

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

Original URL:https://aws.amazon.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部署优化的更多系列文章。

 

本篇作者

Anup Sivadas

Amazon Web Services公司解决方案架构师。他与AWS客户联手为AWS服务架构的实际使用提供指导与技术帮助,引导客户在实施AWS解决方案时获得更高的价值回报。