高可用性代表一種設計方式，目的是維持系統實際可行的最高可用性，希望可減少造成停機時間的原因 (例如系統故障及維護)，並縮短偵測到確實發生的停機時間事件並從中復原的時間。實務上，自動化代表為提高可用性，偵測到停機時間事件並快速從中復原是必要的。
Sentinel 是複雜的多層應用程式，仰賴各種服務也提供多樣的服務，並整合多個外部協力廠商系統來進行資料收集、資料共享和事件矯正。大部分高可用性解決方案允許實作者宣告必須為高可用性的服務和相依服務之間的相依性，但這只適用於在叢集本身執行的服務。Sentinel 的外部系統 (例如事件來源) 必須分開設定，以依組織規定提供使用，而且也必須設定為可正確處理一段時間無法使用 Sentinel 的情況，例如容錯移轉事件。若存取權限嚴格受到限制 (例如使用驗證工作階段來傳送/接收協力廠商系統和 Sentinel 之間的資料)，協力廠商系統就必須設定為接受來自任何叢集節點的工作階段或啟始其工作階段 (根據此目的，Sentinel 應使用虛擬 IP 設定)。NetIQ 無法保證在我們的產品和我們無法控制的協力廠商系統之間任何特定層級的高可用性。
所有高可用性叢集需要某種形式的共享儲存，方便應用程式資料在原始節點發生故障時，快速移至其他叢集節點。儲存本身必須為高可用性；這通常是透過使用連接至使用光纖通道網路之叢集節點的儲存區域網路 (SAN) 技術達成。其他系統使用網路附加儲存 (NAS)、iSCSI 或允許遠端掛接共享儲存的其他技術。共享儲存的基本要求為叢集可以完整將儲存從失敗的叢集節點移至新的叢集節點。
附註：若是 iSCSI，您應使用硬體支援的最大訊息傳輸單元 (MTU)。最大訊息傳輸單元有助提升儲存效能。若儲存的延遲和/或頻寬低於建議，Sentinel 可能發生問題。
Sentinel 有兩個基本方法可以用於共享儲存。第一個方法是找出在分享儲存上的所有元件：應用程式二進位檔、組態和事件資料。進行容錯移轉時，儲存會從主要節點卸載並移至備份節點；備份節點會從共享儲存載入整個應用程式和組態。第二個方法會將事件資料儲存在共享儲存上，但是應用程式二進位檔和組態會放置在每個叢集節點上。進行容錯移轉時，只有事件資料會移到備份節點。
每個方法各有其優缺點，但是第二個方法允許 Sentinel 安裝使用符合 FHS 規定的標準安裝路徑、允許驗證 RPM 封裝，也允許軟修補和重新組態以縮短停機時間。
此解決方案將向您介紹一個範例，引導您瞭解安裝到使用 iSCSI 共享儲存之叢集的程序，並找到每個叢集節點上的應用程式二進位檔和組態。
任何高可用性環境的一個重要元素是以一致的可靠方式來監控必須為高可用性的資源以及其所依賴的任何資源。SLE HAE 使用名為資源代理程式的元件來執行此監控，資源代理程式的工作是提供每個資源的狀態，再加上 (必要時) 啟動或停止該資源。
資源代理程式必須為監控的資源提供可靠的狀態，才能避免不必要的停機時間。誤報 (資源被視為故障，但事實上可自行復原) 可能在非實際必要時導致服務移轉 (和相關的停機時間)，誤判異常 (資源代理程式回報某資源運作正常，但事實上並無法運作) 可能造成無法正常使用服務。從另一方面來說，外部監控服務並不容易，例如 Web 服務連接埠可能會回應簡單的 Ping，但可能無法在發出真正的查詢時提供正確的資料。在許多情況下，自我測試功能必須內建到服務本身，以提供確實正確的評量。
此解決方案為 Sentinel 提供基本的 OCF 資源代理程式，可監控重要硬體、作業系統或 Sentinel 系統故障。此時，Sentinel 的外部監控能力是根據 IP 連接埠探測，有可能會出現誤報和誤判異常。我們計劃持續改善 Sentinel 和資源代理程式，以提高此元件的準確性。
在高可用性叢集中，重要服務會隨時受到監控，並在失敗時自動在其他節點上重新啟動。不過，若主要節點發生通訊問題，此自動化可能產生問題；在該節點上執行的服務可能看起來已失敗，但實際上仍繼續執行，並寫入資料到共享儲存。若在此時於備份節點上啟動新的服務組合，很容易就會造成資料損毀。
叢集使用合稱為圍籬區隔的各種技術來防止發生此情況，包括電腦分裂偵測器 (SBD) 和 Shoot The Other Node In The Head (STONITH)。主要是為了防止共享儲存上的資料損毀。