SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Date: 11 5 月, 2024

What Causes Failovers to Happen

是什麼導致故障轉移？

在支援工作中，我們從客戶那裡得到的最常見問題之一是「是什麼促使我們故障轉移從我的主節點到輔助節點？

發生這種情況的原因有很多……我們將嘗試解釋最常見的原因以及如何識別這些原因。

在我們開始之前，讓我們區分“故障轉移”和“切換”，因為許多客戶可以互換使用這些術語。

「切換」是手動將層次結構從主節點移動到輔助節點的行為。這可以透過 GUI、在輔助節點上執行「In Service」或透過命令列來完成：

Perform_action -a Restore -t $LKTag（使層次結構投入使用）

另一方面，「故障轉移」是在沒有任何手動互動的情況下執行的…並且被定義為在先前活動的伺服器、應用程式或硬體/網路發生故障時自動切換到備份伺服器。

故障轉移和切換本質上是相同的操作，不同之處在於故障轉移是自動的並且通常在沒有警告的情況下運行，而切換是有意的並且需要人為幹預。

以下是啟動「故障轉移」最常見的「故障」：

  1. 伺服器層面原因

伺服器故障

  • 主伺服器斷電或關閉。
  • 負載過大導致的 CPU 使用率 — 在 I/O 負載非常重的情況下，延遲和記憶體不足的情況可能會導致系統變得無回應，從而生命守護者可能會偵測到伺服器已關閉並啟動故障轉移。
  • 仲裁/見證 – 作為仲裁/見證 I/O 防護機制的一部分，當主伺服器失去仲裁時，“快速啟動”：，“快殺“ 或者 ”奧蘇” 被執行（基於設定）並啟動故障轉移。在決定何時進行故障轉移時，見證伺服器僅在驗證主伺服器已發生故障且不再屬於叢集的情況下才允許在備份伺服器上投入使用資源。這將防止由於節點之間的簡單通訊故障而發生故障轉移，而這些故障不會影響對服務中節點的整體存取和效能。

通訊（心跳）失敗

LifeKeeper 有一個內建的「心跳」訊號，可以定期通知配置中的每個伺服器其配對伺服器正在運行。預設情況下，LifeKeeper 每五秒在伺服器之間發送一次心跳（這對於繁忙的叢集是可調整的）。如果通訊問題導致心跳跳過兩次心跳，但在第三次心跳時恢復，LifeKeeper 不會採取任何操作。然而，如果通訊路徑在三個節拍內保持無效狀態，LifeKeeper 會將該通訊路徑標記為無效。如果冗餘通訊路徑也失效（我們建議兩條路徑），它將啟動故障轉移。

以下情況可能會導致心跳喪失：

  • 與主伺服器的網路連線遺失。
  • 網路延遲。
  • TCP 通訊路徑上的網路流量過大可能會導致意外行為，包括錯誤故障轉移和 LifeKeeper 初始化問題。
  • 網卡故障。
  • 網路切換失敗。
  • 手動拉/刪除網路連接
  • 主伺服器斷電或關閉。
  • 負載過大導致的 CPU 使用率 — 在非常重的 I/O 負載下，延遲和記憶體不足的情況可能會導致系統無回應，從而 LifeKeeper 可能會偵測到伺服器已關閉並啟動故障轉移。

調整心跳參數：

LCMNUMHBEATS=Y（其中 Y 是日誌中記錄通訊路徑失敗錯誤之前的心跳數）。預設值為 3，如果您的系統繁忙或跨 WAN，則可以更改，以避免錯誤的通訊路徑故障。

LCMHBEATTIME=5（這是以秒為單位的間隔，這是預設值，不應更改）。

預設情況下，這些可調參數不在 /etc/default/LifeKeeper 檔案中。您將需要添加它們來更改心跳值。

在 /etc/default/LifeKeeper 中新增這些可調參數和值後，您需要停止 LifeKeeper 並重新啟動它。您可以使用命令 lkstop -f，該命令會停止 LifeKeeper，但不會關閉受保護的應用程式。

您需要在兩個系統上執行此操作。

這將允許 LifeKeeper 在將通訊路徑標記為失敗之前等待 5 倍 Y 秒。

什麼是裂腦，是什麼原因造成的？

如果使用單一通訊路徑且該通訊路徑發生故障，則 LifeKeeper 層次結構可能會嘗試同時在多個系統上投入使用。這稱為錯誤故障轉移或「裂腦」場景。在裡面「裂腦」情景，每個伺服器都認為它控制應用程序，因此可能會嘗試存取共享儲存設備並向其寫入資料。為了解決裂腦情況，LifeKeeper 可能會導致伺服器關閉或重新啟動，或使層次結構停止服務，以確保所有共享資料的資料完整性。此外，TCP 通訊路徑上的大量網路流量可能會導致意外行為，包括錯誤故障轉移和 LifeKeeper 無法正確初始化。

以下是可能導致腦裂的情況：

  • 上面列出的任何通信故障
  • LifeKeeper 不正確關閉
  • 伺服器資源匱乏
  • 遺失所有網路路徑
  • DNS 或其他網路故障
  • 系統當機

使用仲裁/見證來防止裂腦

  • LifeKeeper 的Quorum/Witness 伺服器支援套件（steeleye-lkQWK，以下簡稱「Quorum/Witness 套件」）與LifeKeeper 核心現有的故障轉移流程相結合，使得在可能出現整體網路故障的情況下，系統能夠更加可靠地進行故障轉移。這實際上意味著可以完成本地站點故障轉移和跨 WAN 的節點故障轉移，同時大幅降低風險裂腦情況。
  • 在考慮網路分區的分散式系統中，有一個稱為仲裁的概念來獲得跨集群的共識。具有仲裁的節點是指能夠獲得所有叢集的共識並允許資源投入使用的節點。另一方面，沒有仲裁的節點是無法取得所有叢集共識的節點，不允許將資源投入使用。這將防止腦裂的發生。檢查節點是否具有仲裁稱為仲裁檢查。如果有仲裁，則表示「仲裁檢查成功」；如果沒有仲裁，則表示「仲裁檢查失敗」。
  • 如果發生通訊故障，使用發生故障的一個節點和另外多個節點（或其他設備）將允許節點獲得有關故障節點狀態的「第二意見」。獲得「第二意見」的節點稱為見證節點（或見證設備），獲得「第二意見」稱為見證檢查。在確定何時進行故障轉移時，見證節點（見證設備）僅在驗證主伺服器發生故障且不再屬於叢集的情況下才允許在備份伺服器上投入使用資源。這將防止由於節點之間的簡單通訊故障而發生故障轉移，而這些故障不會影響對服務中節點的整體存取和效能。在實際操作過程中，當LifeKeeper啟動或恢復故障的通訊路徑時，將會諮詢見證節點（見證設備）。見證檢查只能對具有法定人數的節點執行。

  1. 資源失敗原因

LifeKeeper 旨在監控單一應用程式和相關應用程式群組，在受保護的應用程式發生故障時定期執行本機復原或通知。例如，相關應用程式是主要應用程式依賴較低層級儲存或網路資源的層次結構。 LifeKeeper 監控這些受保護資源的狀態和運作狀況。如果確定資源處於故障狀態，則會嘗試在沒有外部幹預的情況下恢復目前系統（服務中節點）上的資源或應用程式。如果本地復原失敗，將啟動資源故障轉移。

應用程式失敗

  • 偵測到應用程式故障，但本地復原過程失敗。
  • 刪除故障 – 在資源故障轉移過程中，某些資源需要從主伺服器上的服務中刪除，然後在選定的備份伺服器上投入使用，以提供關鍵應用程式的完整功能。如果此刪除過程失敗，將重新啟動主伺服器，從而導致完整的伺服器故障轉移。

刪除失敗的範例：

  • 無法卸載檔案系統
  • 無法關閉受保護的應用程式（oracle、mysql、postgres 等）

檔案系統問題

  • 磁碟已滿 — LifeKeeper 的檔案系統運作狀況監控可以偵測磁碟已滿的檔案系統狀況，這可能會導致檔案系統資源發生故障轉移。
  • 卸載或不正確安裝的檔案系統 — 使用者手動卸載或變更正在使用的且受 LK 保護的檔案系統上的選項。
  • 重新安裝失敗 — 以下是重新安裝失敗的常見原因（可能導致故障轉移）：
  • 檔案系統損壞（fsck 失敗）
  • 建立掛載點目錄失敗
  • 掛載點正忙
  • 安裝失敗
  • LifeKeeper 內部錯誤

IP位址故障

當 IP 復原套件偵測到 IP 位址故障時，由此產生的故障會觸發 IP 本機復原腳本的執行。 LifeKeeper 首先嘗試在目前網路介面上恢復 IP 位址的服務。如果本機復原嘗試失敗，LifeKeeper 會將 IP 位址和所有相關資源故障轉移到備份伺服器。在故障轉移期間，刪除程序將取消目前伺服器上的 IP 位址配置，以便可以在備份伺服器上進行配置。此刪除過程失敗將導致系統重新啟動。

  • IP衝突
  • IP衝突
  • DNS解析失敗
  • NIC 或交換器故障

預訂衝突

  • 受保護設備的預訂遺失或被盜
  • 無法重新獲得受保護資源設備的預留或控制（由手動使用者介入、HBA 或交換器故障引起）

SCSI設備

  • 無法開啟受保護的SCSI 設備。該設備可能故障或可能已從系統中刪除。

用於確定故障轉移原因的資源

/var/log/lifekeeper.log

這個由 LifeKeeper 編寫的日誌檔案應該是您在確定可能導致故障轉移的原因時首先查看的地方。

例如，最常見的原因之一是通訊路徑故障。以下是發生這種情況時您將在 lifekeeper.log 中找到的條目範例：

9 月 21 日 11:06:57 es1ecc08tev lcm[46893]：訊息：lcm.tli_hand:::005257：在開發 10.236.17.226/10.238.17.226 上錯過了 48 個驅動程式編號 = 198 個驅動程式 = 21m）。

9 月 21 日 11:06:57 es1ecc08tev lcm[46893]：訊息：lcm.tli_hand:::005257：在開發 10.236.17.226/10.237.17.226 上錯過了 48 個驅動程式編號 = 199 個驅動程式 = 1999）。

9 月 21 日 11:07:02 es1ecc08tev lcm[46893]：訊息：lcm.tli_hand:::005257：在開發 10.236.17.226/10.238.17.226 上錯過了 48 個驅動程式編號 = 298 個驅動程式 = 298m）。

達到最大心跳數後，故障轉移開始：

9 月 21 日 11:10:49 es6ecc08tev lcm[9416]: INFO:lcm.tli_hand:::005257:missed heartbeat 47 of 48 on dev 10.237.17.226/10.236.0.236) 驅動程式編號。

9 月 21 日 11:10:49 es6ecc08tev eventslcm[47082]：警告：lcd.net:::004258：10.237.17.226/10.236.17.226 與 es1ecc08tev 的通訊失敗

9 月 21 日 11:10:49 es6ecc08tev eventslcm[47082]：警告：lcd.net:::004261：將啟動系統「es1ecc08tev」的通訊故障轉移。

9 月 21 日 11:10:49 es6ecc08tev lifekeeper[47121]：通知：event.comm_down:::010466：通訊 es1ecc08tev 失敗

/var/日誌/訊息

這個 Linux 產生的檔案通常包含由系統上執行的各種進程和服務所產生的系統訊息。這些訊息可以包括：

系統啟動訊息：有關係統啟動過程的信息，包括核心訊息和來自 systemd 或其他 init 系統的訊息。

服務啟動和關閉訊息：指示服務何時啟動或停止的訊息，包括在此過程中遇到的任何錯誤或警告。

核心訊息：有關 Linux 核心操作的信息，包括硬體檢測、裝置初始化以及核心錯誤或警告。

網路相關訊息：有關網路連線、防火牆活動和網路設定變更的資訊。

系統效能資訊：與系統效能監控相關的訊息，例如CPU使用率、記憶體使用率、磁碟I/O統計資料。

SIOS 高可用性和災難復原

SIOS科技公司提供高可用性和災難復原透過針對最重要應用程式的叢集管理來保護和最佳化 IT 基礎架構的產品。今天聯繫我們了解更多。

經許可轉載安全作業系統