故障防护

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

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

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

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?。