仲裁和仲裁设备

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

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

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

仲裁算法自动执行： 当群集事件触发其计算时，计算的结果可以随群集生存期的不同而改变。

仲裁选票计数

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

仲裁设备获取仲裁选票计数基于设备的节点连接数。 当设置仲裁设备时，它获得了一个最大选票计数 N-1，其中 N 是仲裁设备连接的投票数。 例如，连接到两个选票数非零的节点的仲裁设备有其中一个的仲裁数（二减一）。

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

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

仲裁配置

仲裁配置依赖于群集中节点的数目：

• 双节点群集 – 双节点群集需要两个仲裁选票才能形成。 这两个选票可以来自于两个群集节点，或者只来自一个节点和一个仲裁设备。 然而，在双节点群集中，必须配置一个仲裁设备，以确保在一个节点发生故障时另外那个节点可以继续工作。

• 多于两个节点的群集 – 您应在对磁盘存储器群组进行共享访问的每对节点中指定一个仲裁设备。 例如，假定您拥有一个类似于图形 3–2 中所示的三节点群集。 在此图中，nodeA 和 nodeB 共享对同一磁盘群组的访问权，而 nodeB 和 nodeC 共享对另一磁盘群组的访问权。 总共会有五个仲裁选票，其中三个来自节点，两个来自节点共享的仲裁设备。 一个群集需要多数仲裁选票才能形成。

  Sun Cluster 软件不要求也不强迫在对磁盘存储器群组进行共享访问的每对节点中指定一个仲裁设备。 然而，在 N+1 配置退化为双节点的群集、并且可访问两个磁盘群组的节点也发生故障时，此软件可以提供所需的仲裁选票。 如果您在每对节点之间配置了仲裁设备，则其余的节点仍可作为一个群集来运行。

  有关这些配置的示例，请参见图形 3–2。

图形 3–2 仲裁设备配置示例

仲裁原则

在设置仲裁设备时，请遵循下列原则：

• 在连接到同一个共享的磁盘存储器群组的所有节点间建立仲裁设备。 在共享群组内增加一个磁盘作为仲裁设备以确保在任何节点发生故障时，其它节点可以维持仲裁并可以控制共享群组上的磁盘设备组。

• 必须将仲裁设备连接到至少两个节点上。

• 仲裁设备可以是任何用作双端口仲裁设备的 SCSI-2 或 SCSI-3 磁盘。 连接到超过两个节点的磁盘必须支持 SCSI-3 持久性组保留 (PGR)，而不论磁盘是否用作仲裁设备。 有关详细信息，请参阅《Sun Cluster 软件安装指南》中有关规划的章节。

• 您可以使用包含用户数据的磁盘作为仲裁设备。

故障防护

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

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

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

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 磁盘，故障快速防护机制的工作方式都是一样的。

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

出现应急状态之后，节点可能重新引导并尝试重新加入群集；或者，如果群集是由基于 SPARC 的系统组成的，则停留在 OpenBoot^TM PROM (OBP) 提示符处。 所采取的操作取决于 auto-boot? 参数的设置。 您可以在基于 SPARC 的群集中的 OpenBoot PROM ok 提示符处使用eeprom(1M) 来设置 auto-boot?，也可以在基于 x86 的群集中，在 BIOS 引导之后选择运行 SCSI 实用程序来设置 auto-boot?。