部署MicrosoftSQLServer2005群集

微软公司的SQL Server 发布已经有一段时间了 先前作了简单的测试安装 感觉确实有不小的改进 在 *** 作上我还是有些不适应 毕竟我不是专门做数据库管理的 菜啊！

之所以会对SQL 感兴趣 主要是因为很多朋友都在用 而且未来我可能也会接触它 一直以来都想搞一次MDaemon的冗余方案测试 本来打算采用免费的MySQL可是发现目前的 x版本竟然无法正常运行在MSCS上 无奈等待了有数月之久直到微软的SQL 发布 哈哈！机器的内存也升级到 G 所以决定抱着勇于求知的精神开始筹备测试部署SQL 群集 年前最后一天班下午没有太多事情就搭建了一个DC+NodeA+NodeB的群集环境 安装SQL 还是比较顺利的 后来放入第二张盘安装便失败了 以为是因宿主性能造成（在 M内存的虚拟机中安装SQL 群集 真的是非常得慢 我可怜的硬盘） 决定年后上班搭建一个双节点群集环境来做测试 这样一来资源占用应该会小很多 毕竟撤掉一台单独的DC

昨天是年后的第一天班 处理完手上的工作 下午便开始搭建双节点群集环境 这样强烈使用VMware GSX来作为虚拟机软件 不像VSRV R 那样配置方便 但是相对来说整体的 *** 作还是优于VSRV R 的 另外就是运行速度 感觉确实要快很多 新版的GSX搭建MCSC还是比较简便的 不必像网上资料中写的需要什么pln工具 直接生成固定容量磁盘后 修改虚拟机的配置文件添加参数就可以了 关于配置参数的资料可以参考

本文主要总结SQL 的群集部署 所以关于VMware下MSCS环境的搭建步骤就不再重复 直接从主题开始

测试环境 宿主机           硬件配置 PIV G/ G DDR / G PATA pm/ C NIC           *** 作系统 Microsoft Windows XP Pro With SP ENU           虚拟平台 VMware GSX

VirtualHost Microsoft Cluster NodeA           硬件配置 PIV G/ M/ G/vlance NIC/vmxnet NIC           *** 作系统 Microsoft Windows Server EE With SP CHS           网卡信息 vlance NIC M 全速半双工/HeartBeat/IP                           vmxnet NIC M 全速全双工/Public/IP /GW /DNS /WINS            承载服务 DC+DNS+WINS+IIS

VirtualHost Microsoft Cluster NodeB           硬件配置 PIV G/ M/ G/vlance NIC/vmxnet NIC           *** 作系统 Microsoft Windows Server EE With SP CHS           网卡信息 vlance NIC M 全速半双工/HeartBeat/IP                           vmxnet NIC M 全速全双工/Public/IP /GW /DNS /WINS          承载服务 DC+DNS+WINS+IIS

Virtual G Pln Qdisk M/Sdisk M        注意 本次测试将仲裁盘和资源盘放在了一起 实际中最佳的做法应当单独配置一个物理磁盘作仲裁使用 为提高安全性还应该为仲裁磁盘配置RAID

MSCS IP

目标实现 成功部署 SQL Server 群集/HostName SQL /IP

群集实施       我手上的SQL 为企业中文版 CD 首先放入第一张盘 点击 服务器组件 工具 联机丛书和示例 开始SQL 的群集安装 安装程序会自动检测当前是否为群集环境并为群集安装准备 小提示 MSCS默认环境下 群集组资源中缺少MSDTC组件 所以需要先添加MSDTC后再开始SQL 的群集安装 否则会出现警告并停止！

接受软件使用许可协议

SQL 在进行初始检测后开始执行安装 SQL 所需组件

完成所必需组件的安装

安装程序开始执行系统配置检查

进入SQL 的安装向导

向导开始执行系统配置检查 因为是安装群集 会自动检查各节点并给出状态提示 因为虚拟机配置的是 M内存 所以这里会 最低硬件要求 的警告 可以忽略！

选择要安装的组件 如要得到各组件的详细信息可以选择高级项

进入高级项后就来到了详细的各组件的功能选择 这里可以得到详细的组件信息 根据需要选择组件功能

实例名 配置中选择 默认实例

虚拟服务器名称配置中 为此群集命名为sql

为虚拟服务器配置IP 这里我使用Public作为公共访问 并分配一个IP 添加后点击 下一步

在 选择群集组 中选择可以得群集组 因为这里我只有一个默认的群集组 所以点击 下一步 继续

d出警告 提示我此群集组包含仲裁资源 这是因为我之前配置了一块Pln磁盘并分配两个逻辑分区来做群集 因此在这里会提示警告 可以直接忽略

群集节点配置中 选择可用的节点 因为我当前是双节点群集环境 所以安装向导自动为我选择了NodeA节点

配置远程安装的帐户 这里的帐户必须是各节点上有效的管理员帐户

为服务配置帐户 之前我已经添加了一个名为sql 的域用户作为SQL服务帐户 所以这里填写上正确的信息

配置群集服务的域组 这里其实我到现在还没有彻底搞明白是什么意思 参看帮助文件 便在域中为每个SQL服务创建对应的全局组 （希望达人能够帮我解答一下此处的意义！）

身份验证模式中 选择 混合模式 这和SQL 的感念是一样的

排序规则我是按照默认选择的

这里我没有选择微软提供的跟踪服务功能

前期的安装配置完成后就准备开始执行正式的文件安装 激动啊！

SQL 的群集安装进度还是很人性化的 这里你可以切换每个节点来监视安装进度

到这里就是一个漫长的等待了 真是心疼我的硬盘 不过结果很悲惨 在CD 安装完毕后 系统提示我插入CD 记得年前的测试也是在这里出现问题的 感觉会不会是因为磁盘写延迟 导致另外一个节点没有安装完 我就放入第二张CD造成的呢？抱着幻想我就一直等待 并且监视两台节点的日志 直到节点的硬盘和网卡没有强烈的提示后 我才放入CD 点击了确定 谁知道接下来就出现了之前测试相同的错误 安装终止并结束了 郁闷！这是怎么回事？检查系统发现SQL 的服务已经是启动了 这么说服务的安装时成功的 于是进入添加删除程序中 使用更改方式检查SQL 的安装 发现这里只有添加节点和卸载SQL 群集两个选择

重新执行光盘 发现CD 原来是 工具 联机丛书和示例 的安装盘

于是再次执行安装程序 哈哈 记起来了！之前也重新执行过安装不过放入的是CD 所以组件选中服务项等都是不安装 我以为红叉代表删除 所以就没敢继续 如果当时直接从CD 执行安装估计也就成功了

我个人认为 SQL 的管理工具等组件应该在群集安装后再单独为每个节点安装才是最佳的做法 至于为什么之前会失败只能靠其他达人来做试验来验证了！完成了管理工具等组件的安装 怀着兴奋的心情打开了全新的SQL 管理工具 默认启动后显示的是连接到服务器的配置页面 这里配置好登录后 可以在管理工具的选项中修改初始打开页面 在 已注册的服务器 窗体中打开SQL 服务器

哈哈 SQL 的群集算是安装完成了 真是令人兴奋！ 

进入 群集管理器 中检查SQL 群集的安装 发现没有问题 心理已经非常激动了！

最后来验证一下群集是否真的开始正常工作了 我将NodeB节点关闭后 在NodeA上打开 群集管理器 发现SQL 的群集资源已经自动并成功地从NodeB上转移到了NodeA 在NodeA上打开SQL 的管理工具进行服务器连接测试 成功！

至此 SQL 的群集算是圆满测试成功了 其间也是走了不少弯路 不过最后总算是成功了 心理也得到了安慰 其实SQL 的群集还是非常简单的 只不过CD 的安装出错到底是因为其本身不支持群集安装还是因为其他原因目前还不知晓 只能等权威的解释了！另外 SQL 的群集安装需要在拥有活动资源的节点上进行安装

总算是把文章写完了 今天狂停电 真郁闷！害死我了 最后算是一边写一边发布再编辑 真是费神 此实战总结为个人观点 其中有不足或错误之处还希望大家多多指正！

lishixinzhi/Article/program/SQLServer/201311/22067

转自：集群故障转移的仲裁

Windows服务器故障转移集群（Windows Server Failover Cluster，简称WSFC）使用仲裁投票（Quorum Voting）决定集群的健康状况，或使故障自动转移，或使集群离线。 当集群中的结点发生故障时，会由其他结点接手继续提供服务 ，不过， 当结点之间通信出现问题，或大多数结点发生故障时，集群就会停止服务，可是集群可以容忍多少个结点发生故障呢？ 这要由仲裁配置（Quorum Configuration）决定，仲裁配置采用少数服从多数（Majority）原则，只要集群中健康运行的结点数量达到仲裁规定的数量（多数结点投赞成票），集群就会继续提供服务，否则集群就停止提供服务。在停止提供服务期间，正常结点持续监控故障结点是否恢复正常，一旦正常结点的数量恢复到仲裁规定的数量，集群就恢复正常，继续提供服务。仲裁投票默认是启用的（Cluster Manged Voting：Enable）。

一，仲裁模式

仲裁模式是在WSFC 集群级别配置的，规定仲裁投票的方法，默认情况下，故障转移集群管理器会基于集群结点的数量，自动推荐一个仲裁模式。仲裁配置影响集群的可用性，在集群中，重组的集群结点必须在线，否则集群将由于仲裁不足而必须停止服务。

1，术语解释

仲裁（Quorum）：法定数量，预先规定具有投票权的结点或见证（Witness）的数量；

仲裁投票（Quorum Voting）指法定数量的结点和见证进行投票，如果多数投赞成票，那么判断集群处于健康状态；

投票节点（Voting Node）：在集群中，拥有投票权的结点称作投票结点，如果投票结点投赞成票，代表该结点认为集群是健康的；但是，单个结点不能决定集群整体的健康状态。

投票见证（Voting Witness）：除了投票结点能够进行投票之外，共享的 File 和 Disk 也能投票，称作投票见证， 共享的File 投票见证，称作文件共享见证（File Share Witness）；共享的Disk 投票见证，称作硬盘见证（Disk Witness） ；

仲裁结点集合（Quorum Node Set）：拥有投票的结点和Witness统称仲裁结点集合；由仲裁结点集合的投票结果决定集群整体的健康状态。

2，仲裁模式

仲裁模式多数原则 是指所有投票结点进行投票，如果赞成票占比在50%以上，那么WSFC认为集群处于健康状态，执行故障转移，继续提供服务，否则，WSFC认为集群出现严重故障，WSFC使集群离线，停止提供服务。根据仲裁结点集合的组成类型，将仲裁模式分为以下四种类型：

结点多数 （Node Majority）：在集群中，投票结点都是集群的结点服务器，如果一半以上的投票结点（Voting Node）投赞成票，那么WSFC判定集群是健康的；

结点和文件共享多数 （Node and File Share Majority）：和Node Majority模式相似，除了将远程文件共享配置为一个投票见证（Voting Witness）之外，该共享文件称作仲裁文件，或见证文件。使用仲裁文件，远程文件拥有投票权，如果其他结点能够连接到该共享文件，那么认为该文件投一个赞成票。如果投票结点和文件共享投的赞成票占一半以上，那么WSFC判定集群是健康的。作为一个最佳实践，文件共享见证（File Share Witness）不要存储在集群中的任何一个结点服务器上，并且设置任何一个结点服务器都有权限访问。

结点和硬盘多数 （Node and Disk Majority）：和Node Majority模式相似，除了将共享硬盘配置为一个投票见证（Voting Witness）之外，该共享硬盘称作仲裁硬盘，或见证硬盘。仲裁硬盘需要共享存储，集群中各个结点都需要挂载同一个共享硬盘。

只硬盘（Disk Only） ：没有多数，仅仅把一个共享的硬盘作为唯一见证，集群中的任何一个结点能够访问该共享硬盘，这意味着，一旦仲裁硬盘脱机，集群就会停止提供服务。

常见的仲裁模式是结点多数（Node Majority） 和 结点和文件共享多数（Node and File Share Majority） ，如果集群结点数量是 奇数 ，那么使用结点多数仲裁模式；如果集群结点数量是 偶数 ，那么使用结点和文件共享多数仲裁模式，该模式需要配置一个共享文件夹，集群中的各个结点都有权限访问该共享文件夹，并且该共享文件夹不能创建是集群的结点上。

打开故障转移管理器（Failover Cluster Manager），右击集群结点，在上下文菜单中点击“More Actions”，在扩展菜单中选择“Configure Cluster Quorum Settings”，打开仲裁配置向导（Wizard），为该集群配置仲裁。

在任何时刻，从每一个的结点的角度来看，其他结点可能处于离线状态，或正在进行故障转移，或由于网络连接失败而处于不响应状态，仲裁投票的关键在于确定所有投票结点的真实状态。除了“Disk Only”仲裁模式之外，其他仲裁模式都依赖于投票结点之间周期性的心跳信号通信，一旦某个结点因为网络通信故障，系统宕机，硬件损坏，机房停电等异常而无法回应心跳信号，那么剩余的结点就认为该结点出现异常，把该结点从当前集群排除。WSFC统计所有投票结点的仲裁结果，决定集群的健康状态。

如果集群的结点位于不同的子网（Subnet）中，当一个结点在子网1中被认为是故障结点时，实际上，该结点可能是由于网络通信故障而不能被子网1的结点感知，但是该结点在子网2中是在线的，健康的 。如果投票结点在不同的子网中能够建立多个投票仲裁，那么将产生脑裂场景。在该场景中，位于不同仲裁的结点有不同的表现，使仲裁产生冲突，WSFC不能正确的执行故障转移，可能产生数据不同步。脑裂场景只可能在系统管理员手动执行强制仲裁(Forced  Quorum) *** 作时发生。

WSFC在集群的结点之间进行健康检测和仲裁投票，每一个结点通过周期性地发送心跳信号，检测其他其他结点的健康状态，并和其他结点共享健康数据，无法响应心跳信号的结点被认为处于异常状态，集群的所有健康结点都会很快知道该结点出现故障。

仲裁结点集合是投票结点和见证结点（Witness）结合，仲裁结果由多数（Majority）结点决定，集群整体的健康状态是由周期性的仲裁投票的结果决定的，WSFC根据仲裁投票的结果，执行自动故障转移或者使集群离线：如果仲裁结点集合（Quorum Node Set)的投票结果表明大多数结点是健康的，那么集群将进行故障转移，继续提供服务；如果投票结果是少数结点，那么集群将处于离线状态。

---