避免某些事情——我們以前都做過。我們在與配偶散步時在商店裡看到的舊情人，在我們“不准備購買”時看到的銷售人員，甚至在我們“度假”時看到的老闆。當我是一個開發團隊的經理時，我瞥見了一個直接報告在他們應該不在辦公室的時候在商店裡瀏覽。他們躲在衣架之間，匆匆跑下下一個過道，匆匆離開。我們以前都這樣做過，在某些情況下，出於心理健康、身體健康或隱私和個人原因，我們都需要採取一些避免措施。即使在 HA。那麼，你如何在你的高可用性環境，為什麼？

在高可用性中使用迴避策略的四個理由

• 更好的性能（最小化服務器過載）

在 HA 中使用避免策略的原因之一是提高應用程序和服務器性能。考慮運行生產工作負載的三台服務器的情況，我們稱它們為 Server Alpha、Server Beta 和 Server Gamma。服務器 Alpha 和 Beta 運行由數據庫支持的關鍵應用程序，而服務器 Gamma 運行報告和數據轉換作業。如果 Server Alpha 出現故障，通常會發生故障轉移到 Server Beta。但是，由於服務器 Beta 已經在運行大量工作負載，因此產生的額外應用程序負載可能會導致服務器過載和兩個應用程序的性能不佳。因此，部署避免策略以確保選擇 Server Gamma 作為故障轉移目標可能是明智之舉。

• 性能優化

再次考慮三個服務器的場景，Alpha、Beta 和 Gamma。服務器 Alpha 和 Beta 可擴展以處理峰值工作負載，而服務器 Gamma 是成本優化的服務器。如果 Server Alpha 和 Server Beta 出現故障，則會發生故障轉移到成本優化的服務器 Gamma。但是，此服務器無法擴展以處理峰值工作負載，也無法同時處理 Server Alpha 和 Server Beta 的工作負載。在這種情況下，可以使用規避策略通過在另一台主機可用時自動從 Server Gamma 移動一個或兩個工作負載來優化性能。

• 高可用優化

HA 優化是另一種部署迴避策略的場景。 與性能優化策略一樣，HA 優化用於確保您的環境能夠承受大多數故障情況，並且您的應用程序經過優化以在任何時間點提供最高級別的可用性。HA 優化對於具有復制入隊進程的 SAP 等應用程序很重要。在任何 SAP 環境中，您都不希望 ASCS（ABAP SAP 中央服務）和 ERS（入隊複製服務）實例長時間駐留在同一服務器上，因為存在丟失鎖定和取消作業的風險。 為了防止這種情況發生，您可以使用避免策略，使 ERS 和 ASCS 實例始終在相對的集群節點上運行。考慮運行生產工作負載的三台服務器的情況，我們將它們稱為服務器 Alpha、Beta 和 Gamma。Server Alpha 正在運行 ASCS 實例，而 Server Beta 正在運行 ERS 實例。服務器 Gamma 用作服務器 Beta (ERS) 和服務器 Alpha (ASCS) 故障轉移的第三個節點。如果 Beta 崩潰，您不希望 ERS 資源與 ASCS 實例在同一節點上運行。為確保此操作，您可以部署避免策略，首先自動檢查並確保兩個應用程序位於不同的服務器上，並維護 SAP ASCS/ERS 鎖定故障轉移的最佳實踐。

• DR避免

假設您有兩個數據中心：City Alpha 和 City Beta，它們相距大約 70 英里，您的大多數客戶都位於它們之間的中心。 但是，由於最近內部組織的變化、合併/關閉和收購以及治理要求，您的 IT 團隊必須添加位於 City Gamma 的第三個數據中心，距離 Alpha 和 Beta 大約 350 英里。現在主要在 Alpha 和 Beta 中保護的資源也擴展到 Gamma 位置。鑑於大多數用戶和團隊都在 Alpha 和 Beta 位置附近，即使是最極端的用戶也位於鄰近城市，您的團隊需要避免故障轉移到 Gamma 位置。 與其他策略一樣，DR 避免尋求通過避免 DR 節點來優化性能、輸入/輸出區域數據成本、延遲和客戶端訪問，如果任一區域內只有一個節點發生故障。它還可以確保即使兩個節點在不同的時間後都發生故障，在轉移到 DR 之前，故障轉移總是發生在集群或數據中心中的另一個節點上。

那麼，您如何部署迴避策略呢？

許多提供程序具有可以配置的關聯規則，而其他提供程序使用服務器優先級或手動步驟的組合。對於適用於 Linux 的 SIOS 保護套件，您可以使用多種內置方法，包括：

• 資源優先級

如果發生故障，資源將故障轉移到它們具有最低剩餘優先級的服務器並級聯到任何其他服務器（Alpha、Beta 和 Gamma）。Server Alpha 是Resource.HR 的主服務器，Server Beta 是Resource.MFG 的主服務器，Server Gamma 是所有資源/服務器的備份服務器。使用資源優先級，Resource.HR 在服務器 Alpha 上的優先級為一 (1)，在服務器 Gamma 上的優先級為二 (2)。而 Resource.MFG 在服務器 Beta 上的優先級為一 (1)，在服務器 Gamma 上的優先級為二 (2)。如果客戶想要優化環境的使用，那麼 Resource.HR 在 Server Beta 上的優先級可以是三 (3)，Resource.MFG 在 Server Alpha 上的優先級可以是三 (3)。如果服務器 Alpha 發生故障，資源 Resource.HR 將首先失敗到服務器 Gamma，然後再嘗試在服務器 Alpha 上投入使用（恢復）。

適用於 Linux 的 SIOS 保護套件（UI 和 CLI）允許用戶為每個服務器和資源組合指定優先級。

• 策略或關聯規則

策略規則還可用於防止在給定服務器上發生資源恢復，從而允許資源避開可能正在運行更關鍵或資源密集型工作負載的指定服務器。典型的政策包括：

• • • • • • 默認情況下將阻止來自特定服務器的應用程序的約束策略。
          • 將阻止應用程序來自沒有足夠資源的服務器的資源策略
          • 定義允許或禁止資源進入系統的時間段的臨時策略
          • 定義首選服務器或集群內可能的應用程序所有權能力的自定義策略

SIOS Protection for Linux CLI 允許用戶指定策略規則，這些規則可以禁用故障轉移到指定服務器的特定資源、提供保護故障的臨時策略、禁用特定應用程序類型的故障、約束策略和自定義策略。

• 特定規避資源

建立資源避免策略的最細粒度的方法是在每個層次結構中部署特定的避免腳本。這種方法將允許用戶配置特定的應用程序（例如 app1 和 app2），盡可能避免彼此，同時允許其他應用程序不受限制地運行。在我們的三個服務器（Alpha、Beta 和 Gamma）以及三個資源 app1、app2 和 app3 的情況下，此方法將提供最大的靈活性。在這個例子中，app1 和 app2 將在服務器出現故障時尋求避免搭配，但 app3 將根據優先級失敗到下一個可用節點，沒有任何搭配限制。

有關避免策略和資源的其他示例，請考慮適用於 Linux 的 SIOS 保護套件文件.如果客戶有兩個應用程序 app1 和 app2，他們需要盡可能在不同的節點上運行，則客戶可以使用 SIOS Protection Suite for Linux gen/app 資源和 '/opt/LifeKeeper /lkadm/bin/avoid_restore' 腳本。

轉載自SIOS