服务器群集.docx
《服务器群集.docx》由会员分享，可在线阅读，更多相关《服务器群集.docx（19页珍藏版）》请在冰豆网上搜索。
服务器群集
一、群集介绍
服务器群集是一组协同工作并运行Microsoft群集服务（MicrosoftClusterService，MSCS）
的独立服务器。
它为资源和应用程序提供高可用性、故障恢复、可伸缩性和可管理性。
它允
许客户端在出现故障和计划中的暂停时，依然能够访问应用程序和资源。
如果群集中的某一
台服务器由于故障或维护需要而无法使用，资源和应用程序将转移到可用的群集节点上。
（说明:
本文档编写的目的是为了帮助大家实现所关心的如何在VMWareWorkstation中完成
典型群集的配置步骤，不会具体的涉及到如何安装群集应用程序，如Exchange群集等）
二、群集专业术语
节
点:
构建群集的物理计算机
群集服务:
运行群集管理器或运行群集必须启动的服务
资
源:
IP地址、磁盘、服务器应用程序等都可以叫做资源
共享磁盘:
群集节点之间通过光纤SCSI电缆等共同连接的磁盘柜或存储
仲裁资源:
构建群集时，有一块磁盘会用来仲裁信息，其中包括当前的服务状态各个节点的
状态以及群集转移时的一些日志
资源状态:
主要指资源目前是处于联机状态还是脱机状态
资源依赖:
资源之间的依存关系
组
:
故障转移的最小单位
虚拟服务器:
提供一组服务--如数据库文件和打印共享等
故障转移:
应用从宕机的节点切换到正常联机的节点
故障回复:
某节点从宕机状态转为联机状态后，仍然继续宕机前的工作，为其他节点分流
三、实验环境介绍及要求
1、拓扑图
2、软件配置说明
（1）DC软件配置信息
OS:
WindowsServer2003X86SP1中文企业版
Role:
ActiveDirectory域控制器
Domain:
ServerName:
DC
IP:
192.168.0.254（以“桥接”方式连接）
Netmask:
255.255.255.0
Gateway:
192.168.0.254
（2）ClusterNodeA软件配置信息
OS:
WindowsServer2003X86SP1中文企业版
Role:
MemberServer
ServerName:
ClusterNodeA
IP1:
192.168.0.1（以“桥接”方式连接）
Netmask1:
255.255.255.0
Gateway1:
192.168.0.1
Dns1:
192.168.0.254
IP2:
10.0.0.1（以“VMnet2”方式连接）
Netmask2:
255.0.0.0
Gateway2:
None
DNS2:
None
（3）ClusterNodeB软件配置信息
OS:
WindowsServer2003X86SP1中文企业版
Role:
MemberServer
ServerName:
ClusterNodeB
IP1:
192.168.0.2
Netmask1:
255.255.255.0
Gateway1:
192.168.0.1（以“桥接”方式连接）
Dns1:
192.168.0.254
IP2:
10.0.0.2（以“VMnet2”方式连接）
Netmask2:
255.0.0.0
Gateway2:
None
DNS2:
None
3、硬件配置要求
（1）网卡
1）群集中的每个节点需要有两个网卡。
一个用来连接您的公共网络，一个用来进行群集节
点间的通讯，俗称“心跳连接”。
2）心跳线必须通过交叉线直接连接群集节点，不能通过任何路由设备。
因为群集心跳数据
包的生存时间TTL值为1。
我们知道，数据包在每经过一个路由节点时，TTL值都会减一。
（2）共享磁盘
1）除操作系统所在磁盘外，还需要两个额外的SCSI磁盘。
一个用来做仲裁磁盘，另一个用
来充当数据共享磁盘。
2）共享磁盘必须位于系统驱动器所用的控制器以外的另一个控制器上。
不要和操作系统所
在磁盘使用同一个总线。
3）所有共享磁盘，包括仲裁磁盘，必须在物理上附加到一个共享总线。
4）仲裁磁盘空间大小最小50MB。
为了得到最佳的NTFS文件系统性能，建议采用最小500
MB的磁盘分区。
5）所有共享磁盘必须配置为基本磁盘，而不能为动态磁盘。
6）共享磁盘不支持软件容错，不要再试图对共享磁盘做软RAID。
7）如果您使用的是64位版本的WindowsServer2003的系统，需要注意的是，所有共享磁
盘必须配置为主引导记录（MBR），也就是建立主分区。
也不要试图配置为GPT磁盘，
因为它不能作为群集磁盘得到支持。
8）群集磁盘上的所有分区必须格式化为NTFS。
9）群集节点的操作系统必须采用同架构的版本，不能节点A采用32位系统，而节点B却
使用64位系统。
（说明:
在本次实验中，模拟的SCSI共享磁盘柜均是通过VMwareWorkstation自带的相关工
具来创建）
四、安装群集前的准备工作
1、创建共享磁盘
（1）创建用来保存共享磁盘的目录
在本实验中，我在D:
\VirtualMachines目录下新建了一个ShareDisks文件夹，用来保存后面
两个操作建立的虚拟仲裁磁盘文件和数据磁盘文件。
（2）创建仲裁磁盘
进入VMwareWorkstation软件安装目录，在命令提示符窗口敲入如下命令:
vmware-vdiskmanager.exe-c-s600Mb-alsilogic-t2“D:
\Virtual
Machines\ShareDisks”\Quorum.vmdk
（3）创建数据共享磁盘
进入VMwareWorkstation软件安装目录，在命令提示符窗口敲入如下命令:
vmware-vdiskmanager.exe-c-s2Gb-alsilogic-t2“D:
\Virtual
Machines\ShareDisks”\ShareDisk.vmdk
（4）验证共享磁盘是否成功创建
进入D:
\VirtualMachines\ShareDisks中，可以看到步骤2、3创建的4个虚拟磁盘文件。
（5）附加共享磁盘
通过前面的操作，我们已经成功的创建了群集所需要的共享磁盘。
接下来将虚拟磁盘文件附
加到ClusterNodeA和ClusterNodeB上。
1）进入ClusterNodeA所对应的虚拟系统目录（不是虚拟机软件安装目录），找到.vmx
（VMware配置文件），用记事本打开，添加如下记录:
disk.locking="false"
diskLib.dataCacheMaxSize="0"
scsi1.present="TRUE"
scsi1.virtualDev="lsilogic"
scsi1:
5.present="TRUE"
scsi1:
5.fileName="D:
\VirtualMachines\ShareDisks\Quorum.vmdk"
scsi1:
6.present="TRUE"
scsi1:
6.fileName="D:
\VirtualMachines\ShareDisks\ShareDisk.vmdk"
2）在ClusterNodeB上重复前一个操作，并做相应的修改。
3）关闭VMwareWorkstation软件后再次打开，会发现先前创建的共享磁盘均附加到
ClusterNodeA和ClusterNodeB上了。
从上两个图中可以看出:
1）共享磁盘属于SCSI通道1，和系统盘SCSI通道0不在一个共享总线上，符合集群需求
2）共享磁盘的仲裁磁盘和数据磁盘均位于SCSI通道1上，亦符合集群需求
2、网络及系统配置
（1）创建群集服务帐户
1）群集服务需要一个属于可运行群集服务的每个节点上的本地管理员组成员的域用户帐
户。
因为安装群集服务时需要用到这个用户名和密码，所以该用户帐户必须在配置群集服务
前予以创建。
该用户帐户只能专门用于运行群集服务，而不能属于个人。
建议该账户是普通
域账户，而不是域管理员账户。
2）如下图所示，必须勾选“密码永不过期”，建议同时将“用户不能更改密码”勾选。
当
然，如果您希望每次密码到期前都手工重设密码，以便在您的工作周报中多一个已完成的工
作记录，我不反对。
3）创建完毕后，再将其添加到各个节点的本地管理员组中即可。
（2）添加群集A记录
如果您需要将运行在群集服务上的应用程序服务（该服务器即为虚拟服务器）以域名的形式
对内或对外发布，您可能需要在域控制器的DNS管理器中添加群集名的A记录。
例如，本
次试验中，我给节点A和节点B通过群集虚拟出来的地址192.168.0.10分配一个对应的A
记录名:
ClusterT
（3）ClusterNodeA上的共享磁盘配置
1）启动ClusterNodeA（不要开启ClusterNodeB，使其保持关闭状态。
这样有助于保证附加
到共享总线的磁盘上的数据不会丢失或遭到破坏。
）
2）打开ClusterNodeA的“磁盘管理”，系统会自动找到先前创建的两个共享磁盘。
进入“磁
盘初始化和转化向导”
3）“新建磁盘分区”
4）选择建立“主磁盘分区”。
5）给仲裁磁盘分配一个约定成俗的驱动器号Q。
6）一定要格式化成为NTFS，同时把卷标改成“Quorum”。
7）以上是对仲裁磁盘进行操作，按照同样的方法，对共享数据磁盘进行操作。
分配驱动器
号为R，卷标名为Data。
（具体过程略）。
另外，需要补充一点的是，通常，驱动器盘符“Q”
用于仲裁磁盘，而“R”、“S”等字母则常用于数据磁盘。
尽管您可以按照个人喜好随意更
改，但是建议采用约定成俗的规定。
8）对共享磁盘的操作完成后，建议验证一下磁盘是否可读写。
方法是新建一些文件后再删
除，看看是否都正常。
（4）网络配置
1）为了接下来的实验更加直观，建议把两块网卡进行重命名操作。
生产环境也推荐这样操
作。
2）HearbeatConnection网卡（以下改称为心跳网卡）的TCP/IP属性如下。
不要对心跳网
卡设置默认网关和DNS地址。
3）按照下图修改心跳网卡的高级TCP/IP属性，目的是禁止心跳网卡的DNS和NetBios
查询。
这样能够消除可能出现的通信问题，也有利于减少不必要的网络流量。
因为服务器
群集节点间的通信对于群集的顺畅运转至关重要。
4）按照微软官方推荐的做法，如果您拥有一个能够以不同速度进行传输的网卡，那么您应
该手动指定同一个速度及双工模式。
不要对传输速度应用自动选择设置，因为某些适配器在
确定速度时可能丢掉一些数据包。
这直接影响到群集节点之间的通讯质量。
Microsoft建议
您将同一路径上的所有设备设定为“10M”和“半双工”。
同时，如果您的网卡支持Teaming
冗余，而您又无法确保该特性和群集之间的兼容性时，建议取消该特性。
由于虚拟机无法
对网卡的物理属性进行该类设置，如下图所示。
故特意从生产环境HP服务器上截取了如下两张图来说明。
5）至此，有关ClusterNodeA的前期网络和系统的相关配置已结束。
接下来按照类似的方
法对ClusterNodeB进行配置。
（5）ClusterNodeB上的共享磁盘配置
1）关闭ClusterNodeA，开启ClusterNodeB。
在此期间，请保持ClusterNodeA处于关闭状
态。
原因前面已经说明，不再赘述。
（请尽量按照下图的方式关闭ClusterNodeA，而不只是
简单的关闭系统）
2）打开ClusterNodeB的磁盘管理器，可以看到之前创建的共享磁盘同样被系统发现了。
只是由于WindowsServer2003系统的设计使然，没有自动为其分配驱动器号。
我们需要手
工对它分配和ClusterNodeA相同的驱动器号。
3）为了实验的直观性，建议将卷标也进行修改。
卷标名建议和ClusterNodeA上的保持一
致。
4）同样，建议用同样的方法验证一下磁盘是否可正常读写。
5）至此，我们已完成两个节点的网络和系统相关配置。
下面，我们开始进入真正的群集服
务安装环节。
五、安装群集服务
1、在A节点上新建一个群集
（1）开启ClusterNodeA，同时保持ClusterNodeB处于关闭状态。
展开ClusterNodeA的“开
始”菜单，定位到“程序”“管理工具”，打开“群集管理器”。
（2）选择“创建新群集”。
（3）输入您公司的域名和事先准备好的群集名。
如果有需要，在DNS中对该群集名建立对
应的A记录。
（4）输入新群集中的第一个节点的计算机名，这里我们选择ClusterNodeA
（5）这时会对群集配置进行一个完全分析。
如果有任何一项无法通过检测，务必检查原因、
排除问题。
故障排除后，不需要重新再来，只需点一下“重新分析”按钮就行。
（6）输入群集的IP地址，该地址是ClusterNodeA和ClusterNodeB共同虚拟出来的群集IP。
其FQDN地址对应于前面的ClusterT.
（7）输入前面创建的群集服务帐号。
该帐号可以不是域管理员，但是必须是各节点的本地管
理员。
（8）下图是配置信息汇总。
如果发现配置有错误，可以点击“上一步”进行更改。
否则点击
“下一步”，开始群集创建。
（9）可以查看创建过程是否顺利。
一般来说，只要前面群集前的分析没有问题，创建过程一
般都不会有问题的。
（10）完成新建服务器群集向导。
至此，我们已经成功的在ClusterNodeA上配置了群集服务。
（11）打开群集管理器，验证ClusterNodeA上的群集服务已成功安装。
资源所有者均为
ClusterNodeA，并均处于联机状态。
2、将B节点加入现有群集
（1）开启ClusterNodeB节点，同时不要关闭ClusterNodeA，否则无法加入现有群集。
打开
群集管理器，选择“添加节点到群集”，“浏览”，找到之前创建的群集名ClusterTest。
点击“确定”。
（2）进入添加节点向导。
（3）选择您要添加到现有群集的节点。
我这里选择ClusterNodeB。
（4）同样，节点加入前会进行群集配置分析。
如果分析结果中有任何问题，请着手解决后再
往下继续。
（5）输入群集服务帐号。
（6）群集配置信息汇总，返回修改请点击“上一步”，继续请点击“下一步”。
（7）开始“添加节点到群集”的配置操作。
（8）完成节点添加工作。
（9）从下图可以看出，ClusterNodeB已成功加入现有群集，目前处于运行状态。
（10）至此，我们成功的在ClusterNodeA上新建了一个名为ClusterTest的群集，并成功将
ClusterNodeB加入该群集中。
（11）细心的您在ClusterNodeB加入到现有群集后，可能会发现无法在ClusterNodeB上访问
原有的共享磁盘。
如下图所示。
不要奇怪，只是正常现象。
因为在群集服务中，同一时刻只
能有一个节点对资源拥有所有权。
在我这个例子中，此刻仲裁磁盘的所有者是ClusterNodeA，
所以ClusterNodeB无法访问。
反过来，如果所有者是ClusterNodeB，则会变成ClusterNodeA
无法访问共享磁盘。
六、配置群集服务
1、群集网络配置
（1）进行专用网络配置。
打开群集管理器，单击“群集配置”，单击“网络”，右键选择Heartbeat
的属性。
（2）选择“为群集使用启用这个网络”和“只用于内部群集通讯（专用网络）”。
对上图中的几个选项，我稍微做一下解释:
为群集使用启用这个网络:
如果选定了该复选框，群集服务将使用该网络。
默认对所有网络
选定该复选框。
只用于客户端访问（公用网络）:
如果您想让群集服务仅使用该网络适配器与其它客户端进
行外部通信，那么选择该选项。
该网络适配器将不进行节点对节点通信。
只用于内部群集通信（专用网络）:
如果您想让群集仅使用该网络进行节点对节点通信，那
么选择该选项。
所有通信（混合网络）:
如果您想让群集服务使用该网络适配器进行节点对节点通信和外部
客户端通信，那么选择该选项。
默认对所有网络选定该复选框。
在本次实验中，我们仅使用到了两个网络:
PublicConnection和HeartbeatConnection。
基于最
常见的配置，我们将这两个网络分别作为混合网络和专用网络。
（3）同样，进行公用网络配置
2、心跳适配器优先化
（1）由于群集服务总是尝试使用列于首位的网络适配器进行节点间的远程过程调用（RPC）
通信。
只有当群集服务无法使用第一个网络适配器进行通信时，才会使用列表上的下一个网
络适配器。
所以我们需要调整一下心跳适配器的优先级。
（2）启动群集管理器。
右击群集名称，然后单击“属性”，在弹出的对话框中单击“网络优先
级”选项卡。
将HeartbeatConnection上移至顶部。
3、仲裁磁盘配置
启动“群集管理器”。
右击左上角的群集名称，然后单击“属性”。
单击“仲裁”选项卡。
在
“仲裁资源”列表框中，选择“磁盘Q”。
4、创建一个启动延迟（此操作非必需）
当出现所有的群集节点均同时启动并尝试附加到仲裁资源的情况时，群集服务可能无法启
动。
例如：
在发生电源故障后，同时对所有节点恢复电力时，可能出现这种情况。
（尽管可
能性比较低，但是还是有可能发生的。
）要避免这种情况，可以编辑boot.ini文件。
将Timeout
设置不同的值，以避免两个节点同时启动。
（1）打开ClusterNodeA上系统盘根目录下的boot.ini文件，按下图修改。
也许您会问，为什么要添加一行同样的记录。
这是因为如果是单操作系统，无论你如何设置
timeout的值都是没有用的。
只有多系统才会读取这个值。
所以我们复制同样的记录来实现
启动延迟的目的。
（2）同样的方法，将ClusterNodeB上的boot.ini文件的timeout值设置为其他数值。
如果您想
在恢复电力时，ClusterNodeA能够优先启动，就把ClusterNodeB上的timeout值大于10。
以错开同时启动。
5、测试群集安装
前面我们在CluterNodeA和CluterNodeB新建和加入现有群集结束后，都分别给出了一张截
图用来验证群集安装的正确性。
如果您觉得验证不周全，还可以采用如下几个方法来验证。
（1）最简单的验证就是通过群集管理器。
打开群集管理器，查看是否能够打开到群集的连接。
（2）查看群集服务是否启动
（3）相关事件日志
（4）相关注册表键值
七、故障转移测试
前面说了这么多，终于等到最激动人心的时刻了。
在这一环节中，我准备将测试分为初级测
试和高级测试两块来验证群集的故障转移功能。
1、初级测试
（1）打开群集管理器，从图中我们可以看出，目前数据共享磁盘的所有者是ClusterNodeA，
状态为联机。
（2）右键选择组0的“属性”，再选择“移动组”。
（3）可以看到此时的状态为“脱机挂起”。
（4）从图中可以得知，共享数据磁盘R的所有者已经转移到ClusterNodeB上了，状态为联
机。
（5）此实验说明，在群集服务中，资源能够从一个节点手动转移到另一个节点。
（当然也能
够自动转移，后面的实验均属于自动转移）
2、高级测试
（1）手工模拟故障1次
（1）打开群集管理器，对磁盘Q进行一次“初始故障”操作。
此时磁盘Q的所有者为
ClusterNodeA。
（2）可以看到磁盘Q已经联机挂起了。
（3）经过很短的时间后，磁盘Q又自动联机了，所有者还是ClusterNodeA。
（4）此实验说明，群集节点的资源，在遇到初始故障后，能够自我修复，重新回到联机状态。
虽然在这个实验中没有体现出能够初始故障多少次，但是我可以告诉大家，是3次。
如果初
始故障次数超过3次，就不会自我修复了，而是会进行故障转移。
下面的实验会证明这一点。
（2）手工连续模拟故障4次
（1）打开群集管理器，对磁盘R进行“初始故障”操作，重复4次。
此时磁盘R的所有者还
属于ClusterNodeA。
（2）4次模拟故障后，定位到“资源”，在右边窗口中可以看到，所有资源已自动迁移到
ClusterNodeB上，处于联机状态。
（3）由于心跳侦测机制的作用（心跳信息大约每1.2秒一次），群集服务会发现ClusterNodeA
并不是真正的宕机，所以ClusterNodeA会自动尝试联机。
（4）节点ClusterNodeA已恢复正常。
（5）此实验说明，在群集服务中，当某个节点故障超过3次后，则不会自动恢复，而是进行
故障转移。
同时也说明，当群集服务检测到原节点可用时，原节点会再次自动回到群集中。
此过程的专业术语叫“故障回复”
（3）停止群集服务测试
1）在停止ClusterNodeB上的群集服务前，先打卡群集管理器，可以察看到，目前资源的所
有者是ClusterNodeB。
2）停止ClusterNodeB的群集服务。
3）再次回到群集管理器，发现资源的所有者已经切换到ClusterNodeA上。
因为ClusterNodeB
上的服务已停止，不可能自动恢复过来。
仍旧通过心跳侦测机制，当丢失4次心跳信息后，
（大约5秒），则会宣告该节点失败。
所以图中显示红叉，表示ClusterNodeB这个节点目前
不可用。
4）此实验说明，当某个节点上的群集服务停止后，运行在该问题节点上的资源会自动转移
到其他正常节点。
（4）模拟意外断电时故障转移
1）测试前按照老规矩，打开集群管理器，可以看到资源的所有者是Clus
升级会员 