RHEL High-Availability Solution 由于网际网络及电子商务的盛行改变了企业Business Model，现在企业的顾客巳不是局限在Local 的客户。全世界都有可能是您的客户，加上人们生活型态改变，所以全年365 天24 小时随时都可能有商机产生。 当信息系统发生无可预期的停机事件时，除了企业损失生产力、客户与收入。还可能遭遇到进一步受罚、诉讼、声誉不良的影响。此外，拥有一个永不打烊( High Availability )的运作模式，更是一个不容忽视的竞争优势和服务关键。所以现在许多企业除了要求伺服系统能在上班时间提供可靠与连续运转的服务，更希望能对客户提供24 X 7 全年无休的服务。
简介 在商业的 Unix 市场中，高可用性 ( High Availability ) 是销售Unix 服务器解决方案的关键。事实上每个 Unix 供货商都有他们自己的高可用性软件解决方案，例如IBM 的高可用性丛集软件解决方案，就是 AIX 上的HACMP ( High Availability Cluster Multi-Processing ） 。其它主要的 Unix 供货商像 HP，Sun，DEC 和其它的供货商有许多类似的软件解决方案可用。 High Availability 是现今销售Unix 给许多企业的关键。特别对于需要web-based 和其它必须一整年，每周七天，每天 24 小时可用的服务器。至于新窜起的网格运算市场而言更是如此。但是在Linux 一直没有很成熟的HA 解决方案，即便是RedHat 在Advanced Server 2.1 上提出的HA 解决方案和其他的Unix 厂商的HA 解决方案也有一段不小的差距。 不过，随着RedHat Enterprise 3.0 的推出，Red Hat 在其上推出一个重量级企业应用软件「RedHat Cluster Suite」，使得情况有所改观。Cluster Suite 包含两个技术：Cluster Manager 和 Linux Virtual Server。Cluster Manager 是HA 的最佳解决方案，只要两台服务器和共享的外接储存设备，透过Cluster Manager 来控制服务器所执行的服务，就可轻松达成HA 的目的。不过Red Hat Cluster Suite 不包含在RHEL 3.0 中，它必须额外购买。而且只支持 RHEL AS 和 ES 版。(图1) 点击查看大图 图1：RedHat 产品架构图 笔者一直认为Linux 要成为企业重要关键的服务器，甚至取代高阶Unix 的服务器，稳定可靠的HA 的解决方案是不可或缺的。但 RedHat 一直没有推出笔者认为足以媲美 AIX HACMP 的产品。总算随着RedHat Enterprise 3.0 的上市，也推出了Red Hat Cluster Suite。它比之前AS 2.1 稳定性更高，而且也较容易设定。本篇文章先为读者介绍 Cluster、HA 等相关技术及观念，下一篇文章笔者将利用RedHat Cluster Suite 实作HA 解决方案。
Clustering 分类 笔者有时遇到客户或学生询问Cluster 丛集系统及High Availability 相关问题，总觉得Cluster、HA、High performance 这几个名词常让人混洧。就笔者的看法，「所谓Cluster 就是由一台以上的机器为了某种特定需求所组成的架构」，根据不同的需求我们可将Cluster 分为以下三种，并对应RedHat 由何种软件提供相关功能。 High availability clusters 增加服务器和以网络为基础的应用程序的高可用性及备援性。由 Cluster Suite 中的Cluster Manager 技术提供 Load Balancing clusters 将服务需求分派给多台服务器，可视系统负载随时弹性增加服务器由 Cluster Suite 中的 Linux Virtual Server (Piranha) 技术提供 High performance clusters (HPC) 提供同步运算及平行处理的能力 Cluster Suite 不提供 (另外有 lam、pvm 套件，规划由WS 担纲) 本篇文章最主要介绍有关「High availability cluster」相关技术，其它两种 Cluster 不在此次探讨范围内。RedHat Cluster Manager 是以 open source Kimberlite cluster project 为基础来发展而来，读者可参考下列网址得到相关的信息http://oss.missioncriticallinux.com/kimberlite/。 一个完善的HA 解决方案必须具备下列特性： Reliability (可靠性) Availability (可用性) Scalability (扩充性)
High availability clusters 功能 HA Cluster 通常必须提供下列功能： 具备Hardware redundancy for fault tolerance 功能 「Redundancy」笔者看到有些文章译成「冗余、冗、过多、多余、赘..」真的是很怪，其实Redundancy 的意义就是「备援」。至于fault tolerance 是指「容错」，所谓「容错」代表当系统能够响应非预期性的故障时，可在容许状况及范围之下仍然可以继续运作，无须做任何的的切换或转移。在HA Cluser 中「Hardware redundancy for fault tolerance」相关解决方法可参考表１。 表1：HA Hardware redundancy for fault tolerance 解决方法 「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 又有那些?接下来笔者便为各位介绍这些相关技术。 图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 的总线确保每 一个成员都能免于由于其它成员的系统负载初始或修复所引起的干扰。 图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 电位移的问题。 点击查看大图 图4： SSA 示意图 SSA 是一个比SCSI 优良的技术，不过很可惜地，SSA 磁盘只能从 IBM 购买，取得成本太高，这些磁盘价格远高一般的 SCSI 磁盘价格。而且至今在Linux上仍没有够成熟的SSA Driver。 Fibre Channel Interconnect Fibre 是笔者最喜欢的解决方案，也是笔者认为是比较有扩展性且适合大型企业的架构。较简单经济的架构便如图5 所示，两个主机连接端口的一个单一控制卡RAID 数组，没有使用Fibre Hub 或Switch，主机连接端口配接卡直接联机至 RAID控制卡。当您使用这种类型的 single-initiator 光纤信道联机，您的RAID 控制器必须拥有分开的主机连接端口给每一部Cluster 成员。 图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 配置表 表2 是Linux-HA 被激活之前的情形。 两个服务接口都位于它们个别配置的启动地址上。备援接口位于它们的备援地址上。假设整个Clusters 对外服务的IPAddress ( 也就是Client 连至Clusters 的IP address )为”192.168.10.11”。当Linux-HA 被激活于两个节点时，由于Node 1 是主要节点，它将取得对外服务地址。 表3：Linux HA 激活后的IP 配置表 假设主要节点的服务( Service ) 网卡故障，则备援( Standby )配接卡将接管服务地址 ( 192.168.10.11 )，如表4。 表4：主要节点的服务网卡故障后的IP 配置表 假设主要节点Node 1 故障，Node 2 将取得包括于资源群组中的服务地址，如表5。 由以上这个简单的例子中，我们也可以移动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。
[1] [2] 下一页
（出处：http://www.sheup.com）
上一页 [1] [2]