SunPlex 系统使用户和数据间的"路径"上的所有组件都具有高度的可用性,这些组件包括网络接口、应用程序本身、文件系统和多主机磁盘。一般情况下,如果一个群集组件可免受系统中的任何单一(软件或硬件)故障的影响,则该组件就具有高可用性。
下表显示了 SunPlex 组件的故障种类(既包括硬件方面又包括软件方面)以及高可用性框架中所包含的恢复种类。
表 3-1 SunPlex 故障检测和恢复级别
有故障的群集组件 |
软件恢复 |
硬件恢复 |
---|---|---|
数据服务 |
HA API,HA 框架 |
无 |
公共网络适配器 |
网络适配器故障转移 (NAFO) |
多个公共网络适配卡 |
群集文件系统 |
主要和辅助复制 |
多主机磁盘 |
镜像多主机磁盘 |
卷管理器(Solstice DiskSuite 和 VERITAS Volume Manager) |
硬件 RAID-5(例如,Sun StorEdge A3x00) |
全局设备 |
主要和辅助复制 |
到设备、群集传输结点的多个路径 |
专用网 |
HA 传输软件 |
多个专用硬件独立网络节点 |
节点 |
CMM,故障快速防护驱动程序 |
多个节点 |
Sun Cluster 软件的高可用性框架可迅速检测到节点故障,并在群集中的其余节点上为该框架资源创建一个新的等效服务器。 不会出现所有框架资源都不可用的情况。 在恢复期间,未受崩溃节点影响的框架资源是完全可用的。 而且,故障节点的框架资源一恢复就立即可用。 已恢复的框架资源不必等待其他所有框架资源都完全恢复。
对于大多数具有高可用性的框架资源来说,其恢复过程都可让使用该资源的应用程序(数据服务)看到。 框架资源访问的语义在整个节点故障期间得到全面的保护。 应用程序根本不知道框架资源已转移到另一节点。 单个节点的故障对使用连接到此节点的文件、设备和磁盘卷的其他节点上的程序来说,是完全透明的。 多主机磁盘的使用就是一个例证,这些磁盘具有连接多个节点的端口。
群集成员监视器 (CMM) 是一组分布的代理程序,每个群集成员上都有一个代理程序。 这些代理程序在群集互连中交换信息,以便:
在所有节点上保持一致的成员视图(定额)
使用注册的回叫来驱动同步重新配置,以响应成员更改
处理群集划分(群集分割,失忆)
保证所有群集成员间的充分连通性
与 Sun Cluster 软件以前的发行版不同,CMM 是完全在内核中运行的。
CMM 的主要功能是针对在任一给定时间加入群集的节点集合建立一个群集范围内的协议。 这种约束称为群集成员。
为确定群集成员并最终保证数据的完整性,CMM:
说明群集成员的更改,如某个节点加入或脱离群集
保证"故障"节点脱离群集
保证"故障"节点在修复前不进入群集
防止群集将自身划分为一些节点子集
有关群集如何防止自身划分为多个独立群集的详细信息,请参阅"定额和定额设备"。
为确保数据免遭破坏,所有节点必须就群集成员达成一致协议。 如果需要,CMM 将根据故障来对群集服务(应用程序)重新进行配置。
CMM 会从群集传输层接收到关于与其他节点连通性的信息。 CMM 使用群集互连在重新配置期间交换状态信息。
检测到群集成员有更改后,CMM 会对群集执行一次同步配置,这时可能会按群集的新成员关系重新分配群集资源。
如果 CMM 检测到节点上存在严重的问题,它会要求群集框架来强制关闭该节点(应急状态)并将其从群集成员中删除。 实现这种功能的机制称为故障快速防护。 故障快速防护会使节点以两种方式关闭。
如果节点脱离群集后试图在没有定额的情况下启动新的群集,它会被"隔离",从而无法访问共享磁盘。 有关使用故障快速防护的详细信息,请参阅"故障防护"。
如果一个或多个特定于群集的守护程序出现故障(clexecd、rpc.pmfd、rgmd 或 rpc.ed),CMM 会检测到该故障,而节点将处于应急状态。
panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago. 409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0) %l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0 |
进入应急状态之后,该节点可能重新引导,试图重新连接群集;也可能停留在 OpenBoot PROM (OBP) 提示符状态下。 执行的具体操作将由 OBP 中的 auto-boot? 参数的设置来决定。
群集配置库 (CCR) 是专用的群集范围的数据库,用于保存与群集的配置和状态有关的信息。 CCR 是一个分布式数据库。 每个节点上都有该数据库的完整副本。 CCR 确保了所有节点对"整个" 群集有统一的认识。为避免毁坏数据,每个节点需要知道群集资源的当前状态。
CCR 使用两阶段提交算法进行更新:更新必须在所有群集成员上均成功完成,否则更新将被转返。CCR 使用群集互连来应用分布式更新。
尽管 CCR 是由文本文件组成的,但也绝不要手动编辑 CCR 文件。 每个文件都包含一个校验和记录来保证节点间的一致性。 手动更新 CCR 文件可能会导致某个节点或整个群集不能工作。
CCR 靠 CMM 来保证群集只有在定额建立后才能运行。 CCR 负责跨群集验证数据的一致性,需要时执行恢复,并为数据更新提供工具。