如何在Google Cloud中创建Microsoft SQL Server故障转移群集

Dave Bermingham是 SIOS Technology 的Microsoft云和数据中心管理MVP 。

尽管云在许多（即使不是大多数）企业应用程序中继续流行，但是IT部门仍然不愿意将关键云（包括Google Cloud Platform）用于关键业务Microsoft SQL Server应用程序。 他们的主要担心是，在高可用性群集配置通常不如私有企业云更健壮，更昂贵的环境中，运行Microsoft SQL Server以及可选的Microsoft Windows Server故障转移群集（WSFC）的风险和复杂性增加。

SQL Server的问题之一是需要对Always On故障转移群集实例使用共享存储。 这是一个有两个原因的问题。 首先，在Google Cloud Platform中无法使用存储区域网络（SAN）形式的共享存储。 其次，共享任何东西都会在没有完全冗余的情况下造成单点故障。

[入门： Azure云迁移指南 。 •教程： Google Cloud入门 。 | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

克服此类限制的一种方法涉及在Google Cloud中实现第三方故障转移群集软件。 当设计为支持SQL Server时，故障转移群集将创建易于管理的高性能，高可用性环境。

Google Cloud中SQL Server高可用性的限制

与其他云服务一样，Google Cloud Platform为许多需要高可用性的应用程序提供应用程序故障转移功能。 这些服务通过将数据从主实例复制到不同区域中的一个或多个副本实例来工作，这些区域通常位于不同的数据中心，以防止本地灾难。 如果应用程序的主实例发生故障，则高可用性设置将故障转移到副本实例。

在Google Cloud（撰写本文时）中，标准的高可用性规定具有以下五个限制：

• 通常仅由区域中断触发故障转移，这只是应用程序失败的众多原因之一。
• 每个主服务器只能创建一个故障转移副本，从而创建一个故障点。
• 必须使用主数据集执行备份，从而不可避免地要进行计划内的停机。
• 使用事件日志复制数据会造成“复制滞后”，从而导致故障转移期间的临时中断。
• 该服务当前仅支持MySQL和PostgreSQL，但不支持SQL Server。

尽管这些限制作为某些应用程序的灾难恢复策略的一部分是可以接受的，但对于任务关键型SQL Server应用程序却是不可接受的。 为了支持公共，私有和混合云中的高可用性，SQL Server提供了自己的解决方案以及企业版中的Always On可用性组。 但是，这种高级功能的价格也无法为许多数据库应用程序辩护。

SQL Server Standard Edition包括Always On故障转移群集，该群集利用了操作系统内置的Windows Server故障转移群集。 虽然可以使其在Google Cloud中正常运行，但它要求使用第三方无SAN故障转移群集来代替SAN，并允许在故障转移群集中使用本地连接的存储。

将无SAN的故障转移群集添加到Google Cloud

无需SAN的故障转移群集软件专门用于创建其名称所暗示的内容：与存储无关，无共享的服务器和存储群集，并具有自动故障转移功能以实现应用程序可用性。 作为高可用性解决方案，无SAN群集能够在私有，公共和混合云中的LAN和WAN上运行。 这些集群也是可扩展的，从而使组织可以在大多数应用程序中使用单个通用的高可用性解决方案。

大多数无SAN故障转移群集软件都提供了实时，块级数据复制，连续应用程序监视以及可配置的故障转移/故障回复恢复策略的组合，以保护关键业务应用程序，包括那些使用SQL中的Always On Failover Clustering功能的应用程序服务器标准版。

一些更强大的无SAN故障转移群集解决方案还提供高级功能，例如通过直观的图形用户界面简化配置和操作，选择同步或异步复制，使性能最大化的WAN优化，主备数据库的手动切换服务器分配以进行计划内的维护，并执行常规备份而不会中断应用程序。

在Google Cloud中配置SQL Server故障转移群集实例

本节概述了用于跨Google Cloud Platform基于区域的基础架构配置简单的两台服务器故障转移群集的过程。 使用相同的基本过程，涉及三个或更多服务器的配置也是可能的。

该示例使用SIOS DataKeeper群集版本创建了无SAN故障转移群集。 SIOS DataKeeper使用块级复制来确保每个SQL实例上本地连接的存储保持同步。 SIOS DataKeeper还通过其自己的称为DataKeeper卷的存储类资源与Windows Server故障转移群集集成，该资源代替了物理磁盘资源。 在群集中，DataKeeper卷似乎是物理磁盘，但它不控制SCSI保留，而是控制镜像方向，从而确保仅主动服务器写入磁盘，而被动服务器则同步或接收所有更改。异步地。

下图显示了配置为虚拟私有云（VPC）的无SAN故障转移群集的体系结构。 在美国中部地区的不同区域（1-A和1-B）中有两个SQL Server节点。 在Windows群集中配置仲裁所需的文件共享见证由美国中部1-C区的域控制器执行。 将仲裁的每个实例保留在不同的区域中，可以避免整个区域离线时丢失多于一票的可能性。 还显示了将在后续步骤中配置的VPC的节点名称，IP地址和子网值。

操作系统

此处显示的是Google虚拟私有云的无SAN故障转移群集的最终配置。

在Google云端中创建故障转移群集的方式与在私有云中创建故障转移群集的方式几乎相同，但有一个重要区别：由于GCP的原因，您不能使用具有单个虚拟IP地址的单个子网在群集节点之间移动缺乏对免费ARP（地址解析协议）的支持。 可以通过遵循此处概述的过程来解决此限制，该过程将每个节点放置在不同的子网中，然后为群集IP地址创建特定于主机的路由。 请注意，该讨论假定读者熟悉Google Cloud和IP地址子网划分。

步骤＃1：创建VPC网络和故障转移群集实例

在此示例中，名为WSFCNET的VPC在三个不同的区域（10.0.0.0/24、10.1.0.0/24和10.2.0.0/24）中具有三个子网：WSFCSUBNET1，WSFCSUBNET2和WSFCSUBNET3，用于SQL1，SQL2和DC1。 ， 分别。 使用Google Cloud Platform控制台，最初会为每个节点分配一个静态IP地址，并在/ 24子网中进行转发； 但是，我们将所有SQL节点更改为/ 16子网掩码，以支持特定于主机的路由。 此步骤还涉及创建防火墙规则以允许VPC节点之间进行通信。

这是用于创建WSFCSUBNET1的命令：

gcloud compute networks subnets create wsfcsubnet1 --network wsfcnet \
 --region us-central1 --range 10.0.0.0/24

SQL1和SLQ2故障转移群集实例使用预装有SQL Server的标准Windows Server 2016映像，但是在步骤3中创建基本群集之后，需要将SQL Server软件重新安装为群集实例。 DC实例还使用标准的Windows Server 2016映像。

步骤2：更新IP地址和路由

连接DC1并将其指定为域控制器后，使用netsh命令更改SQL Server实例的IP地址，使其具有/ 16子网掩码以支持特定于主机的路由。 netsh命令还用于设置DNS地址。 然后，使用Google Cloud Platform控制台上的gcloud compute routes create命令创建四个路由，同时包含用于SQL1和SQL2的路由以及路由侦听器。

以下是用于更新SQL1地址的命令：

netsh interface ip set address name=ethernet static 10.0.0.4 255.255.0.0 10.0.0.1 1
netsh interface ip set dns ethernet static 10.2.0.100

以下是用于为SQL1创建路由和路由侦听器的命令：

gcloud compute routes create cluster-sql1-route --network wsfcnet \
--destination-range 10.0.1.4/32 --next-hop-instance sql1 \
--next-hop-instance-zone us-central1-a --priority 1
gcloud compute routes create cluster-sql1-route-listener
--network wsfcnet \
--destination-range 10.0.1.5/32 --next-hop-instance sql1 \
--next-hop-instance-zone us-central1-a --priority 1

步骤＃3：创建集群

使用指定的IP地址和路由，通过运行PowerShell命令以启用故障转移群集以及验证和创建群集（同时指定其名称和成员节点IP地址）来创建群集。 创建群集后，将更改仲裁属性和权限以在DC1上创建文件共享，并为群集节点提供共享和NTFS级别的读/写权限。

这是用于在两个SQL节点上启用故障转移群集功能的PowerShell命令：

Install-WindowsFeature Failover-Clustering –IncludeManagementTools 

然后使用此PowerShell命令来验证集群：

Test-Cluster -Node sql1, sql2 

最后，通过从SQL1或SQL2运行New-Cluster命令来创建New-Cluster ：

New-Cluster -Name cluster1 –Node sql1,sql2 -NoStorage -StaticAddress 10.0.1.4,10.1.1.4

在DC1上创建文件共享后，使用以下PowerShell命令添加文件共享见证：

Set-ClusterQuorum -NodeAndFileShareMajority \\dc1\quorum 

步骤＃4：安装SQL Server实例

最后一步涉及在故障转移群集的两个节点（SQL1和SQL2）上安装SQL Server软件。 此步骤还涉及配置SIOS DataKeeper以在服务器实例之间复制本地连接的磁盘，以及在故障转移群集中注册DataKeeper卷资源。 同步复制通常用于Google Cloud Platform区域内的镜像，如本示例所示。 在单独区域中的第三个节点进行镜像将使用异步复制。

当然，细节始终是魔鬼，而配置Google Cloud VPC以进行故障转移群集所涉及的完整细节不在本文讨论范围之内。 SIOS白皮书“ 如何使用SIOS DataKeeper在Google Cloud Platform中构建无SAN的SQL Server故障转移群集实例 ”中提供了完整的分步说明，包括完整的详细命令和屏幕截图。 尽管某些屏幕和设置特定于SIOS DataKeeper，但配置要求完全适用于任何SQL Server故障转移群集解决方案。

David Bermingham是一位高可用性专家，他是八年微软MVP，六年是集群MVP，两年是云和数据中心管理MVP。 David在SIOS Technology担任主管的工作使他专注于宣传Microsoft高可用性和灾难恢复解决方案，并为群集实现提供了动手支持，培训和专业服务。 通过David.Bermingham@us.sios.com向David 发送电子邮件，并在us.sios.com和www.ClusteringforMereMortals.com上了解更多信息 。

-

新技术论坛提供了一个以前所未有的深度和广度探索和讨论新兴企业技术的场所。 选择是主观的，是基于我们对InfoWorld读者认为最重要和最感兴趣的技术的选择。 InfoWorld不接受发布的营销担保，并保留编辑所有贡献内容的权利。 将所有查询发送到 newtechforum@infoworld.com 。

From: https://www.infoworld.com/article/3278666/how-to-create-a-microsoft-sql-server-failover-cluster-in-the-google-cloud.html