如何在Azure中配置SQL Server 2008 R2故障转移群集实例

配置Azure实例
我不会在这里详细介绍一些屏幕截图，特别是由于Azure门户UI常常会常常更改，因此我拍摄的任何屏幕截图都会很快变得陈旧。相反，我将只介绍您应该了解的重要主题。

故障域或可用区？
为了确保您的SQL Server实例具备高可用性，您必须确保您的群集节点位于不一样的故障域（FD）或不一样的可用区（AZ）中。您的实例不只须要驻留在不一样的FD或AZ中，并且您的文件共享见证（见下文）也须要驻留在与您的群集节点所在的FD或AZ不一样的FD或AZ中。

这是个人见解。AZ是最新的Azure功能，但到目前为止它们仅在少数几个地区获得支持。AZ提供比FD（99.95％）更高的SLA（99.99％），并保护您免受我在个人帖子Azure Outage Post-Mortem中描述的那种云中断 。若是您能够在支持AZ的区域中部署，那么我建议您使用AZ。

在本指南中，我使用了AZ，当您进入有关配置负载均衡器的部分时，您会看到它们。可是，若是使用FD，除了负载均衡器配置将引用可用性集而不是可用区以外，一切都将彻底相同。

你问什么是文件共享见证？
Windows Server故障转移群集（WSFC）要求您配置“见证”以确保故障转移正常运行，而无需详细说明。WSFC支持三种见证：磁盘，文件共享和云。因为咱们在Azure中，所以没法使用磁盘见证。Cloud Witness仅适用于Windows Server 2016及更高版本，所以咱们可使用文件共享见证。若是您想了解有关群集仲裁的更多信息，请查看Microsoft Press博客上的帖子，来自MVP：了解Windows Server 2012 R2中的Windows Server故障转移群集仲裁。

将存储添加到SQL Server实例
在配置SQL Server实例时，您须要为每一个实例添加其余磁盘。最低限度，您须要一个磁盘用于SQL数据和日志文件，一个磁盘用于Tempdb。在云中运行时，是否应该为日志和数据文件设置单独的磁盘有些争议。在后端，存储所有来自同一个地方，您的实例大小限制了您的总IOPS。在我看来，分离日志和数据文件确实没有任何价值，由于您没法确保它们在两个物理磁盘集上运行。我会留给你决定，但我把日志和数据所有放在同一卷上。

一般，SQL Server 2008 R2 FCI会要求您将tempdb放在群集磁盘上。可是，SIOS DataKeeper有一个很是好的功能，称为DataKeeper非镜像卷资源。本指南不包括将tempdb移动到此非镜像卷资源，但为了得到最佳性能，您应该执行此操做。真的没有理由复制tempdb，由于它不管如何都是在故障转移时从新建立的。

就存储而言，您可使用任何存储类型，但必须尽量使用托管磁盘。确保群集中的每一个节点都具备相同的存储配置。启动实例后，您将须要附加这些磁盘并将它们格式化为NTFS。确保每一个实例使用相同的驱动器号。

联网
这不是一项艰难的要求，但若是可能的话，请使用支持加速网络的实例大小。此外，请确保在Azure门户中编辑网络接口，以便您的实例使用静态IP地址。要使群集正常工做，您须要确保更新DNS服务器的设置，使其指向Windows AD / DNS服务器而不只仅是某个公共DNS服务器。

安全
默认状况下，同一虚拟网络中的节点之间的通讯是敞开的，但若是您已锁定Azure安全组，则须要知道必须在群集节点之间打开哪些端口并调整安全组。根据个人经验，在Azure中构建群集时遇到的几乎全部问题都是由阻塞的端口引发的。

DataKeeper有一些端口须要在群集实例之间打开。这些端口以下：

UDP：137,138
TCP：139,445,9999，以及10000到10025范围内的端口
故障转移群集有本身的一组端口要求，我甚至不会尝试在此处进行记录。这篇文章彷佛涵盖了这一点。

此外，稍后描述的Load Balancer将使用必须容许每一个节点上的入站流量的探测端口。本指南中经常使用和描述的端口是59999。

最后，若是您但愿您的客户端可以访问您的SQL Server实例，您须要确保您的SQL Server端口是打开的，默认状况下是1433。

请记住，Windows防火墙或Azure安全组能够阻止这些端口，所以请务必检查这两个端口以确保它们可访问。

加入域名
SQL Server 2008 R2 FCI的要求是实例必须驻留在同一Windows Server域中。所以，若是您尚未这样作，请确保已将实例加入Windows域。

本地服务账户
安装DataKeeper时，它会要求您提供服务账户。您必须建立域用户账户，而后将该用户账户添加到每一个节点上的本地管理员组。在DataKeeper安装期间询问时，请将该账户指定为DataKeeper服务账户。注意：暂时不要安装DataKeeper！

域全局安全组
安装SQL 2008 R2时，系统会要求您指定两个全局域安全组。您可能但愿展望SQL安装说明并当即建立这些组。您还须要建立域用户账户并将其放在每一个安全账户中。您将指定此账户做为SQL Server群集安装的一部分。

其余先决条件
您必须在两个群集实例的每一个实例上启用故障转移群集和.Net 3.5。启用故障转移群集时，还要确保启用可选的“故障转移群集自动化服务器”，由于Windows Server 2012 R2中的SQL Server 2008 R2群集是必需的。

建立Cluster和DataKeeper卷资源
咱们如今准备开始构建集群。第一步是建立基本群集。因为Azure处理DHCP的方式，咱们必须使用Powershell建立集群，而不是集群UI。咱们使用Powershell，由于它容许咱们在建立过程当中指定静态IP地址。若是咱们使用UI，则会看到VM使用DHCP，而且它会自动分配重复的IP地址，所以咱们但愿经过使用Powershell来避免这种状况，以下所示。

New-Cluster - 名称 cluster1 - 节点 sql1 ，sql2 - StaticAddress 10.0 .0 .100 - NoStorage

群集建立后，运行Test-Cluster。这在SQL Server安装以前是必需的。

测试- 集群

您将收到有关存储和网络的警告，但您能够忽略Azure中SANless群集中的预期。若是有任何其余警告或错误，您必须在继续以前解决这些问题。

建立群集后，您须要添加文件共享见证。在咱们指定为文件共享见证的第三台服务器上，建立一个文件共享，并为咱们刚刚建立的集群计算机对象提供读/写权限。在这种状况下，$ Cluster1将是在共享和NTFS安全级别都须要读/写权限的计算机对象的名称。

建立共享后，您可使用配置群集仲裁向导（以下所示）配置文件共享见证。

安装DataKeeper
在安装DataKeeper以前等待建立基本集群很是重要，由于DataKeeper安装会在故障转移群集中注册DataKeeper Volume Resource类型。若是你已经跳过枪并安装了DataKeeper，那不要紧。只需再次运行安装程序并选择“修复安装”。

下面的屏幕截图将引导您完成基本安装。首先运行DataKeeper安装程序。

您在下面指定的账户必须是域账户，而且必须是每一个群集节点上的本地管理员组的一部分。

当提供SIOS许可证密钥管理器时，您能够浏览到临时密钥，或者若是您有永久密钥，则能够复制系统主机ID并使用它来申请永久许可证。若是您须要刷新密钥，SIOS许可证密钥管理器是一个将安装的程序，您能够单独运行以添加新密钥。

建立DataKeeper卷资源
在每一个节点上安装DataKeeper后，您就能够建立第一个DataKeeper卷资源了。第一步是打开DataKeeper UI并链接到每一个群集节点。

若是一切都正确完成，服务器概述报告应该以下所示。

您如今能够建立第一个Job，以下所示。

选择源和目标后，将显示如下选项。对于同一区域中的本地目标，您惟一须要选择的是同步。

选择“是”并将此卷自动注册为群集资源。

完成此过程后，打开故障转移群集管理器并查看磁盘。您应该在Available Storage中看到DataKeeper Volume资源。此时，WSFC将其视为普通群集磁盘资源。

SQL Server 2008 R2仅在带有SQL Server SP2或更高版本的Windows Server 2012 R2上受支持。不幸的是，Microsoft从未发布过包含SP2或SP3的SQL Server 2008 R2安装介质。相反，您必须在安装以前将Service Pack整合到安装介质上。若是您尝试使用标准SQL Server 2008 R2媒体进行安装，则会遇到各类问题。我不记得你会看到的确切错误，但我记得他们并无真正指出确切的问题，你会浪费大量的时间来弄清楚出了什么问题。

截至本文撰写之日，Microsoft在Azure Marketplace中没有带有SQL Server 2008 R2产品的Windows Server 2012 R2，所以若是要在Windows Server 2012 R2上运行SQL 2008 R2，您将自带SQL许可证在Azure中。若是他们稍后添加该图像，或者您选择在Windows Server 2008 R2映像上使用SQL 2008 R2，则必须先卸载现有的SQL Server独立实例，而后再继续。

我按照本文选项1中的指导将SP3整合到个人SQL 2008 R2安装介质上。固然，您将不得不调整一些内容，由于本文引用的是SP2而不是SP3。确保在咱们将用于群集的两个节点的安装介质上整合SP3。

使用带有SP3的SQL Server 2008 R2媒体进行整理，运行安装程序并安装群集的第一个节点，以下所示。

若是您使用除SQL Server的默认实例之外的任何其余内容，则本指南中将介绍一些其余步骤。最大的区别是您必须锁定SQL Server使用的端口，由于默认状况下，SQL Server的命名实例不使用1433.一旦锁定端口，每当咱们引用端口时，您还须要指定该端口而不是1433本指南中的1433，包括防火墙设置和Load Balancer设置。

在这里，请确保指定未使用的新IP地址。这是咱们稍后在配置内部负载均衡器时将使用的相同IP地址。

正如我以前提到的，SQL Server 2008 R2使用AD安全组。若是您尚未建立它们，请继续建立它们，以下图所示，而后再继续执行SQL安装中的下一步。

指定先前建立的安全组。

确保您指定的服务账户是关联的安全组的成员。

在此处指定SQL Server管理员。

若是一切顺利，您如今能够在群集的第二个节点上安装SQL Server。

在第二个节点上，运行带有SP3安装的SQL Server 2008 R2，而后选择“将节点添加到SQL Server FCI”。

继续安装，如如下屏幕截图所示。

假设一切顺利，您如今应该配置一个双节点SQL Server 2008 R2群集，其外观以下所示。

可是，您可能会注意到只能从活动群集节点链接到SQL Server实例。问题是Azure不支持免费ARP，所以您的客户端没法直接链接到群集IP地址。相反，客户端必须链接到Azure负载均衡器，该负载均衡器将链接重定向到活动节点。要使其工做，有两个步骤：建立负载均衡器并修复SQL Server群集IP以响应负载均衡器探测并使用255.255.255.255子网掩码。这些步骤以下所述。

我将假设您的客户端能够直接与SQL集群的内部IP地址通讯，所以咱们将在本指南中建立内部负载均衡器（ILB）。若是须要在公共Internet上公开SQL实例，则可使用公共负载均衡器。

在Azure门户中，按照屏幕截图建立一个新的Load Balancer，以下所示。Azure门户UI快速变化，但这些屏幕截图应该为您提供足够的信息来完成您须要作的事情。随着咱们的进展，我会召集重要的设置。

在这里，咱们建立了ILB。在此屏幕上须要注意的重要事项是您必须选择“静态IP地址分配”并指定咱们在SQL群集安装期间使用的相同IP地址。

因为我使用了可用区，我将Zone Redundant视为一种选择。若是您使用了可用性集，那么您的体验将略有不一样。

在后端池中，确保选择两个SQL Server实例。您不但愿在池中添加文件共享见证。

在这里，咱们配置健康探测器。大多数Azure文档都使用端口59999，所以咱们将坚持使用该端口进行配置。

在这里，咱们将添加一个负载平衡规则。在咱们的示例中，咱们但愿将全部SQL Server流量重定向到活动节点的TCP端口1433。选择浮动IP（直接服务器返回）为已启用也很重要。

如今，咱们必须在其中一个群集节点上运行Powershell脚本，以容许Load Balancer Probe检测哪一个节点处于活动状态。该脚本还将SQL群集IP地址的子网掩码设置为255.255.255.255.255，以免与咱们刚刚建立的Load Balancer发生IP地址冲突。

＃ 定义 变量 $ ClusterNetworkName = “” ＃ 的 集群 网络 名称（使用 优惠- ClusterNetwork 上 的Windows 服务器 2012 的 高 以 找到 该 名称）$ IPResourceName = “” ＃ 的 IP 地址 资源 名称 $ ILBIP = “” ＃ 的 IP 地址 的 在 内部 负载 平衡器（ILB）和 SQL 集群 导入- 模块 FailoverClusters ＃ 若是 您 正在 使用 的Windows 服务器 2012 或 更高：获取- ClusterResource $ IPResourceName | Set - ClusterParameter - Multiple @ { Address = $ ILBIP ; ProbePort = 59999 ; SubnetMask = “255.255.255.255” ; 网络= $ ClusterNetworkName; EnableDHCP时= 0 } ＃ 若是 您 正在 使用 的Windows 服务器 2008 R2 使用 此：#cluster RES $ IPResourceName / 私法 enable，使能= 0 地址= $ ILBIP probeport = 59999 子网掩码= 255.255。255.255
若是正确运行，这就是输出的样子。

下一步
若是你到了这一点而且仍然没法远程链接到群集，那么你就不会是第一我的。在安全性，负载均衡器，SQL端口等方面，有不少问题可能出错。我编写本指南以帮助解决链接问题。

事实上，在这个很是安装中，我在SQL Server配置管理器中的SQL Server TCP / IP属性方面遇到了一些奇怪的问题。当我查看属性时，我没有看到SQL Server群集IP地址是它正在侦听的地址之一，因此我不得不手动添加它。我不肯定这是否是异常，但在我从远程客户端链接到集群以前，这确定是我必须解决的问题。

正如我以前提到的，您能够对此安装进行的另外一项改进是为TempDB 使用DataKeeper非镜像卷资源。若是你设置了它，请注意人们常常遇到的如下两个配置问题。

第一个问题是若是将tempdb移动到第一个节点上的文件夹，则必须确保在第二个节点上建立彻底相同的文件夹结构。若是在尝试进行故障转移时不这样作，SQL Server将没法联机，由于它没法建立TempDB

第二个问题发生在建立集群后，将其余DataKeeper卷资源添加到SQL集群的任什么时候候。您必须进入SQL Server群集资源的属性，并使其依赖于您添加的新DataKeeper Volume资源。对于TempDB卷和您在建立集群后可能决定添加的任何其余卷都是如此。

若是您对此配置或任何其余群集配置有任何疑问，请随时与我联系或在下面发表评论。