SQL Server AlwaysON从入门到进阶（4）——分析和部署Windows Server Failover Cluster

本文属于SQL Server AlwaysON从入门到进阶系列文章

前言：

本节将进一步介绍关于Windows Server Failover Cluster（WSFC）的部署细节和一些常规的配置任务。在本系列中将会使用5节点群集。同时也会看到在创建基本的WSFC时的实际要求。首先是对部署前的前置条件介绍。

先决条件：

在搭建WSFC之前，首先需要确保所有将要加入到群集的节点已经启用了Windows Server 的“故障转移群集（Failover Clustering）”功能。这个功能用于提供故障转移功能，使用一系列的DDLs和管理工具使得管理员可以配置和管理群集。群集启用的方式一般有以下几种：

• 服务器管理器|仪表板→添加角色和功能：
• cmd命令：其中？为安装文件所在盘符：DISM /Online /Enable-Feature /FeatureName:FailoverCluster-Mgmt /All /LimitAccess /Source=?:\sources\sxs 
• PowerShell：Install-WindowsFeature -Name "Failover-Clustering

注意：上面的命令需要先启用.NET 3.5，可以在cmd命令中加上/FeatureName:NetFX3 或在PowerShell命令中加上：-Name "NET-Framework-Core" 或者在界面操作中勾选下图的样子：

在创建群集之前，还需要确保所有的伙伴节点使用了相同的Windows版本及补丁版本（本例使用同一个安装文件可以避免这种风险但是正式环境还需要检查）。如果某个节点的网卡驱动不一样，那么可能导致一系列的麻烦，首当其冲就是在群集验证过程就会出现失败。

上一节中提到过，还需要一个DNS架构、一个AD域和一个TCP/IP网络。这部分单独一系列文章介绍。

群集IP和群集名配置：

一旦安装完故障转移群集，就可以调整基础架构以满足要求。这里需要确定虚拟IP地址和虚拟网络名（通常有系统管理员分配）。群集客户端接入点也需要这些配置。这个名字和IP地址会用于连接Windows Cluster并进行群集对象管理之用。下面是将要用到的授权清单：

节点和虚拟网络IP分配情况

计算机名	IP 地址
ClusterNode1	192.168.0.171
ClusterNode2	192.168.0.172
ClusterNode3	192.168.0.173
ClusterNode4	192.168.0.174
ClusterNode5	192.168.0.175
WIN2K12R2-01	192.168.0.176

这个列表中你会发现有一台额外的计算机名和IP地址，这是用于Windows Server Failover Cluster客户端接入点的机器。在 上一节中提到，每个SQL Server FCI或AlwaysOn侦听器在安装之后，会使用虚拟计算机对象和虚拟IP地址。在本系列的最后一文会看到我们有最少有两个或更多的虚拟计算机对象和虚拟IP地址。当连到群集中时，我们使用的是WIN2K12R2-01或 192.168.0.176。

下面稍微花点时间看下AD 计算机名对象和虚拟计算机对象的创建。在 基于SQL Alwayson的Windows Server 2012 WSFC搭建指南 系列中（实际上是为了这个系列而编写的），部署了一个DC和5个Windows Server服务器作为群集节点，通常我们都使用域管理员权限，所以很少遇到权限问题。但是在正式环境中，DBA通常使用的是由IT团队创建及配置好的WSFC。所有的创建和分配细节都被覆盖掉。同时，你通常只有低权限的域用户可用。

当尝试使用低权限账号安装FCI或者AlwaysOn 侦听器时，你会发现一些对象的创建错误。对此可以参考这篇文章： 在 Active Directory 域服务中预安排群集计算机对象

Windows Cluster 网络配置：

当使用Winodws 2008/2012创建群集时，群集网络驱动程序会检测并创建基于默认网关绑定到网络适配器的网络。如果侦测到有默认网关，那么就会统一客户端的连接并把这个默认网关标识成可用于群集连接。而存储网络如iSCSI，则不用于群集通讯。

确保各节点的所有网络适配器被合适地按用法命名（如public,private（本文使用domain代表）,iSCSI等。）命名规范可以使得管理和运维更加合理及轻松。另外也要确保网络适配器连接的优先级。在三个网卡中，优先级从优先到最后的顺序为：Public→Private（Domain）→iSCSI。

在所有非客户端网络，这里就是Private（Domain）和iSCSI，都需要取消“在DNS中注册此连接的地址”的勾选并勾选“禁用TCP/IP上的NetBIOS”，如下面两图：

Windows Server Cluster Service：

Windows Server群集服务，群集服务用于控制服务器群集操作和管理群集的内部平面文件数据库。一个群集是独立服务器组合起来并作为一个单独实体对外提供服务的集合。用户看到的群集是一个单独的系统。如果某个节点发生故障，其他节点会承担起故障节点的服务和数据继续运作。当一个新节点加入群集，所有的已群集应用如SQL Server FCI必须在这个节点上重新安装。

下面是Windows 群集服务中，如果环境跨越了防火墙，就需要配置的网络要求：

系统服务名称：ClusSvc

应用程序协议	协议	端口
群集服务	UDP	3343
RPC	TCP	135
群集管理器	UDP	137
随机分配的高 UDP 端口¹	UDP	1024 – 65535 之间的随机端口号 49152 - 65535 之间的随机端口号²

¹ 有关如何自定义此端口的更多信息，请参阅“参考”部分中的“远程过程调用和 DCOM”部分。
² 这是 Windows Server 2008 和 Windows Vista 中的范围。

详细内容可以查阅：Windows 服务器系统的服务概述和网络端口要求

创建Windows Server Failover Cluster：

这部分另起一个系列：

基于SQL Alwayson的Windows Server 2012 WSFC搭建指南（1）——简介及AD搭建和配置

基于SQL Alwayson的Windows Server 2012 WSFC搭建指南（2）——Windows 2012 Cluster搭建

Windows 群集内的仲裁：

现在是时候说一下仲裁。Windows群集要求一些媒介用于在普通活动的群集操作过程中，决定资源的所有者。在多节点发生灾难性故障时，这个媒介可以避免节点间的相同资源争用。这些仲裁如下：详细内容可以查看官方资料： 在 Windows Server 2012 故障转移群集中配置和管理仲裁

模式	说明
多数节点（无见证）	仅节点具有投票。 没有配置任何仲裁见证。 群集仲裁是活动群集成员身份中的多数投票节点。
带有见证的多数节点（磁盘或文件共享）	节点具有投票。 此外，仲裁见证有一票。 群集仲裁是活动群集成员身份中的多数投票节点以及一个见证投票。 仲裁见证可以是指定的磁盘见证或文件共享见证。
无多数（仅磁盘见证）	没有节点具有投票。 仅磁盘见证有一票。 群集仲裁由磁盘见证的状态确定。 如果一个节点可用并且与群集存储中的特定磁盘通信，则该群集具有仲裁。 通常，不建议使用此模式，并且不应该选择它，因为它为群集创建了单点故障。

Windows 2012 R2支持“动态权重管理”配置，这个功能用于防止群集在计划性关闭节点过程中出现中断。下面只介绍Windows 2012。我们首先把节点5驱逐出群集：

Windows 2012：

在Windows 2012 群集中，投票已经变得动态管理。我门在节点一或者其他节点中运行PowerShell，并输入：

get-clusternode | ft id,nodename,dynamicweight,nodeweight 

注意PowerShell是大小写敏感的。
结果如下：

可以看到每个节点已经有一个相同的权重或者票数，但是再看动态节点权重（DynamicWeight列）已经重新平衡。节点4已经动态撤销投票以便确保投票配置按奇数节点投票。

提醒：在Windows 2012 R2中，唯一一个关闭动态节点权重功能的方式只有通过PowerShell实现。意味着微软并不希望你关闭。

现在我们添加一个文件共享见证然后重新检查变化。

右键群集名，选择更多操作→配置群集仲裁设置：

选择【选择仲裁见证】：

如果这里选择了【高级仲裁配置】：可以看到下面两个图的界面

在高级仲裁配置中，可以选择对所有节点或者部分节点进行投票控制。可以选择下一步，或者回到上一步选【选择仲裁见证】，继续进行配置

这里选择【配置文件共享见证】：

新建一个文件共享路径：这里使用WINS这台机

按下图配置：名字无所谓

继续配置直到完成：

重新检查投票配置和仲裁模式，可以看到下图内容：

• 仲裁类型现在变成NodeAndFileShareMajority。
• 所有节点在仲裁中都活动。因为在群集节点中现在变成了奇数节点所以动态节点权重已经不影响投票。

可以随机停止某个/些节点，然后运行上面的PowerShell去检查数据以便验证结果。完成测试后使用界面选择【使用默认仲裁配置】来移除文件共享见证。现在把节点5添加回群集中。

把Node5加回群集中：

现在对WSFC的搭建已经完成，下一文是FCI的分析和部署。但是由于工作需要，暂时跳过，直接进入再下一文即AlwaysOn Availability Group的分析和部署部分。后续再回过头完善。

SQL Server AlwaysON从入门到进阶（6）——分析和部署AlwaysOn Availability Group