VMware Workstation 6.02 中Cluster配置指南(2)

 

VMware Workstation 6.02 中Cluster配置指南(2)

五、安装群集服务

1、在节点1上新建一个群集

(1)开启Cluster Node-1,同时保持Cluster Node-2处于关闭状态。展开Cluster Node-1的"开始"菜单,定位到"程序"-->"管理工具",打开"群集管理器"。见下图:

20032223

(2)选择"创建新群集"。 见下图:

20032224

  在操作里面选择创建新群集  按确定  接着下一步

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

20032225

(4) 输入新群集中的第一个节点的计算机名称,在计算机名里面输入Node-1  接着下一步  见下图:

20032226

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

20032227

(6) 输入群集的IP地址,该地址是Node-1和Node-2共同虚拟出来的群集IP。其FQDN地址对应于前面的ClusterTest.yejunsheng.com

20032228

  在IP地址里面输入192.168.0.10  接着下一步

(7)输入前面创建的群集服务账号。该账号可以不是域管理员,但是必须是各节点的本地管理员  见下图:

20032229

  输入用户名(ClusterService)和密码  接着下一步

(8)下图是配置信息汇总。如果发现配置有错误,可以点击"上一步"进行更改。否则点击"下一步",开始群集创建。

20032230

(9) 可以查看创建过程是否顺利。一般来说,只要前面群集前的分析没有问题,创建过程一般都不会有问题的

20032231

(10) 完成新建服务器群集向导。至此,我们已经成功的在Node-1上配置了群集服务。 见下图:

20032232

  按完成

(11)打开群集管理器,验证Node-1上的群集服务已成功安装。资源所有者均为Node-1,并均处于联机状态。 见下图:

20032233

2、将节点2加入现有群集

(1) 开启Node-2节点,同时不要关闭Node-1,否则无法加入现有群集。打开群集管理器,选择"添加节点到群集","浏览",找到之前创建的群集名ClusterTest。 点击"确定"。 见下图:

20032234

(2) 进入添加节点向导。见下图:

20032235

  接着下一步

(3) 选择您要添加到现有群集的节点。我这里选择Node-2  见下图:

20032236

(4)同样,节点加入前会进行群集配置分析。如果分析结果中有任何问题,请着手解决后再往下继续。 见下图:

20032237

(5)输入群集服务账号。 见下图:

20032238

  输入ClusterService的密码  接着下一步

(6) 群集配置信息汇总,返回修改请点击"上一步",继续请点击"下一步"。 见下图:

20032239

(7) 开始"添加节点到群集"的配置操作。见下图:

20032240

  接着下一步

(8) 完成节点添加工作。见下图:

20032241

  按完成

(9) 从下图可以看出,Node-2已成功加入现有群集,目前处于运行状态。

20032242

(10) 至此,我们成功的在Node-1上新建了一个名为ClusterTest的群集,并成功将Node-2加入该群集中。

(11) 细心的您在Node-2加入到现有群集后,可能会发现无法在Node-2上访问原有的共享磁盘。如下图所示。不要奇怪,只是正常现象。因为在群集服务中,同一时刻只能有一个节点对资源拥有所有权。在我这个例子中,此刻仲裁磁盘的所有者是Node-1,所以Node-2无法访问。反过来,如果所有者是Node-2,则会变成Node-1无法访问共享磁盘。

20032243

20032244

  我来到Node-1这台计算机 可以看到现在的所有者是NODE-1 在群集管理器里面展开组--对组0和群集组右键--选择移动组 

20032245

  我来到Node-2这台计算机 可以看到现在的所有者是NODE-2了 打开Q盘(共享磁盘)也可以访问到磁盘里面的资源了 此时如果你跑到Node-1上访问共享磁盘的话会发现不能访问的 因为现在所有者是NODE-2了

20032246

  我来到Node-1这台计算机--打开我的电脑--访问Q盘(共享磁盘)--可以看到无法访问Q:/。设备未就绪。

六、配置群集服务

1、群集网络配置

(1) 进行专用网络配置。打开群集管理器,单击"群集配置",单击"网络",右键选择Heartbeat的属性。 见下图:

20032247

(2) 选择"为群集使用启用这个网络"和"只用于内部群集通讯(专用网络)"。 见下图:

20032248

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

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

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

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

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

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

(3) 同样,进行公用网络配置  见下图:

20032249

2、心跳适配器优先化

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

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

20032250

3、仲裁磁盘配置

启动"群集管理器"。右击左上角的群集名称,然后单击"属性"。单击"仲裁"选项卡。在"仲裁资源"列表框中,选择"磁盘Q"。 见下图:

20032251

4、创建一个启动延迟(此操作非必需)

当出现所有的群集节点均同时启动并尝试附加到仲裁资源的情况时,群集服务可能无法启动。例如: 在发生电源故障后,同时对所有节点恢复电力时,可能出现这种情况。(尽管可能性比较低,但是还是有可能发生的。)要避免这种情况,可以编辑boot.ini文件。将Timeout设置不同的值,以避免两个节点同时启动。

(1) 打开Node-1上系统盘根目录下的boot.ini文件,按下图修改。

20032252

也许您会问,为什么要添加一行同样的记录。这是因为如果是单操作系统,无论你如何设置timeout的值都是没有用的。只有多系统才会读取这个值。所以我们复制同样的记录来实现启动延迟的目的

(2) 同样的方法,将Node-2上的boot.ini文件的timeout值设置为其他数值。如果您想在恢复电力时,Node-1能够优先启动,就把Node-2上的timeout值大于10。以错开同时启动。

5、测试群集安装

前面我们在Node-1和Node-2新建和加入现有群集结束后,都分别给出了一张截图用来验证群集安装的正确性。如果您觉得验证不周全,还可以采用如下几个方法来验证。

(1) 最简单的验证就是通过群集管理器。打开群集管理器,查看是否能够打开到群集的连接。 见下图:

20032253

(2) 查看群集服务是否启动  见下图:

20032254

(3) 相关事务日志  见下图:

20032255

(4) 相关注册表键值  见下图:

20032256

  通过开始--运行--输入regedit按确定来打开注册表编辑器  展开HKEY_LOCAL_MACHINE--Cluster--可以看到相关注册表键值

七、故障转移测试

前面说了这么多,终于等到最激动人心的时刻了。在这一环节中,我准备将测试分为初级测试和高级测试两块来验证群集的故障转移功能。

1、初级测试

(1) 打开群集管理器,从图中我们可以看出,目前数据共享磁盘的所有者是Node-1,状态为联机。 见下图:

20032257

(2)右键选择组0的"属性",再选择"移动组"。 见下图:

20032258

(3) 可以看到此时的状态为"脱机挂起"。 见下图:

20032259

(4) 从图中可以得知,共享数据磁盘R的所有者已经转移到NODE-2上了,状态为联机。 见下图:

20032260

(5) 此实验说明,在群集服务中,资源能够从一个节点手动转移到另一个节点。(当然也能够自动转移,后面的实验均属于自动转移)

2、高级测试

(1) 手工模拟故障1次

(1) 打开群集管理器,对磁盘Q进行一次"初始故障"操作。此时磁盘Q的所有者为NODE-1  见下图:

20032261

(2) 可以看到磁盘Q已经联机挂起了。见下图:

20032262

(3) 经过很短的时间后,磁盘Q又自动联机了,所有者还是NODE-1。见下图:

20032263

(4)此实验说明,群集节点的资源,在遇到初始故障后,能够自我修复,重新回到联机状态。虽然在这个实验中没有体现出能够初始故障多少次,但是我可以告诉大家,是3次。如果初始故障次数超过3次,就不会自我修复了,而是会进行故障转移。下面的实验会证明这一点。

 

(2) 手工连续模拟故障4次

(1) 打开群集管理器,对磁盘R进行"初始故障"操作,重复4次。此时磁盘R的所有者还属于NODE-1。见下图:

20032264

(2) 4次模拟故障后,定位到"资源",在右边窗口中可以看到,所有资源已自动迁移到NODE-2上,处于联机状态。见下图:

20032265

(3) 由于心跳侦测机制的作用(心跳信息大约每1.2秒一次),群集服务会发现Node-1并不是真正的宕机,所以Node-1会自动尝试联机。

(4) 节点Node-1已恢复正常。见下图:

20032266

(5) 此实验说明,在群集服务中,当某个节点故障超过3次后,则不会自动恢复,而是进行故障转移。同时也说明,当群集服务检测到原节点可用时,原节点会再次自动回到群集中。此过程的专业术语叫"故障回复"

 

(3) 停止群集服务测试

1) 在停止Node-2上的群集服务前,先打开群集管理器,可以察看到,目前资源的所有者是Node-2  见下图:

20032267

2)停止Node-2的群集服务。见下图:

20032268

3)再次回到群集管理器,发现资源的所有者已经切换到Node-1上。因为Node-2上的服务已停止,不可能自动恢复过来。仍旧通过心跳侦测机制,当丢失4次心跳信息后,(大约5秒),则会宣告该节点失败。所以图中显示红叉,表示Node-2这个节点目前不可用。见下图:

20032269

4) 此实验说明,当某个节点上的群集服务停止后,运行在该问题节点上的资源会自动转移到其他正常节点。

 

(4) 模拟意外断电时故障转移

1) 测试前按照老规矩,打开群集管理器,可以看到资源的所有者是Node-2。见下图:

20032270

2) 直接关闭虚拟机后,打开Node-1上的群集管理器,发现资源已经为脱机状态,且群集组已显示不正常。见下图:

20032271

3) 群集服务试图将资源所有者切换到Node-1上。见下图:

20032272

4)资源已全部迁移到Node-1上,且显示Node-2不正常。见下图:

20032273

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

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值