VMware Workstation 6.0 中Cluster配置指南

服务器群集是一组协同工作并运行Microsoft群集服务（Microsoft Cluster Service，MSCS）的独立服务器。它为资源和应用程序提供高可用性、故障恢复、可伸缩性和可管理性。它允许客户端在出现故障和计划中的暂停时，依然能够访问应用程序和资源。如果群集中的某一台服务器由于故障或维护需要而无法使用，资源和应用程序将转移到可用的群集节点上。

（说明:本文档编写的目的是为了帮助大家实现所关心的如何在VMWare Workstation中完成典型群集的配置步骤，不会具体的涉及到如何安装群集应用程序，如Exchange群集等）

二、群集专业术语

节点: 构建群集的物理计算机

群集服务: 运行群集管理器或运行群集必须启动的服务

资源: IP地址、磁盘、服务器应用程序等都可以叫做资源

共享磁盘: 群集节点之间通过光纤 SCSI 电缆等共同连接的磁盘柜或存储

仲裁资源: 构建群集时，有一块磁盘会用来仲裁信息，其中包括当前的服务状态各个节点的状态以及群集转移时的一些日志

资源状态: 主要指资源目前是处于联机状态还是脱机状态

资源依赖: 资源之间的依存关系

组 : 故障转移的最小单位

虚拟服务器: 提供一组服务--如数据库文件和打印共享等

故障转移: 应用从宕机的节点切换到正常联机的节点

故障回复: 某节点从宕机状态转为联机状态后，仍然继续宕机前的工作，为其他节点分流

三、实验环境介绍及要求 1、拓扑图

2、软件配置说明 (1) DC软件配置信息

OS:Windows Server 2003 X86 SP1 中文企业版

Role: Active Directory域控制器

Domain:test.com

ServerName:DC.test.com

IP:192.168.0.254 （以“桥接”方式连接）

Netmask:255.255.255.0

Gateway:192.168.0.254

(2) Cluster Node A软件配置信息

OS: Windows Server 2003 X86 SP1 中文企业版

Role: Member Server

ServerName:ClusterNodeA.test.com

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) Cluster Node B软件配置信息

OS: Windows Server 2003 X86 SP1 中文企业版

Role: Member Server

ServerName:ClusterNodeB.test.com

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) 仲裁磁盘空间大小最小50 MB。为了得到最佳的NTFS文件系统性能，建议采用最小500 MB的磁盘分区。

5) 所有共享磁盘必须配置为基本磁盘，而不能为动态磁盘。

6) 共享磁盘不支持软件容错，不要再试图对共享磁盘做软RAID。

7) 如果您使用的是64位版本的Windows Server 2003的系统，需要注意的是，所有共享磁盘必须配置为主引导记录（MBR），也就是建立主分区。也不要试图配置为GPT磁盘，因为它不能作为群集磁盘得到支持。

8) 群集磁盘上的所有分区必须格式化为NTFS。

9) 群集节点的操作系统必须采用同架构的版本，不能节点A采用32位系统，而节点B却使用64位系统。

(说明:在本次实验中，模拟的SCSI共享磁盘柜均是通过VMware Workstation自带的相关工具来创建)

四、安装群集前的准备工作 1、创建共享磁盘 (1) 创建用来保存共享磁盘的目录

在本实验中，我在D:\Virtual Machines目录下新建了一个ShareDisks文件夹，用来保存后面两个操作建立的虚拟仲裁磁盘文件和数据磁盘文件。

(2) 创建仲裁磁盘

进入VMware Workstation软件安装目录，在命令提示符窗口敲入如下命令:

vmware-vdiskmanager.exe -c -s 600Mb -a lsilogic -t 2 “D:\Virtual Machines\ShareDisks”\Quorum.vmdk

(3) 创建数据共享磁盘

进入VMware Workstation软件安装目录，在命令提示符窗口敲入如下命令:

vmware-vdiskmanager.exe -c -s 2Gb -a lsilogic -t 2 “D:\Virtual Machines\ShareDisks”\ShareDisk.vmdk

(4) 验证共享磁盘是否成功创建

进入D:\Virtual Machines\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:\Virtual Machines\ShareDisks\Quorum.vmdk"

scsi1:6.present = "TRUE"

scsi1:6.fileName = "D:\Virtual Machines\ShareDisks\ShareDisk.vmdk"

2) 在ClusterNodeB上重复前一个操作，并做相应的修改。

3) 关闭VMware Workstation软件后再次打开，会发现先前创建的共享磁盘均附加到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记录名:ClusterTest.test.com

(3) ClusterNodeA上的共享磁盘配置

1）启动ClusterNodeA(不要开启ClusterNodeB，使其保持关闭状态。这样有助于保证附加到共享总线的磁盘上的数据不会丢失或遭到破坏。)

2）打开ClusterNodeA 的“磁盘管理”，系统会自动找到先前创建的两个共享磁盘。进入 “磁盘初始化和转化向导”

3） “新建磁盘分区”

4）选择建立“主磁盘分区”。

5）给仲裁磁盘分配一个约定成俗的驱动器号Q。

6）一定要格式化成为NTFS，同时把卷标改成“Quorum”。

7）以上是对仲裁磁盘进行操作，按照同样的方法，对共享数据磁盘进行操作。分配驱动器号为R，卷标名为Data。（具体过程略）。另外，需要补充一点的是，通常，驱动器盘符“Q”用于仲裁磁盘，而“R”、“S”等字母则常用于数据磁盘。尽管您可以按照个人喜好随意更改，但是建议采用约定成俗的规定。

8）对共享磁盘的操作完成后，建议验证一下磁盘是否可读写。方法是新建一些文件后再删除，看看是否都正常。

(4) 网络配置

1）为了接下来的实验更加直观，建议把两块网卡进行重命名操作。生产环境也推荐这样操作。

2） Hearbeat Connection网卡（以下改称为心跳网卡）的TCP/IP属性如下。不要对心跳网卡设置默认网关和DNS地址。

3） 按照下图修改心跳网卡的高级TCP/IP属性，目的是禁止心跳网卡的DNS和NetBios查询。这样能够消除可能出现的通信问题，也有利于减少不必要的网络流量。因为服务器群集节点间的通信对于群集的顺畅运转至关重要。

4）按照微软官方推荐的做法，如果您拥有一个能够以不同速度进行传输的网卡，那么您应该手动指定同一个速度及双工模式。不要对传输速度应用自动选择设置，因为某些适配器在确定速度时可能丢掉一些数据包。这直接影响到群集节点之间的通讯质量。Microsoft建议您将同一路径上的所有设备设定为“10 M”和“半双工”。同时，如果您的网卡支持Teaming冗余，而您又无法确保该特性和群集之间的兼容性时，建议取消该特性。由于虚拟机无法对网卡的物理属性进行该类设置，如下图所示。

故特意从生产环境HP服务器上截取了如下两张图来说明。

5）至此，有关ClusterNodeA的前期网络和系统的相关配置已结束。接下来按照类似的方法对ClusterNodeB进行配置。

(5) ClusterNodeB上的共享磁盘配置

1） 关闭ClusterNodeA，开启ClusterNodeB。在此期间，请保持ClusterNodeA处于关闭状态。原因前面已经说明，不再赘述。（请尽量按照下图的方式关闭ClusterNodeA，而不只是简单的关闭系统）

2）打开ClusterNodeB的磁盘管理器，可以看到之前创建的共享磁盘同样被系统发现了。只是由于Windows Server 2003系统的设计使然，没有自动为其分配驱动器号。我们需要手工对它分配和ClusterNodeA相同的驱动器号。

3）为了实验的直观性，建议将卷标也进行修改。卷标名建议和ClusterNodeA上的保持一致。

4）同样，建议用同样的方法验证一下磁盘是否可正常读写。

5）至此，我们已完成两个节点的网络和系统相关配置。下面，我们开始进入真正的群集服务安装环节。

五、安装群集服务 1、在A节点上新建一个群集

(1) 开启ClusterNodeA，同时保持ClusterNodeB处于关闭状态。展开ClusterNodeA的“开始”菜单，定位到“程序”à“管理工具”，打开“群集管理器”。

(2) 选择“创建新群集”。

(3) 输入您公司的域名和事先准备好的群集名。如果有需要，在DNS中对该群集名建立对应的A记录。

(4) 输入新群集中的第一个节点的计算机名，这里我们选择ClusterNodeA

(5) 这时会对群集配置进行一个完全分析。如果有任何一项无法通过检测，务必检查原因、排除问题。故障排除后，不需要重新再来，只需点一下“重新分析”按钮就行。

(6) 输入群集的IP地址，该地址是ClusterNodeA和ClusterNodeB共同虚拟出来的群集IP。

其FQDN地址对应于前面的ClusterTest.test.com.

(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) 选择“为群集使用启用这个网络”和“只用于内部群集通讯（专用网络）”。

对上图中的几个选项，我稍微做一下解释:

为群集使用启用这个网络: 如果选定了该复选框，群集服务将使用该网络。默认对所有网络选定该复选框。

只用于客户端访问（公用网络）:如果您想让群集服务仅使用该网络适配器与其它客户端进行外部通信，那么选择该选项。该网络适配器将不进行节点对节点通信。

只用于内部群集通信（专用网络）:如果您想让群集仅使用该网络进行节点对节点通信，那么选择该选项。

所有通信（混合网络）:如果您想让群集服务使用该网络适配器进行节点对节点通信和外部客户端通信，那么选择该选项。默认对所有网络选定该复选框。

在本次实验中，我们仅使用到了两个网络:Public Connection和Heartbeat Connection。基于最常见的配置，我们将这两个网络分别作为混合网络和专用网络。

(3) 同样，进行公用网络配置

2、心跳适配器优先化

(1) 由于群集服务总是尝试使用列于首位的网络适配器进行节点间的远程过程调用（RPC）通信。只有当群集服务无法使用第一个网络适配器进行通信时，才会使用列表上的下一个网络适配器。所以我们需要调整一下心跳适配器的优先级。

(2) 启动群集管理器。右击群集名称，然后单击“属性”，在弹出的对话框中单击“网络优先级”选项卡。将Heartbeat Connection 上移至顶部。

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）测试前按照老规矩，打开集群管理器，可以看到资源的所有者是ClusterNodeB。

2）直接关闭虚拟机后，打开ClusterNodeA上的集群管理器，发现资源已经为脱机状态，且群集组已显示不正常。

3）群集服务试图将资源所有者切换到ClusterNodeA上。

4）资源已全部迁移到ClusterNodeA上，且显示ClusterNodeB不正常。

5）此实验说明，当群集中的节点遇到突发性的意外事件（如意外断电等。）后，资源会自动从问题节点转移到正常节点。

八、结束语

如果您完成了本指南全部的实验环节，那么恭喜您！您已经完成了所有节点上的群集服务配置。服务器群集已经完成可以运作了。您现在可以准备安装群集资源，比如：文件共享、打印机共享、诸如分布式的事务协调器、DHCP、WINS等群集识别服务、或者诸如Exchange Server或SQL Server等群集识别程序。

转载于:https://blog.51cto.com/windows2008/108963

weixin_33858249

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
VMware Workstation 6.0 中Cluster配置指南

VMware Workstation 6.0 中Cluster配置指南目录一、群集介绍... 3 二、群集专业术语... 3 三、实验环境介绍及要求... 4 1、拓扑图... 4 2、软件配置说明... 4 (1) DC软件配置信息... 4 (2) Cluster Node A软件配置信息... 4 (3) Cluster Node B软件配置信息....
复制链接

扫一扫