转载

RedHat集群配置节点反复重启问题

在使用Dell 730 X86服务器，操作系统redhat 6.6安装RHCS的时候，出现HA集群在配置完成后出现两台机器反复重启的情况。即两个集群节点始终都只有一个状态能够是online状态。当A机是online状态的时候，如果这个时候去启动B机的cman和rgmanager的时候，即出现fence error的情况，直接将A机踢出并进行重启。

#service cman start

#service rgmanager start

网上的文章初步看了下，基础的分析情况如下：

1、网络交换机，对于有些交换机型号（如CISCO）必须设定PORTFAST（可能是这么拼，我对交换机不熟悉）。而有些品牌的型号（如TPLINK）缺省就设定了PORTFAST。

2、fence_ilo的版本问题。我用RHCS 4.5，就出现了不断重启，下载了最新4.7的fence包，才解决的。

再详细说一下有关fence版本的问题，在4.5中，fence_ilo xxxx -o off能正常关机，但fence_ilo xxxx -o on或者-o restart报错，不能重新启动机器。假设A机正常工作，B机关着，那么A机的fenced服务会不断发fence信号（相当于 fence_ilo xxx -o restart，都是通过fence agent来发出的)，让B机重启，但由于fence 不能在OFF的状态把B机启动，所以会一直报fence failure。而手动启动B机，刚启动，A机的fence信号又发过来，让B机RESTART，结果就是B机OFF以后不能START。

具体在启动的时候系统日志会报如下错误：

fence[4407] fence dev ** agent fence_ipmilan result: error from agent

fence[4407] fence *** failed

注：A机发fence 信号的周期是10秒左右，0秒发出fence 信号（fence node "nodename")，5秒就能返回失败信号（fence "nodename" failure），10秒再发出fence信号。以上过程在B机未能重启的情况下，一直重复。

对于dell 730的fence设备已经升级为idrac8，而不是原来的drac设备。对于该问题，按照检查的步骤初步进行了如下的检查。即首先确认ipmitool本身设备正常。

#ipmitool -H 192.168.100.1 -I lanplus -U Administrator mc info

注意：在配置fence_ipmi时需要在/etc/cluster/cluster.conf中加入lanplus=1（ILO3需要）

在做RHCS集群中，选择IPMI进行Fence配置时，仅仅验证ipmitool测试正常是不够的。还需要验证RHCS中的agent是否可以正常工作，因为我通过ipmitool lan print 1 发现验证仅支持MD5(网上一堆案例都搞不清auth的问题，有贴auth="none"的，有贴auth="password"的，只有通过上述方法验证后你才能确定到底是什么原因)，所以使用以下指令进行agent的验证试探。具体命令如下：

一开始没有输入-P参数，导致返回错误，在输入-P参数后验证方式为md5的时候，返回正常。在这里测试正常后需要配置cluster.conf里面的fence设备参数部分，在这个里面将直接影响到整个fence操作是否正常。

在这里最麻烦的主要还是agent设备的选择，我们分别测试了fence_drac5, fence_idrac和fence_ipmilan，最后发现对于dell的idrac8还是要选择fence_ipmilan设备，在这里修改完成后，又先后通过网上材料的搜索尝试对如下的内容进行修改和调整

#网上有说是超时时间太短，增加power_wait="2" timeout="35"，问题没有解决。

#redhat网站有说在选择fence_ipmilan设备时候需要配置 privlvl="operator"，问题依然存在没有解决

#对于fence_ipmilan测试，当不加auth="md5"的时候也可以通，该为auth="none"验证，发现在验证后两个节点可以启动起来，但是发现fence设备本身的ipmitool出现不稳定的新问题，具体如下：

Error in open session response message : insufficient resources for session

Error: Unable to establish IPMI v2 / RMCP+ session

问题还是没有得到彻底解决，感觉越尝试问题越多。由于在出现该问题的当天，我们初步查找到网上有反馈说是由于交换机本身的multicast组播策略有问题，但是当时没有引起足够的重视，该问题反馈的现象和我们遇到的情况也相当类似，即由于心跳检测本身是走的交换机的组播，当A机器向B机器发出multicast信息的时候如果没有及时的得到反馈，则A机器会认为B机器服务已经宕掉，而通过fence强制B机器进行重启。具体看参考文章1和文章2的描述：

在这个问题出现的时候，我们首先还是通过命令进行了两台机器的心跳检测，测试的情况是心跳本身是正常的。但是由于由于两台机器的心跳线是通过交换机连接，而且和业务网络连接的交换机是不同的两台。因此，对于对于是由于组播原因引起的可能性还是很大。

对于心跳线，我们考虑是否修改为双机直连，但是在双机直接连接的情况下很容易发送脑裂现象。

基于冗余的角度考虑，应该在主、备服务器使用两个物理连接传输heartbeat的控制信息；这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的“脑裂”（split-brain）或“partitioned cluster”。在两个节点共享同一个物理设备资源的情况下，脑裂会产生相当可怕的后果。一般心跳线失效的时候会出现这种状况。

因此建议还是连接在交换机上更加保险，当我们将业务网络和心跳网络都连接到同一台交换机上的时候，本文提到的异常和故障问题解决，基本还是说明是由于交换机组播问题引起，真是坑人啊。

参考文章

1)http://h30499.www3.hp.com/t5/General/Redhat-cluster-start-cman-fence-the-other-node/td-p/5402363?notmigrated#.VbsetfnsnCk

2)http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/68131-cat-multicast-prob.html

3)http://linux.die.net/man/8/fence_ipmilan. --ipmilan详细参数说明

4)https://access.redhat.com/solutions/175603

5)https://access.redhat.com/search/#/?q=fence error from agent

6)https://access.redhat.com/solutions/18431

7)http://wenku.baidu.com/view/c7cc4507767f5acfa0c7cd21.html --fence问题详细描述

正文到此结束