RHCS，fencing后服务器反复重启

bpxyz

（IE8，呕人啊）

vincent-zz

谢谢分享了，明天要搞一套RHEL5.4的HA，看了这个，就可能少走不少弯路

alonerhu

我在rhel 6.3上面遇到同样的问题了，上午好好的，后来有人做了个fence，然后就一直互相fence下去，晕死。
NetworkManager没有启用，做了bonding。
我觉得问题还是bondding。

翻遍了网络，最后有一个看起来比较靠谱的，有热心人翻译自社区的Q&A，摘录在这里：

在双节点集群需要使用仲裁和fencing。典型的，fencing需要仲裁来允许一个主节点在线。在一个双节点集群中，这意味着要求两个节点同时在线。所以，通过仲裁来解决允许一个节点结合仲裁来启动。这样，就可以允许两个节点都fence。
当两个节点彼此断开，它们都会变成quorate，然后彼此fence。如果操作失败，就会再次尝试fencing。此时一切正常。
问题是，如果两个节点后来又连接起来，但是它们彼此都已经fenced了。这时两个节点都会放弃fencing操作，因为远程节点已经”online”了。不幸的是，两个节点都具备状态，所以不会恢复。或者，更直接地说，一旦火并，必须有一个节点赢得控制。
那么，什么是问题？由于智能的网络交换机都具备防范spanning tree的功能，所以多播数据包将不会立即转发，这导致两个节点openais/cman问题。它们彼此fence对方，但是由于不能连接到fencing设备而失败。大约需要30到60秒，生成树（spanning tree）算法完成执行。Fencing已经结束了，但是没有任何一个节点赢得了控制。由于没有完成fence，这两个节点持续处于JOIN_START_WAIT状态而放弃fence doamin。

可以采用如下方式解决：

设置交换机的portfast或类似属性。这将立即完成spannging tree过程，通过跳过一些发现过程。对于Cisco交换机，参考Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays
使用廉价的交换机（呵呵，我倒，没有spannging tree功能）
临时使用交叉线

我的做法是修改/etc/sysconfig/cman，把里面CMAN_CLUSTER_TIMEOUT和CMAN_SHUTDOWN_TIMEOUT都改成了300。
如果是rhel5,可以直接在cluster里面<fencesdaemon post_join_delay="300" />