高可用性是指一种设计方法，旨在使系统尽可能地保持可用。其目的是最大程度地减少诸如系统故障和维护等的停机因素，并最大限度地缩短检测发生的停机事件并从其中恢复所需的时间。事实上，自动检测停机事件并从其中恢复很快成为必要的手段，因为必须实现最高级别的可用性。
Sentinel 是一种复杂的多层应用程序，它依赖于各种服务并提供各种服务。此外，它与多个外部第三方系统集成，以进行数据收集、数据共享和事件更新。大多数高可用性解决方案都允许实现者声明应该高度可用的服务与依赖服务之间的相关性，但是，这只适用于在群集本身上运行的服务。Sentinel 外部的系统（例如事件源）必须单独进行配置，以便在组织需要时可供使用；另外，这些系统还必须配置为能够正确处理 Sentinel 有段时间不可用（例如发生故障转移事件）的情况。如果严格限制访问权限（例如，使用鉴定的会话在第三方系统与 Sentinel 之间发送/接收数据），则必须将第三方系统配置为接受来自任何群集节点的会话，或者发起到任何群集节点的会话（针对此目的，应该使用虚拟 IP 配置 Sentinel）。NetIQ 无法保证在我们的产品与不受我们控制的第三方系统之间实现任何特定级别的高可用性。
所有高可用性群集都需要某种形式的共享储存，以便在源节点发生故障时，能够在群集节点之间快速移动应用程序数据。储存本身应该高度可用；通常，可以借助于使用光纤通道网络连接到群集节点的储存区域网络 (SAN) 技术实现这种高可用性。其他系统使用网络挂接储存 (NAS)、iSCSI 或其他技术，这些技术可用于远程装入共享储存。共享储存的基本要求是，群集能够完全将储存从发生故障的群集节点移动到新的群集节点。
注：对于 iSCSI，您应使用您的硬件支持的最大讯息传送单位 (MTU)。较大的 MTU 有利于提高储存性能。如果储存的延迟和/或带宽慢于建议值，则 Sentinel 可能会遇到问题。
Sentinel 可对共享储存使用两种基本方法。第一种方法是将所有部件（应用程序二进制文件、配置和事件数据）定位在共享储存上。在发生故障转移时，储存将从主节点上卸载，并移到备份节点；这样就可以从共享储存装载整个应用程序和配置了。第二种方法是将事件数据储存在共享储存上，但应用程序二进制文件和配置驻留在每个群集节点上。在发生故障转移时，只会将事件数据移到备份节点。
每种方法都有各自的优缺点，但第二种方法允许 Sentinel 安装使用符合 FHS 的标准安装路径，可用于验证 RPM 打包，还可用于进行热增补和重新配置，以最大程度地减少停机时间。
此解决方案将向您介绍一个有关在群集上进行安装的过程示例，该群集使用 iSCSI 共享储存，并将应用程序二进制文件/配置定位在每个群集节点上。
任何高可用性环境的一个关键要素是，能够以可靠且一致的方式监视应该保持高度可用的资源，以及这些资源所依赖的任何资源。SLE HAE 使用名为资源代理的部件执行此监视操作，资源代理的任务是提供每个资源的状态，以及（根据要求）启动或停止该资源。
资源代理只有提供了受监视资源的可靠状态，才能防止出现不必要的停机。误报（认为某个资源已发生故障，但事实上它能够自行恢复）可能会导致其实不必要的服务迁移（及相关的停机），而漏报（资源代理报告某个资源在正常运行，但事实上该资源未正常运行）可能会阻止服务的正常使用。另一方面，对服务进行外部监视可能相当困难。例如，Web 服务端口可能会响应简单的 ping 命令，但是当发出实际查询时无法提供正确的数据。在许多情况下，必须在服务本身中内置自检功能，才能提供真正准确的度量。
此解决方案为 Sentinel 提供了基本的 OCF 资源代理，该代理可以监视重大的硬件、操作系统或 Sentinel 系统故障。目前，Sentinel 的外部监视功能基于 IP 端口探测，因此，在某种程度上存在误报和漏报读取内容的可能性。我们计划不断改进 Sentinel 和资源代理，以提高此部件的准确性。
在 HA 群集中，关键服务不断受到监视，并在发生故障时将在其他节点上自动重启动。但是，如果主节点出现通讯问题，则这种自动化操作可能会引入问题；尽管在该节点上运行的服务看似已停止，但实则还在运行并向共享储存写入数据。在此情况下，在备份节点上启动一组新的服务可能很容易导致数据损坏。
群集使用各种技术（统称为“隔离”）防止发生这种情况，这些技术包括节点分裂检测 (SBD) 和逐出其他节点 (STONITH)）。其主要目标是防止共享储存上发生数据损坏。