優化 IT 系統以實現高可用性的策略

優化 IT 系統以實現高可用性的策略

維持 IT 系統的高可用性 (HA) 對於組織的成功至關重要。從關鍵資料庫管理到確保無縫的客戶體驗，實現不間斷營運提出了需要策略規劃的獨特挑戰。以下是組織可以利用的一些關鍵策略來優化其 IT 系統以實現高可用性。

優化 IT 系統以實現高可用性的常見挑戰

有幾個不同的領域開始為 IT 系統帶來挑戰。經常出現的問題是與防毒 (AV) 解決方案的兼容性。通常，問題源於防毒軟體對系統的過度保護以及對應用程式或 HA 解決方案運行至關重要的文件的隔離。當然，驗證解決方案之間的相容性始終很重要，但要更進一步 – 對於管理系統的每個人來說，熟悉 AV 解決方案的工作原理並了解配置/請求更改 AV 的過程總是有好處的解決方案，使關鍵應用程式不會中斷。

除了 AV 解決方案之外，還會出現防火牆配置 – 通常使用 HA 解決方案時，會透過網路傳輸額外的通訊以編排叢集行為。因此，通常需要新增特定規則來適應 HA 解決方案，以防止 HA 解決方案執行錯誤的叢集復原作業。

最後，在配置高可用系統時，存取控制的原理變得稍微複雜一些。雖然各個團隊（IE、資料庫團隊、SAP 團隊、雲端團隊- 無論事物如何分佈）都需要各自網域的權限，但管理HA 解決方案的任何管理員可能會發現他們擁有可透過HA 解決方案存取的其他權限（IE 、啟動應用程式的故障轉移、在節點之間建立通訊、鎖定/解鎖儲存等）。因此，在委派存取權限時，考慮可透過 HA 解決方案執行的操作非常重要。僅允許根級別使用者進行 HA 控制可能是相關的，或者您可以定義透過 HA 解決方案採取操作的程序，以便通知團隊並追蹤操作。無論如何，從最小特權原則來看，HA 解決方案呈現出複雜性，應考慮這種複雜性，以確保應用程式和系統只能由受委託方存取和可變。

故障轉移和災難復原策略在確保系統正常運作時間中的作用

故障轉移功能和災難復原 (DR) 策略都會對關鍵系統的正常運作時間產生重大影響。顯然，HA 可以提供故障轉移功能，以確保單一伺服器問題不會導致應用程式套件中斷，並且如果配置正確，故障轉移幾乎可以是無縫的。這允許在故障系統上進行恢復，同時備用系統發揮主要作用來承擔負載。當然，災難復原可以與HA策略緊密結合。如果已經配置了冗餘 – 為什麼不確保跨故障域存在這種冗餘。如果觀察得當，應用程式可以具有高可用性和容錯性。從 IT 角度分析這些結果時，正確配置的 HA 和 DR 策略可以確保系統充分發揮其潛力，同時最大限度地減少停機時間。託管應用程式的區域中的自然災害或技術故障傳播到其他區域的可能性要小得多。將計劃的冗餘與災難復原計劃結合起來可以用更少的資源滿足更多的功能需求——因為仔細的規劃可以確保透過部署備用站點來處理冗餘和容錯。

平衡成本效益和高可用性：組織策略

配置叢集環境或高可用性系統的成本可能會很高。通常，至少有一個備用系統與主系統一起運行，儘管不處理工作負載，但仍會產生成本，但成本是可以降低的。我建議採取以下幾種方法：考慮使用託管共享儲存解決方案。如果不需要冗餘資料副本，可以使用共用儲存空間來節省儲存空間。像 Amazon EFS 這樣的東西可能意味著您只需為複製磁碟配置的一半儲存空間付費。

考慮 DR 系統的用例。通常，這些系統只是恢復主站點時的權宜之計。資源不會在災難復原站點上長時間運行，因此，根據工作負載，您可以在災難復原站點上配置較小的系統以節省運算成本。當然，您需要與利害關係人溝通設計決策，以便每個人都知道災難復原網站不是長期託管解決方案 – 但只要您的工作負載和勞動力能夠處理額外的限制，就可以節省執行個體大小。同樣，不託管工作負載而僅在叢集內進行協調的編排器和/或仲裁系統可能會比委派的系統工作負載小得多。

考慮使用縱向擴展或橫向擴展的解決方案。擴展意味著增加單一機器的運算能力－在雲端環境中，這涉及到當工作負載壓垮較小實例時，較小實例將其資源池增加到較大實例的資源池。橫向擴展意味著在需要計算能力時增加將分擔應用程式負載的工作人員數量。顯然，用例決定了何時何地擴展或擴展是更好的解決方案 – 但透過熟悉手頭的軟體和環境，您將能夠做出決策並配置系統，以便在時機成熟時採取適當的行動。使用縮放解決方案需要考慮的另一件事是考慮除垢規則的激進程度。為了節省成本，請確保實例將縮減至適當的資源池，並評估指示縮減行為的規則，以確保不會將過多的資源配置時間超過所需時間。之間建立強而有力的溝通和 HA 供應商。確保有溝通的基礎可以促進任何技術的合作部署或環境升級。此外，透過保持溝通活躍，所有團隊都將更了解系統上發生的活動。讓所有團隊保持最新狀態至關重要，並且可以更輕鬆地診斷問題或在必要時開始回溯程序。最後，保持強大的溝通還可以確保團隊之間可以有效地共享最佳實踐，以便團隊可以合作工作，而不是按照不同的原則運作。

實施高可用性：最佳實踐

我向任何部署系統的人推薦的第一個也是最大的實踐是維護測試環境。保持測試環境盡可能與生產環境相同，並對生產環境中將發生的任何流程進行試運行，以便團隊在生產部署時熟悉流程和操作手冊。這種實踐也融入了我為系統提供的其他最佳實踐。透過維護測試環境，您還可以維護一個可用於預先測試任何變更的系統。測試環境是驗證產品相容性並確保技術之間相互操作的任何考慮因素得到充分確立的完美場所。我一次又一次看到的一個很棒的例子是為防毒軟體配置排除項- 在某些情況下，這些排除項未配置並且生產環境會遭受中斷，因為防毒軟體可能會隔離經常訪問的文件。最後，確保定期審核您的配置。檢查各個方面，例如安全群組、存取控制、防火牆規則和軟體相容性（尤其是 HA、受保護的應用程式和防毒之間）。保留對這些審計結果和所做的任何更改的詳細日誌 – 追蹤這些詳細資訊可以提供可靠的記錄，如果可能存在導致問題的配置更改，則可以對其進行審查。此外，當請求供應商支援時，這些審核可以成為一個很棒的共享工具，以便更快地進行完整的根本原因分析。最重要的是，這些審計將提供如何配置的記錄 – 如果指定的配置發生任何變化，人們可以參考過去的審計結果，以根據組織的標準重新調整系統系統配置。

SIOS 知道優化 IT 系統以實現高可用性對於組織的成功至關重要。透過解決防毒解決方案的相容性挑戰和微調防火牆配置，組織可以增強系統彈性和正常運作時間。今天與我們聯繫以獲取更多信息。

經許可轉載安全作業系統

SIOS 技術有助於在高可用性和雲端成本之間取得平衡

SIOS 技術有助於在高可用性和雲端成本之間取得平衡

在兩者之間找到適當的平衡高可用性成本優化可能具有挑戰性。 SIOS Technology 的高級技術佈道師 Dave Bermingham 談論了影響雲端成本的一些關鍵因素以及一些優化成本的策略。他說：「我們專注於實用且有效的策略，這些策略不僅有助於降低與部署高可用性相關的成本，而且除了最大限度地減少與計劃維護相關的停機時間之外，還有助於最大限度地減少意外停機時間。

影響雲端環境成本的關鍵因素

• 影響高可用性配置中的雲端成本和最佳化成本的關鍵因素包括高效的資源管理、策略架構決策和持續監控。
• Bermingham 討論了選擇正確的實例、類型和大小來滿足工作負載要求的重要性，以及自動擴展如何幫助降低成本和優化雲端支出。
• 伯明罕強調，如果跨多個時區部署高可用性解決方案，請考慮資料傳輸成本的重要性，並且您可以使用策略來最大限度地減少費用。
• 其他關鍵考慮因素包括優化儲存以及實施有效的治理和成本管理政策。

在雲端尋找高可用性和成本優化之間的平衡

• Bermingham 解釋說，雖然高可用性會產生一些費用，但這抵消了與任何停機相關的成本，而停機時間可能是巨大的。
• 透過創建模組化和可擴展的系統以及採用 DevOps 文化和利用 CI/CD 實踐的營運策略，在高可用性和最小化雲端成本之間取得平衡非常重要。

雲端成本優化和高可用性挑戰

• Bermingham 強調了在不影響高可用性的情況下優化成本的常見陷阱，例如低估雲端成本管理的複雜性和忽視應用程式效能監控的重要性。
• 關於雲端成本優化最佳實踐和實施 HA 解決方案的培訓不足通常會導致資源利用效率低下和計劃外停機。

SIOS Technology 的高可用性解決方案如何提供協助

• Bermingham 解釋了 SIOS 技術如何透過 HA 解決方案協助應對這些挑戰，這些解決方案可簡化和自動化不同雲端環境中的 HA，從而最大限度地降低成本、最大限度地減少停機時間並管理維護。

經許可轉載安全作業系統

SIOS LifeKeeper for Linux v 9.8.1 改進了公司管理 HA/DR 的方式

SIOS LifeKeeper for Linux v 9.8.1 改進了公司管理 HA/DR 的方式

在當今技術驅動的環境中，公司正在尋求創新的解決方案來有效維護其複雜的應用程式環境。在這個影片中，托德·多恩SIOS Technology 的銷售工程師解釋了最新版本如何適用於 Linux 的 SIOS LifeKeeper幫助公司保護關鍵企業系統免受停機和災難的影響。 「該版本具有新的網頁管理控制台。它是獨立的，不需要額外的安裝或第三方插件，」Doane 說。

經許可轉載安全作業系統

在 GenApp 和 QSP 之間進行選擇：為您的關鍵應用程式自訂高可用性

在 GenApp 和 QSP 之間進行選擇：為您的關鍵應用程式自訂高可用性

GenApp 還是 QSP？這兩種解決方案均受 LifeKeeper 支持，有助於防止關鍵應用程式停機，但了解這些解決方案之間的細微差別對於選擇適合您的特定需求的解決方案非常重要。以下是一些功能、優點和潛在用例，供您決定哪些功能最適合您的環境。

GenApp,通用應用程式的縮寫，是一種資源類型，可讓您在 LifeKeeper 中管理自訂應用程式。借助靈活的框架，您可以使用自己的腳本來執行應用程式可能需要的各種任務，以自動執行故障轉移和復原過程。這種靈活性允許對 LifeKeeper 如何處理啟動、關閉、監控、記錄操作等進行精細控制，以確保應用程式的高可用性。

QSP或快速服務保護旨在成為保護作業系統服務的快速且簡單的方法。 QSP 透過內建的可調整逾時來自動執行這些應用程式的監控、故障轉移和復原。此外，您可以建立依賴關係，以便服務可以與需要該服務的其他應用程式一起啟動和停止。

我如何選擇正確的解決方案？

您需要確定的第一件事是是否可以透過停止並重新啟動服務或守護程式來恢復您的應用程式。如果是這樣，那麼 QSP 可能是保持應用程式正常運作的最佳且最快的解決方案。這是因為它不需要編碼，幾分鐘之內您就可以將應用程式新增為 LifeKeeper GUI 中的 QSP 資源。此外，它是核心產品的一部分，任何編碼更新都包含在新產品版本中。但是，如果您的應用程式除了簡單的運行狀況檢查和作業系統服務等級的重新啟動功能之外還需要其他功能才能正確恢復，那麼您將需要探索 GenApps。為 GenApp 資源類型建立自訂腳本將需要更深入的技術技能和長期維護，但是，執行保持應用程式平穩運行所需的任何任務的靈活性至關重要，尤其是對於利基應用程式。這些任務可以是監視、日誌記錄、清理任務或配置變更等任何任務。

想要更多技術細節嗎？

Linux 和 Windows 版 LifeKeeper 均支援 GenApps 和 QSP，更多技術細節可在下面的連結中找到。

• 適用於 Linux 的 LifeKeeper 的 GenApp
• 適用於 Windows 的 LifeKeeper 的 GenApp
• 適用於 Linux 的 LifeKeeper 的 QSP
• 適用於 Windows 的 LifeKeeper 的 QSP

經許可轉載安全作業系統

是什麼導致故障轉移？

是什麼導致故障轉移？

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

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

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

「切換」是手動將層次結構從主節點移動到輔助節點的行為。這可以透過 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啟動或恢復故障的通訊路徑時，將會諮詢見證節點（見證設備）。見證檢查只能對具有法定人數的節點執行。

2. 資源失敗原因

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 基礎架構的產品。今天聯繫我們了解更多。

經許可轉載安全作業系統