test

Sun Cluster 3.0 12/01 概念

定额和定额设备

由于群集节点共享数据和资源，所以切勿将群集分割为同时处于活动状态的独立分区是十分重要的。 CMM 保证任何时候最多只有一个群集是有效的，即使已对群集互连进行了分区。

群集分区会引起两类问题：群集分割和失忆。如果节点间失去群集互连并且群集划分为若干子群集（每个子群集都认为自己是唯一分区），此时即会发生群集分割。 这是由群集节点之间的通信问题引起的。 失忆在群集关闭后又重新启动时发生，此时的群集数据比关闭时旧。 如果框架数据有多个版本存储在磁盘上，而新的群集体在尚未获得最新的版本时启动，则可能发生这种情况。

群集分割和失忆可以通过以下方法避免：赋予每个节点一个选票，并规定只有获得多数选票才能成为有效群集。 获得多数选票的分区拥有定额，因此允许其运行。 只要群集中有两个以上的节点，这种多数选票机制就能运行良好。 在双节点群集中，多数为二。 如果这样的群集分为两个分区，则需要使用外部选票才能使其中一个分区获得定额。 此外部选票由定额设备提供。 定额设备可以是这两个节点所共享的任一磁盘。 用作定额设备的磁盘可以包含用户数据。

表 3-3 说明 Sun Cluster 软件如何使用定额来避免群集分割和失忆。

表 3-3 群集定额及群集分割和失忆问题

分区类型 

定额解决方案 

群集分割 

仅允许获得多数选票的那个分区（子群集）作为群集（其中最多仅能有一个拥有多数选票的分区）运行 

失忆 

在群集引导时，保证至少有一个节点是最新的群集成员之一（因而有最新的配置数据） 

定额算法自动执行：由于群集事件会触发此计算，因此计算结果在群集的整个生存期间可能会有所变化。

定额选票计数

群集节点和定额设备都会投票以形成定额。 缺省情形下，群集节点在引导并成为群集成员时获取其中一个的定额选票计数。 节点的选票数可以是零，例如当正在安装节点时，或当管理员将节点置于维护状态时。

定额设备获取定额选票计数基于设备的节点连接数。 在设置定额设备时，它需获取一个最大选票数 N-1，其中 N 是有非零选票数的节点数，并且这些节点有到定额设备端口。例如，连接到两个选票数非零的节点的定额设备有其中一个的定额数（二减一）。

在群集安装期间（或以后通过使用《Sun Cluster 3.0 12/01 系统管理指南》中描述的过程）配置定额设备。

注意：

仅在当前连接的节点中至少有一个是群集成员时，定额设备才对选票数起作用。 同时，在群集引导期间，仅在当前连接的至少一个节点正在引导，并且在关闭时它是最近刚刚引导的群集成员的情况下，定额设备才对选票数起作用。

定额配置

定额配置依赖于群集中节点的数目：

图形 3-3 定额设备配置示例

Graphic

定额准则

在设置定额设备时，请使用下列准则：

提示：

要防止个别定额设备出现故障，请在节点集之间配置一个以上的定额设备。 使用来自不同群组的磁盘，并在每个节点集之间配置奇数的定额设备。

故障防护

群集的一个主要问题是引起群集分区的故障（称作群集分割）。 当此故障发生时，有些节点可能无法通信，所以个别节点或节点子集可能会尝试组成个体或群集子集。 每个子集或分区都可能以为它对多主机磁盘具有唯一访问权和所有权。 多个节点试图写入磁盘会导致数据损坏。

故障防护通过以物理方式防止对磁盘的访问，限制了节点对多主机磁盘的访问。 当节点脱离群集时（它或是发生故障，或是分区），故障防护确保了该节点不再能访问磁盘。 只有当前成员节点有权访问磁盘，以保持数据的完整性。

磁盘设备服务为使用多主机磁盘的服务提供了故障转移能力。 在当前担当磁盘设备组主节点（属主）的群集成员发生故障或变得无法访问时，一个新的主节点会被选中，使得对磁盘设备组的访问得以继续，而只有微小的中断。 在此过程中，旧的主节点必须放弃对设备的访问，然后新的主节点才能启动。 然而，如果某个成员从群集中脱离并变得无法访问，群集就无法通知该节点释放那些将该节点作为主节点的设备。 因而，需要一种方法来使免受影响的成员能够从发生故障的成员那里控制并访问全局设备。

SunPlex 系统使用 SCSI 磁盘保留来实现故障防护。 使用 SCSI 保留，故障节点就将与多主机磁盘"隔离"开来，使它们无法访问那些磁盘。

SCSI-2 磁盘保留支持一种保留形式，它或者给所有连接到磁盘的节点都授予访问权（当没有进行任何保留时），或者限制对单个节点（即拥有该保留的节点）的访问权。

当群集成员检测到另一个节点不再通过群集互连进行通信时，它启动故障防护措施来避免另一个节点访问共享磁盘。 当发生此故障防护时，通常将防护的节点处于应急状态，并在其控制台上显示"保留冲突"的消息。

发生保留冲突的原因是：在某个节点已被检测为不再是群集成员后，又将一个 SCSI 保留置于在此节点与其他节点所共享的所有磁盘上。 防护节点可能不会意识到它正处于防护状态；如果它试图访问这些共享磁盘之中的一个，它会检测到该保留并进入应急状态。

故障防护的故障快速防护机制

群集框架通过一种机制确保故障节点无法重新引导并开始写入共享存储器，这种机制被称为故障快速防护。

属于群集成员的节点对它们可以访问的磁盘（包括定额磁盘）持续启用一个特定 ioctl：MHIOCENFAILFAST。 该 ioctl 是对磁盘驱动程序的指令，它能使节点在以下情况下自身进入应急状态：某磁盘由于被其他节点保留而无法让该节点进行访问。

MHIOCENFAILFAST ioctl 指示驱动程序检查节点对磁盘发出的每个读写操作所返回的错误，查看是否返回 Reservation_Conflict 错误代码。 该 ioctl 定期在后台向磁盘发出一个测试操作，检查是否出现 Reservation_Conflict。 如果系统返回 Reservation_Conflict 消息，前台和后台控制流路径均进入应急状态。

对于 SCSI-2 磁盘，保留不是永久性的 - 它们在节点重新引导之后将不再存在。 对于具有持久性组保留 (PGR) 的 SCSI-3 磁盘，保留信息存储在磁盘上，并在多次重新引导节点后仍保持有效。 无论使用 SCSI-2 磁盘还是 SCSI-3 磁盘，故障快速防护机制的工作方式都是一样的。

如果某节点与群集中其他节点失去连接，并且它不属于可获取定额的分区的一部分，它将被另一节点强行从该群集中删除。 属于可获取定额的分区一部分的另一节点将保留放置在共享磁盘上，当不具备定额的节点试图访问共享磁盘时，它将接到保留冲突消息，并在故障快速防护机制的作用下进入应急状态。

进入应急状态之后，节点可能重新引导，试图重新连接群集；也可能停留在 OpenBoot PROM (OBP) 提示符状态下。 执行的具体操作将由 OBP 中的 auto-boot? 参数的设置来决定。