Solaris Cluster 设计用于在发生严重故障的情况下通过将操作控制权从一个服务器节点转移到下一个服务器节点来实现自动化系统恢复。但是，Solaris 系统中的大多数故障不需要完整的系统切换操作即可恢复。
与网络通信相关的故障由 Solaris IPMP 快速且无提示地处理。
系统磁盘故障由 Solaris ZFS 无提示地自动处理。
所连接的存储阵列中的任何单一磁盘驱动器的故障由存储阵列固件自动恢复。当存储阵列无法在发生磁盘故障后进行恢复时，Solaris ZFS 负责向镜像配置中的备用驱动器提供无中断的磁盘 I/O。
如果共享阵列的某个 HBA 端口发生故障，则 Solaris 将自动切换到备用端口。类似地，如果共享阵列上的某个控制器模块发生故障或者某个互连电缆断开了连接，则 Solaris 将立即恢复到连接到磁盘资源的备用路径。
磁带库通信路径中的故障将由 ACSLS 中的双 TCP/IP 逻辑自动恢复。发生故障的磁带库控制器卡的操作将由与磁带库冗余电子设备 (Redundant Electronics, RE) 关联的 ACSLS HA 逻辑自动恢复。
如果 ACSLS 中的多个正在运行的进程有任何一个失败，则 ACSLS 守护进程将立即重新引导失败的进程。
如果 ACSLS 守护进程本身失败，或任何剩余的 ACSLS 服务停止运行，Solaris 服务管理工具 (Service Management Facility, SMF) 将立即重新启动失败的服务。
所有这些情况都是在未涉及 Solaris Cluster 的情况下快速而自动处理的。但是，如果任何其他严重故障会影响活动服务器节点上的 ACSLS 操作，则 ACSLS HA 会指示 Solaris Cluster 将控制权切换到备用节点。
在启动后，ACSLS HA 将每分钟探测一次系统，检查是否发生下列任何事件：
与所连接的磁带库的通信中断。
失去与 ACSLS 逻辑主机的网络联系。
失去与用于客户机调用的 RPC 侦听器端口的联系。
失去对 ACSLS 文件系统的访问。
acsls SMF 服务处于不可恢复的维护状态。
任何这些事件都将触发群集故障转移。如果活动服务器节点上出现任何致命的系统状况，则 Solaris Cluster 也将进行故障转移。
激活群集故障转移控制：
# cd /opt/ACSLSHA/util # ./acsAgt configure
该实用程序会提示您输入逻辑主机名。确保在 /etc/hosts 文件中定义逻辑主机，并确保相应的 IP 地址映射到为 ACSLS HA 配置 Solaris 系统一章中定义的 ipmp 组。运行 acsAgt configure 之前，使用 zpool list 确认 acslspool 是否挂载到当前服务器节点。
此操作将启动 ACSLS 群集控制。Solaris Cluster 将监视系统，每分钟探测一次以专门检验 ACSLS 的运行状况，通常会检验 Solaris 系统。任何被断定为致命错误的状况都将在备用节点上启动操作。
检查 ACSLS 资源组的群集状态：
# clrg status
显示内容如下：
揭示每个节点的状态。
指明哪个节点是活动节点。
揭示故障转移操作是否处于暂停状态。
明智的做法是，在 acsls-storage 资源中设置一个策略，以在活动节点与共享 RAID 磁盘设备之间的通信丢失时重新引导该节点。此操作会导致活动节点在无法连接到磁盘时放弃控制权，从而允许 Solaris Cluster 将控制权转移到备用节点。通过将 Failover_mode 从 SOFT 设置为 HARD，能够确保在活动节点与共享存储设备之间的通信丢失后重新引导该节点。
要查看现有 Failover_mode，请运行以下命令：
# clrs show -v acsls-storage | grep Failover
Failover_mode 应按如下方式设置为 HARD：
# clrs set -p Failover_mode=HARD acsls-storage
在激活群集控制后，可以正常运行 ACSLS。可以使用标准 acsss 控制实用程序启动和停止 ACSLS。在群集控制下，用户以在独立 ACSLS 服务器上启动和停止应用程序的相同方式启动和停止 ACSLS 服务。操作是使用以下标准 acsss 命令进行管理的：
acsss enable acsss disable acsss db
使用这些命令手动启动或停止 acsss 服务决不会导致 Solaris Cluster 通过故障转移操作进行干预。使用 Solaris SMF 命令（例如 svcadm）也不会导致 Cluster 进行干预。每当 acsss 服务中止或中断时，主要由 SMF 而非 Cluster 负责重新启动这些服务。
Solaris Cluster 只在下列情况下才进行干预以在相邻节点上恢复控制权：
与 ACSLS 文件系统的通信中断。
与所有冗余公共以太网端口的通信中断。
与指定磁带库的通信中断并且无法恢复。
如果怀疑维护活动可能会触发不必要的群集故障转移事件，则可以暂停 acsls 资源组的群集控制。
暂停群集控制：
# clrg suspend acsls-rg
当资源组处于暂停状态时，Solaris Cluster 不会尝试将控制权切换到相邻的节点，无论条件是否会触发此类转移操作。
此暂停操作使得您即使在磁带库生产处于全面开工状态下也可以对系统进行更具侵入性的修复。
如果活动节点碰巧在暂停模式下重新引导，则它在重新引导后不会挂载 acslspool，并且 ACSLS 操作也会停止。要清除此状况，应当恢复群集控制。
恢复群集控制：
# clrg resume acsls-rg
如果共享磁盘资源已挂载到当前节点上，则会恢复正常运行。但是，如果 Solaris Cluster 在激活时发现 zpool 未挂载，则它会立即将控制权切换到相邻的节点。如果相邻节点无法访问，则控制权会重新切换回当前节点。Cluster 尝试挂载 acslspool 并在此节点上启动 ACSLS 服务。
以下过程提供了必须要关闭 ACSLS HA 系统的电源时用于安全关闭电源的操作序列。
确定群集中的活动节点。
# clrg status
查找联机节点。
以 root 用户身份登录到活动节点并停止 ACSLS 资源组的 Solaris Cluster 控制。
# clrg suspend acsls-rg
切换到用户 acsss 并关闭 acsss 服务：
# su - acsss $ acsss shutdown
以 acsss 用户身份注销并正常关闭节点的电源。
$ exit # init 5
登录到备用节点并通过 init 5 关闭其电源。
使用物理电源开关关闭共享磁盘阵列的电源。
在执行受控关闭之前处于活动状态的节点上恢复 ACSLS 操作：
在本地使用物理电源开关或者远程使用 Oracle Integrated Lights Out Manager 打开两个节点的电源。
打开共享磁盘阵列的电源
以 root 用户身份登录到任一节点。
如果您尝试以 acsss 用户身份登录或者列出 $ACS_HOME 目录，您会发现在任一节点上都未挂载共享磁盘资源。要恢复群集监视，请运行以下命令：
# clrg resume acsls-rg
通过此操作，Solaris Cluster 将共享磁盘挂载到系统关闭时处于活动状态的节点。此操作还应自动重新引导 acsss 服务并且应恢复正常运行。
某些情况下，当一节点处于维护状态时，ACSLS 必须能够从另一个节点上的独立服务器环境继续运行。硬件维护、操作系统升级或者 Solaris Cluster 升级都属于这种情况。
使用以下过程创建独立的 ACSLS 服务器。
在非群集模式下重新引导所需的节点。
# reboot -- -x
在 SPARC 服务器上从 Open Boot Prom (OBP) 引导进入非群集模式：
ok: boot -x
在 X86 服务器上，需要编辑 GRUB 引导菜单。
打开系统电源。
出现 GRUB 引导菜单时，按 e（edit，编辑）。
从子菜单中，使用方向键选择 kernel /platform/i86pc/multiboot。选中此项后，按 e。
在编辑模式下，将 -x 添加到多引导选项 kernel /platform/i86pc/multiboot -x 并单击 return。
在选中多引导 -x 选项的情况下，按 b 以使用该选项进行引导。
在引导周期完成后，以 root 用户身份登录并导入 ACSLS Z-pool。
# zpool import acslspool
当磁盘资源保持绑定到另一节点时，如果需要，可使用 -f（force，强制）选项。
# zpool import -f acslspool
启动 acsss 服务。
# su - acsss $ acsss enable