循序渐进：如何在Azure中的Windows Server 2008 R2上配置SQL Server 2008 R2故障转移群集实例

介绍

2019年7月9日，对SQL Server 2008和2008 R2的支持将结束。这意味着定期安全更新的结束。但是，如果将这些SQL Server实例移动到Azure，Microsoft将为您提供三年的扩展安全更新，无需额外费用。如果您当前正在运行SQL Server 2008/2008 R2并且在7月9日截止日期之前无法更新到SQL Server的更高版本，那么您将希望利用此优惠而不是冒着面临未来安全漏洞的风险。未修补的SQL Server实例可能导致数据丢失，停机或破坏性数据泄露。

在Azure中运行SQL Server 2008/2008 R2时将面临的挑战之一是确保高可用性。在本地，您可能正在运行SQL Server故障转移群集（FCI）实例以实现高可用性，或者您可能正在虚拟机中运行SQL Server，并且依赖VMware HA或Hyper-V群集来获取可用性。迁移到Azure时，这些选项都不可用。 Azure中的停机是非常可能的，您必须采取措施来缓解。

为了减少停机的可能性并获得Azure 99.95％或99.99％SLA的资格，您必须利用SIOS DataKeeper。DataKeeper克服了Azure缺乏共享存储的问题，并允许您在Azure中构建SQL Server FCI，利用每个实例上的本地连接存储。SIOS DataKeeper不仅支持本指南中记录的SQL Server 2008 R2和Windows Server 2008 R2，它支持从2008 R2到Windows Server 2019的任何版本的Windows Server以及从SQL Server 2008到SQL Server 2019的任何版本的SQL Server 。

本指南将介绍在Azure中创建在Windows Server 2008 R2上运行的双节点SQL Server 2008 R2故障转移群集实例（FCI）的过程。尽管SIOS DataKeeper还支持跨可用区或区域的群集，但本指南假设每个节点都位于同一个Azure区域，但位于不同的故障域中。将使用SIOS DataKeeper代替创建SQL Server 2008 R2 FCI通常所需的共享存储。

在Azure中创建第一个SQL Server实例

本指南将利用Azure Marketplace中发布的Windows Server 2008R2映像上的SQL Server 2008R2SP3。

配置第一个实例时，您必须创建新的可用性集。在此过程中，请确保将Fault Domains的数量增加到3。这允许两个群集节点和文件共享见证每个节点驻留在它们自己的故障域中。

为每个实例添加其他磁盘。建议使用Premium或Ultra SSD。禁用用于SQL日志文件的磁盘上的缓存。在用于SQL数据文件的磁盘上启用只读缓存。有关存储最佳实践的其他信息，请参阅Azure虚拟机中的SQL Server性能指南。

如果尚未配置虚拟网络，请允许创建向导为您创建新虚拟网络。

创建实例后，请进入IP配置并使专用IP地址静态。这是SIOS DataKeeper所必需的，也是群集实例的最佳实践。

确保将虚拟网络配置为将DNS服务器设置为本地Windows AD控制器。这是为了确保您能够在以后的步骤中加入域。

在Azure中创建结束SQL Server实例

按照上面的相同步骤。除了确保将此实例放在您使用第一个实例创建的同一虚拟网络和可用性集中。

创建文件共享见证（FSW）实例

为了使Windows Server故障转移群集（WSFC）以最佳方式工作，您需要创建另一个Windows Server实例并将其放在与SQL Server实例相同的可用性集中。通过将其置于同一可用性集中，可确保每个群集节点和FSW位于不同的故障域中。因此，如果整个故障域脱机，确保您的群集保持在线。此实例不需要SQL Server。它可以是一个简单的Windows Server，因为它需要做的就是托管一个简单的文件共享。

此实例将托管WSFC所需的文件共享见证。此实例不需要具有相同的大小，也不需要附加任何其他磁盘。它的唯一目的是托管一个简单的文件共享。它实际上可以用于其他目的。在我的实验室环境中，我的FSW也是我的域控制器。

卸载SQL Server 2008 R2

配置的两个SQL Server实例中的每一个都已经安装了SQL Server 2008 R2。但是，它们作为独立的SQL Server实例安装，而不是群集实例。在我们安装集群实例之前，必须从每个实例中卸载SQL Server。最简单的方法是运行SQL安装程序，如下所示。

运行setup.exe / Action-RunDiscovery时，您将看到所有预安装的内容 

setup.exe / Action-RunDiscovery

运行setup.exe / Action =卸载/ FEATURES = SQL，AS，RS，IS，工具/ INSTANCENAME = MSSQLSERVER启动卸载过程

setup.exe / Action = Uninstall / FEATURES = SQL，AS，RS，IS，Tools / INSTANCENAME = MSSQLSERVER

运行setup.exe / Action-RunDiscovery确认卸载已完成

setup.exe / Action-RunDiscovery

在第二个实例上再次运行此卸载过程。

将实例添加到域

所有这三个实例都需要添加到Windows域中。

添加Windows故障转移群集功能

需要将故障转移群集功能添加到两个SQL Server实例中

Add-WindowsFeature故障转移 - 群集

关闭Windows防火墙

为简单起见，请在安装和配置SQL Server FCI期间关闭Windows防火墙。有关保护Azure资源的建议，请参阅Azure网络安全最佳实践。可以在此处找到所需Windows端口的详细信息，此处的SQL Server端口和此处的SIOS DataKeeper端口，我们稍后将配置的内部负载均衡器还需要端口59999访问。因此，请务必在安全配置中考虑到这一点。

NetSh Advfirewall设置allprofiles状态

安装Windows Server 2008 R2 SP1的Convenience Rollup更新

为了在Azure中配置Windows Server 2008 R2实例，需要进行关键更新（kb2854082）。该更新以及更多内容包含在Windows Server 2008 R2 SP1的便捷汇总更新中。在每个SQL Server实例上安装此更新。

格式化存储

配置两个SQL Server实例时附加的其他磁盘需要格式化。对每个实例上的每个卷执行以下操作。

微软最佳实践说如下……

“NTFS分配单元大小：格式化数据磁盘时，建议您对数据和日志文件以及TempDB使用64 KB的分配单元大小。”

运行群集验证

运行集群验证以确保一切准备好进行集群。

您的报告将包含有关存储和网络的警告。您可以忽略这些警告，因为我们知道没有共享磁盘，并且服务器之间只存在单个网络连接。您可能还会收到有关网络绑定顺序的警告，该警告也可以忽略。如果您遇到任何错误，您必须在继续之前解决这些错误。

创建群集

在Azure中创建集群的最佳实践是使用Powershell，如下所示。Powershell允许我们指定静态IP地址，而GUI方法则不允许。不幸的是，Azure的DHCP实现与Windows Server Failover Clustering不兼容。如果您使用GUI方法，您将使用重复的IP地址作为群集IP地址。这不是世界末日，但你需要在我展示时解决这个问题。

正如我所说，Powershell方法通常效果最好。但是，出于某种原因，它似乎在Windows Server 2008 R2上失败，如下所示。

New-Cluster -Name cluster1 -Node sql1，sql2 -StaticAddress 10.1.0.100 -NoStorage

您可以尝试这种方法，如果它适合您 – 太棒了！我需要回过头来再研究一下，看看它是不是侥幸。如果Powershell不工作，我需要探索的另一个选项是Cluster.exe。运行cluster / create /？使用不推荐使用的cluster.exe命令提供用于创建集群的正确语法。

但是，如果Powershell或Cluster.exe使您失败，则以下步骤说明了如何通过Windows Server Failover Clustering UI创建群集，包括修复将分配给群集的重复IP地址。

请记住，您在此处指定的名称只是群集名称对象（CNO）。这不是SQL客户端用于连接群集的名称;我们将在稍后的步骤中定义SQL Server群集设置期间。 

此时，已创建群集，但由于重复的IP地址问题，您可能无法使用Windows Server Failover Clustering UI连接到群集。

修复重复的IP地址

如前所述，如果使用GUI创建集群，则无法为集群选择IP地址。由于您的实例配置为使用DHCP（Azure中需要），因此GUI希望使用DHCP自动为您分配IP地址。遗憾的是，Azure的DHCP实现无法按预期工作，并且群集将分配其中一个节点已使用的相同地址。虽然群集将正确创建，但在解决此问题之前，您将很难连接到群集。

要解决此问题，请从其中一个节点运行以下命令，以确保在该节点上启动群集服务。

净启动clussvc / fq

在同一节点上，您现在应该能够连接到Windows Server Failover Clustering UI，在那里您将看到IP地址无法联机。

打开群集IP地址的属性并将其从DHCP更改为静态，并为其分配未使用的IP地址。

将Name资源联机

添加文件共享见证

接下来我们需要添加文件共享见证。在我们配置为FSW的第三台服务器上，创建一个文件夹并共享它，如下所示。您需要在共享和安全级别授予群集名称对象（CNO）读/写权限，如下所示。

创建共享后，在其中一个群集节点上运行“配置群集仲裁”向导，然后按照以下步骤操作。

为DataKeeper创建服务帐户

我们几乎准备好安装DataKeeper。但是，在我们这样做之前，您需要创建一个Domain帐户并将其添加到每个SQL Server群集实例上的Local Administrators组。我们将在安装DataKeeper时指定此帐户。

安装DataKeeper

在两个SQL Server群集节点中的每个节点上安装DataKeeper，如下所示。

这是我们将指定我们添加到每个本地域管理员组的域帐户的位置。

配置DataKeeper

在两个群集节点中的每个节点上安装DataKeeper后，即可配置DataKeeper。

注 – 以下步骤中遇到的最常见错误与安全性相关，通常由预先存在的Azure安全组阻止所需端口。请参阅SIOS文档以确保服务器可以通过所需的端口进行通信。

首先，您必须连接到两个节点中的每一个。

如果一切配置正确，您应该在“服务器概述”报告中看到以下内容。

接下来，创建一个新工作并按照下面说明的步骤

在此处选择“是”以在“可用存储”中注册DataKeeper卷资源

为每个卷完成上述步骤。完成后，您应该在Windows Server故障转移群集UI中看到以下内容。

您现在已准备好将SQL Server安装到群集中。

注 – 此时，只能在当前托管可用存储的节点上访问复制卷。这是预期的，所以不要担心！

在第一个节点上安装SQL Server

在第一个节点上，运行SQL Server安装程序。

选择“新建SQL Server故障转移群集安装”，然后按照说明执行操作。

只选择您需要的选项。 

请注意，本文档假定您使用的是SQL Server的默认实例。如果使用命名实例，则需要确保锁定其侦听的端口，并在配置负载平衡器时使用该端口。您还需要为SQL Server Browser服务（UDP 1434）创建负载平衡器规则，以便连接到命名实例。本指南不涉及这两个要求。但是，如果您需要命名实例，那么如果您执行这两个额外步骤，它将起作用。

在这里，您需要指定一个未使用的IP地址

转到“数据目录”选项卡并重定位数据和日志文件。在本指南的最后，我们将讨论将tempdb重定位到非镜像DataKeeper卷以获得最佳性能。现在，只需将其保留在其中一个群集磁盘上即可。

在第二个节点上安装SQL

在第二个节点上再次运行SQL Server安装程序。然后，选择“将节点添加到SQL Server故障转移群集”。

恭喜你，差不多完成了！但是，由于Azure缺乏对免费ARP的支持，我们需要配置内部负载均衡器（ILB）以协助客户端重定向，如以下步骤所示。

更新SQL群集IP地址

为了使ILB正常运行，必须从其中一个集群节点运行以下命令。SQL Cluster IP使SQL Cluster IP地址能够响应ILB运行状况探测，同时还将子网掩码设置为255.255.255.255，以避免IP地址与运行状况探测冲突。

cluster res <IPResourceName> / priv enabledhcp = 0 address = <ILBIP> probeport = 59999 subnetmask = 255.255.255.255

注意 – 我不知道它是不是侥幸。有时候我运行了这个命令，它看起来很有效，但它没有完成工作，我必须重新开始。我可以判断它是否有效的方法是查看SQL Server IP资源的子网掩码。如果它不是255.255.255.255那么你知道它没有成功运行。 它可能只是一个GUI刷新问题。请尝试重新启动群集GUI以验证子网掩码是否已更新。

成功运行后，使资源脱机并将其重新联机以使更改生效。

创建负载均衡器

最后一步是创建负载均衡器。在这种情况下，我们假设您正在运行SQL Server的默认实例，侦听端口1433。

创建负载均衡器时定义的专用IP地址将与SQL Server FCI使用的地址完全相同。

仅将两个SQL Server实例添加到后端池。不要将FSW添加到后端池。

在此负载平衡规则中，您必须启用浮动IP。

测试群集

最简单的测试是在被动节点上打开SQL Server Management Studio并连接到群集。恭喜！你连接时你做的一切都正确！如果你无法连接，不要害怕。我写了一篇博客文章来帮助解决问题。管理群集与管理传统共享存储群集完全相同。一切都通过故障转移群集管理器控制。

可选 – 重定位TempDB

为获得最佳性能，建议将tempdb移至本地非复制SSD。但是，SQL Server 2008 R2要求tempdb位于群集磁盘上。SIOS有一个称为非镜像卷资源的解决方案，可以解决这个问题。建议创建本地SSD驱动器的非镜像卷资源并在那里移动tempdb。请注意，本地SSD驱动器是非持久性的。您必须注意确保每次服务器重新启动时都会重新创建包含tempdb的文件夹和该文件夹的权限。

在创建本地SSD的非镜像卷资源后，请按照本文中的步骤重新定位tempdb。必须将该文章中描述的启动脚本添加到每个群集节点。

经Clusteringformeremortals.com许可转载