Red Hat Cluster Suite 组件 fencing FAQ

说明

Red Hat Cluster实现HA的关键组件之一是fencing。没有设置fencing，虽然看上去也能够运行Cluster，但是一旦遇到故障切换就会出现异常，所以深入理解fencing原理，正确设置fencing对构建Red Hat Cluster有很大意义。
笔记以英文原文 2010-04-09 版为基础翻译，译文仅供参考，请以英文原文为准。
原文： http://sources.redhat.com/cluster/wiki/FAQ/Fencing

什么是fencing并且为何需要使用fencing？

fencing是cluster项目的一个组件，用来切断集群中和其他节点失去联系的故障节点对一个资源的访问（例如，磁盘）。

最有效的fencing方式通常称为STONITH，也就是”Shoot The Other Node In The Head”的缩写。换句话说，就是强制系统断电或者重启。虽然看上去这种方式是粗糙的没有规划的，但实际上它是一个好东西。如果一个节点对集群的其他节点没有办法协作会不断地损坏数据，除非该故障节点被关闭。所以通过fencing故障节点，我们实际上保护了数据。
fencing通常使用一个网络电源切换机(network power switch)来实现，这个电源切换机可以通过网络管理，称为power fencing（电源阻断）。
fencing也可以通过切断访问资源来完成，例如使用SCSI reservation。这种方式称为fabric fencing（结构阻断）。

在Cluster Suite中支持哪些fencing设备？

这个硬件列表一直在修订。生产商不断推出新模块和新的微码，迫使Red Hat不断改变fence agent。最好查看CVS中的源代码去了解设备是否被提到：

http://sources.redhat.com/cgi-bin/cvsweb.cgi/cluster/fence/agents/?cvsroot=cluster

也可以检查硬件配置列表：

http://www.redhat.com/cluster_suite/hardware/

可以使用自己的watchdog或者手工fencing吗？

不能。在所有生产环境中，fencing都是绝对需要的。所以，不支持用户使用自己的watchdog。
在生产环境或任何关键环境中，手工fencing也是不支持的。

我该使用power fencing还是fabric fencing？

在应用中两者都使用。两种方式都是保证故障节点不能写入文件系统，这样来保证文件系统一致性。
然而，由于很多原因我们建议用户使用电源电路fencing。（后面一段请参考原文）

当fence失败或者fencing由于意外自身故障？

关闭fencing，或者强制fencing推出，如果那个节点使用的gfs不能正常工作。如果出现故障的节点没有运行fencing则这个节点将不能被fenced。可以通过简单重启来完成fencing。

HP的`iLo`（Integrated Lights Out）fencing不能正常工作，如何debug？

首先需要尝试使用命令行进行fencing，例如：

/sbin/fence_ilo -a myilo -l login -p passwd -o off -v

然后检查RIBCL的版本。可能需要升级firmware，或者查看bugzilla这个级别的firmware是否有bug。

什么是fence方法，fence设备和fence级别，并且它们哪个好？

一个节点可以有多个fence方式并且每个fence方式可以有多个fence设备。
多种fence方式设置可以冗余。例如，可以使用主板管理fencing方式来处理节点，如IPMI，或者iLO，或者RSA，或者DRAC。这些fencing方式都基于网络连接。如果这种网络连接失败，则fencing也会失败。所以采用一个后备的fence方式就可以采用类似电源切换机或其他方式来切断节点。如果第一种fencing方式失效，则可以采用第二种fencing方式。
每个fence方式可以采用多个fence设备，例如，如果一个节点有双电源并且可以采用power fence。则一个电源fenced之后，节点仍然不会重启（因为另外一个电源支持它运行）。这种情况下需要在一种fence方式中设置两个fence设备：一个用来切断A另一个用来切断B。
如果有些人说fence级别，实际上他们说的就是fence方法。这种方法是指”power”和”fabric” fencing。

为何节点X一直在fenced？

可能有多种原因导致节点重复fenced，但是底线是这个节点没有看到节点收到了fenced的心跳网络消息。
通常这是由于故障硬件，如坏的网线和坏的交换机接口导致。
要检查用于集群的通讯硬件设备确保通讯路径正常。

为何节点X在启动时就收到fenced消息？

如果网络非常繁忙，集群可能认为它没有收到足够的心跳消息，当节点加入集群时可能发生。可以通过修改cluster.conf中的配置项post_join_delay来改善。例如

<fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="600"/>

是否支持手工fencing？

不，不，一千次地重复“不”。你可以使用手工fencing，但是不能保证节点被fenced并且集群会锁住，服务不能failover。

但我不想购买一个网络电源切换机。为何不支持手工fencing？

因为我们不能保证以下情况：

……

什么时候发生一个节点撤回或收到fenced？

当一个节点不能和其他集群节点通过心跳数据包通讯，则该节点被其他节点fenced。
如果一个GFS文件系统检查到它刚刚执行了一个操作，它会撤回该操作。这个通过GFS撤回操作的方法比一个内核panic要好一些。这意味着这个节点察觉到自己不能安全对文件系统操作，因为它认为自己的假设是错误的。不是干扰内核，而是给你一个机会很好地重启该节点。

当我使用冗余电源的时候哪种方式配置fencing较好？

当使用冗余电源的时候需要很小心配置fencing。如果配置错误，每个电源将独立fencing并且其他电源支持会让系统持续运行。这样系统就不能fencing了。
如果采用双电源，并且电源插在同一个电源切换器上，使用端口1和端口2，则配置类似：

<clusternode name="node-01" votes="1">

<fence>

<method name="1">

<device name="pwr01" option="off" switch="1" port="1"/>

<device name="pwr01" option="off" switch="1" port="2"/>

<device name="pwr01" option="on" switch="1" port="1"/>

<device name="pwr01" option="on" switch="1" port="2"/>

</method>

</fence>

</clusternode>

...

<fencedevices>

<fencedevice agent="fence_apc" ipaddr="192.168.0.101"

login="admin" name="pwr01" passwd="XXXXXXXXXXX"/>

</fencedevices>

如果采用双APC network power switches（pwr01和pwr03），每个电源切换器都有自己的UPS和独立的IP地址。

<clusternode name="node-01" votes="1">

<fence>

<method name="1">

<device name="pwr01" option="off" switch="1" port="1"/>

<device name="pwr02" option="off" switch="1" port="1"/>

<device name="pwr01" option="on" switch="1" port="1"/>

<device name="pwr02" option="on" switch="1" port="1"/>

</method>

</fence>

</clusternode>

...

<fencedevices>

<fencedevice agent="fence_apc" ipaddr="192.168.0.101"

login="admin" name="pwr01" passwd="XXXXXXXXXXX"/>

<fencedevice agent="fence_apc" ipaddr="192.168.1.101"

login="admin" name="pwr02" passwd="XXXXXXXXXXX"/>

</fencedevices>

有一些特定有关配置fencing设备的建议吗？

有一些，对于WTI请参考： http://people.redhat.com/lhh/wti_devices.html

双节点：在启动时fencing收到`JOIN_START_WAIT`，但是节点不能彼此看到。为什么？

在双节点集群需要使用仲裁和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功能）
临时使用交叉线
在”dumb”模式使用qdiskd，这将确保节点同时启动状态一个节点完成仲裁。如果同时禁止了allow_kill和reboot选项，这个过程将不会引入其他明显的集群特征变化。这个方式要求共享存储。