RHEL High-Availability Solution

RHEL High-Availability Solution

简介

Clustering 分类

表1：HA Hardware redundancy for fault tolerance 解决方法

问题 解决方法
磁盘故障 采用硬件 RAID
RAID 控制卡故障 双重的 RAID 控制卡以提供存取RAID资料
Heartbeat 失效 以太网络的 channel bonding 以及fault tolerance
电源来源失效 备用不断电系统(UPS)
所有失效状况下的资料毁损 电源切换器或硬件为基础的 watchdog

「SPOF」 ( Single Points Of Failure )
HA 的基本准则是硬件都必需使用具有Redundancy 的硬设备，例如RAID、Dual Power。最主要原因是为了避免造成「SPOF」 ( Single Points Of Failure ) 的情形发生。什么是「SPOF」? 所谓「SPOF」是指当某个零件故障会造成整个系统无法正当运作，那么这个零件就是整个系统中的Single Points Of Failure。
例如在 Client/Server 环境中，一个服务器系统中的单一网络卡即为这个服务器的 SPOF。同样的，连接到外部储存系统的单一 SCSI 配接卡是 SPOF。 如果一群服务器中的一整个服务器故障，并且这个故障的服务器不能被轻易且快速的由其它服务器置换，那么对这个服务器群组或丛集而言，这个服务器就是一个 SPOF 。

这个解决方法十分简单：配接卡只要借着在一个服务器中设置两张卡，并确认主要配接卡失效时备援配接卡会成为 active ，就可以达成备援( redundancy )。

提供 “failover”机制
如果一台服务器停机或故障, 另一台服务器可以接手( takeover )激活应用程序
以及以下情况发生时仍可以让应用程序正常运作
硬件故障
系统维护及升级
一个典型的High availability clusters 的架构应如图2，这两台服务器彼此如何沟通，还有常见Share Disk Storage 又有那些?接下来笔者便为各位介绍这些相关技术。

http://www.linux.gov.cn/himages/Linux/cluster/RHEL/RHEL2.png
图2：High availability clusters 架构图

High availability clusters 中的通讯机制

Clusters 内部的通讯机制来确保资料的完整性以及当发生Cluster 成员故障情况时能及正修正Cluster 的行为，Cluster 使用这些机制来做以下的事情：

控制系统何时能成为一部Cluster 成员
决定Cluster 系统的状态
当问题发生时，控制Cluster 的行为
RedHat HA Cluster 相关通讯机制如下：

Ethernet 的 heartbeats
「heartbeats」这个名词在各家HA 解决方案中可都是少不了他的身影，「heartbeats」是「心跳」的意义，笔者觉得老外用这个字真的是非常贴切，所 谓「heartbeats」的机制就是用来检查另一台服务器是否仍正常运作的机制。是不是很像人类利用有无心跳来判断一个人是否还活着。

Cluster 成员之间是由点对点的Ethernet 网络线来联机的，每一部成员将会定期地向这些网络线发出 heartbeats ( ping ) 讯号，Linux-HA 使用这个信息来帮助找出成员的状态，并且确保正确地Linux-HA 操作。

共享的(quorum)分割区
在 Linux-HA 中每一部服务器将会定期地写入一个时间戳记( time-stamp )与系统状态到 primary 与 shadow 的共享分割区，也就是位于Share Disk Storage中的某块空间 ( raw partition ) 。 每一部成员将读取由其它成员所写入的系统状态与时间戳记( time-stamp )，以找出它们 的状态是否更新。 成员将会试着从 primary 共享分割区读取信息。 假如该分割区已毁损，成员将会从 shadow共享分割区读取信息，并且同时修复 primary 分割区。 将透过错误检查(checksums) 维护资料一致性， 而且分割区间的任何不一致性都会自动地修正。
远程的电源开关监视
Cluster 中的成员将会定期地监视远程电源开关（假如有的话）联机的使用状况，成员使用这个信息来帮助找出 其它Cluster 成员的状态，电源开关通讯机制的完全失效并不会自动导致failover，假如电源开关无法 power-cycle 一部当机的系统，将不会执行任何的failover，因为Cluster 的基础架构无法保证成员目前的状态。
假如一部成员发现来自另一成员的时间戳记( time-stamp )并没有实时更新，它将会检查 heartbeat 的状态，假如向其它成员发出 heartbeat 讯号的动作仍在执行中，Cluster 管理程序将不会采取任何动作。 假如一部成员在一段时间后都没有更新它的时间戳记( time-stamp )，而且也不响应 heartbeat pings 的讯号，该部成员将被认定已停止运作。

只要有一部服务器可以写入共享的分割区，实时所有其它的通讯机制都失效了，丛集仍将维持运作的状态。

请注意，在某些两部成员的设定中，共享的分割区只被用来当作一个备援，网络成员的算法是对Cluster 成员 是否正在使用中的主要决定因素。 在这个设定中，不更新时间戳记( time-stamp )的一部成员绝不会failover 的发生， 除非clumembd 回报该成员已停止运作。

Share Disk Storage

常见的Share Disk Storage 技术有下列三种：SCSI、SSA、Fibre

SCSI ( Setting Up a Single-initiator SCSI Bus )
如果您的Share Disk Storage 要采用SCSI 的装置，必须选择有支持多主机通道（Multi-Host），其常见的架构如图3。两个 single-initiator 的 SCSI 总线在一个单一控制卡 RAID 数组的阻绝器，一个 Single-initiator SCSI 总线只允许一个成员连接到它，并且提供主机的分离与比一个 multi-initiator 总线更佳的效能表现。 Single-initiator 的总线确保每 一个成员都能免于由于其它成员的系统负载初始或修复所引起的干扰。
http://www.linux.gov.cn/himages/Linux/cluster/RHEL/RHEL3.png
图3：连接到 single-initiator 的 SCSI 总线的单一控制卡 RAID 数组示意图

SSA ( Serial Storage Architecture )
串行式储存架构（ SSA ）是由 X3 授权标准委员会的 X3T10 技术委员会中的 X3T10.1 工作群组所正在发展的高效能串行式计算机与外围接口。最初由 IBM发展， 现今 SSA 是由 SSA 工业协会 推广的开放技术。
SSA 基本上是一个执行于 SCSI-2 软件协议的串行式技术。意思是 SSA 配接卡的装置驱动程序应该可以很容易地整合到现有的 Linux SCSI 子系统。底线是，资料是透过以 200 MBit/s 全双工传输的双绞电缆来传送，而这比 68 Pin的平行 Wide SCSI 技术更易于处理。

SSA 和 SCSI 相较之下，有下列优点：

1)它更易于设定和接线 ( 它不需要终端电阻)。
2)它内建了 HA 特征。SSA Loop 架构（相对于SCSI 总线）没有 SPOF（参考图4）。如果部份的Loop 失效，装置驱动程序将自动并透明地重新自我设定以确保所有的 SSA 装置可被存取而没有任何明显的中断。
3)它不是使用 SCSI ID 寻址，意指设定配接卡毫无困难。
4)相对于 SCSI ， SSA 没有使用总线裁决。而是使用类似网络的设计。资料以 128 字节的封包被送出和接收，而且循环上的所有装置可以独立的请求 time slots 。反过来 SCSI 需要总线裁决，如果 initiator 没有及时释放总线可能导致效能死结。
5)SSA 允许每两个装置间相距 25 公尺。再者，有允许资料穿过 50 微米的光纤电缆传送达 2.4 公里的距离的光纤延伸器。如果设定适当的话，会使得它甚至合适于站台灾难回复。
6)大部分的 SSA 配接卡支持两个独立的循环，使得连结镜射的磁盘到不同循环以提高可用性成为可能。
7)SSA 循环是对称的，双绞线，自由电位的。没有 TERMPWR 电位移的问题。

http://www.linux.gov.cn/himages/Linux/cluster/RHEL/RHEL4.png
图4： SSA 示意图

SSA 是一个比SCSI 优良的技术，不过很可惜地，SSA 磁盘只能从 IBM 购买，取得成本太高，这些磁盘价格远高一般的 SCSI 磁盘价格。而且至今在Linux上仍没有够成熟的SSA Driver。

Fibre Channel Interconnect
Fibre 是笔者最喜欢的解决方案，也是笔者认为是比较有扩展性且适合大型企业的架构。较简单经济的架构便如图5 所示，两个主机连接端口的一个单一控制卡RAID 数组，没有使用Fibre Hub 或Switch，主机连接端口配接卡直接联机至 RAID控制卡。当您使用这种类型的 single-initiator 光纤信道联机，您的RAID 控制器必须拥有分开的主机连接端口给每一部Cluster 成员。
http://www.linux.gov.cn/himages/Linux/cluster/RHEL/RHEL5.png
图5：连接到 single-initiator 的 SCSI 总线的单一控制卡 RAID 数组示意图
IP Address Takeover

最后笔者要介绍IP Address Takeover 技术，通常客户端机器和应用程序无法在运作时，从几个 IP Address 中选择一个IP Address 来存取服务器。所以主要的服务器无法提供服务时，接管的节点必须在重新激活应用程序之前取原来提供服务的IP (well-known IP Address )。这个程序称之为 IP Address Takeover（ IPAT ）。它的基本运作原理如下：

HA Clusters 的成员在有两个网络接口，一个是Service IP Interface、一个是Standby IP Interface。如果它是具有较高优先权的节点或是主要节点 ( Primary Node )，一旦这个节点取得资源群组，Service IP Interface 将会变成这个对外提供的服务IP Address。

例如在Linux HA 激活前，Primary Node 与 Secondary Node 上的IP Address配置如下表：

表2：Linux HA 激活前的IP 配置表

Interface Node 1 (primary) Node 2 (secondary)

Service 192.168.10.10 192.168.10.20

Standby 192.168.11.10 192.168.11.20

表2 是Linux-HA 被激活之前的情形。 两个服务接口都位于它们个别配置的启动地址上。备援接口位于它们的备援地址上。假设整个Clusters 对外服务的IPAddress ( 也就是Client 连至Clusters 的IP address )为”192.168.10.11”。当Linux-HA 被激活于两个节点时，由于Node 1 是主要节点，它将取得对外服务地址。

表3：Linux HA 激活后的IP 配置表

Interface Node 1 (primary) Node 2 (secondary)

Service 192.168.10.11 192.168.10.20

Standby 192.168.11.10 192.168.11.20

假设主要节点的服务( Service ) 网卡故障，则备援( Standby )配接卡将接管服务地址 ( 192.168.10.11 )，如表4。

表4：主要节点的服务网卡故障后的IP 配置表

Interface Node 1 (primary) Node 2 (secondary)

Service 192.168.10.20

Standby 192.168.10.11 192.168.11.20

假设主要节点Node 1 故障，Node 2 将取得包括于资源群组中的服务地址，如表5。

Interface Node 1 (primary) Node 2 (secondary)

Service 192.168.10.20

Standby 192.168.10.11

由以上这个简单的例子中，我们也可以移动192.168.10.11 到节点2 的服务配接卡，但是移动到备援配接卡较为适合。

首先，备援配接卡就不再需要了，也就是Node 2 的备援配接卡也有Client 连线，并提服务，而不是闻置在那儿做备援。

其次，节点 2 也可能正在执行一个资源群组（相互接管）。如果服务 IP Address总是移动到存活节点的相同的（即备援）配接卡，那么移动”对外服务IP Address”的逻辑就得较为简单。

读者看到HA 利用四张网卡来提供一个对外服务的IP，一定会觉得麻烦又眼花瞭乱。虽然我们也可以每个节点只使用一张配接卡于。但是有两个原因不建议这样做。

首先，如果一个节点的配接卡失效，无法判断是只有配接卡或整个实体网络失效。

其次，如果我们加入逻辑来判断是否是配接卡或是网络失效，我们可能必须立即执行节点的failover，而这要花费比本地端配接卡failover 还要更长的时间。
后记

笔者一直希望RedHat 能推出一套可靠好用Linux HA 解决方案，看到Cluster Suit 的推出真是令人雀跃。这期文章笔者先介绍HA 解决方案中常见的技术及观念，下期我们再来卷起袖管打造全年无休的RedHat High Availability Cluster。

作者：IBM 林彦明(Alex Lin)