fencing— Red hat cluster

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中的源代码去了解设备是否被提到:

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

可以使用自己的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,例如:

1

/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来改善。例如

1

<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_killreboot选项,这个过程将不会引入其他明显的集群特征变化。这个方式要求共享存储。
黑洞@heidsoft
Github:https://github.com/heidsoft
微博:http://weibo.com/liuganbin
热衷云计算和大数据
关注CloudStack,OpenStack,Linux c/c++/python/java
关注研究新技术
上一篇:Linux7安装pacemaker+corosync集群-02--配置集群文件系统gfs2(dlm+clvmd)


下一篇:CF349B - Color the Fence(贪心)