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 Technology 的銷售工程師解釋了最新版本如何適用於 Linux 的 SIOS LifeKeeper幫助公司保護關鍵企業系統免受停機和災難的影響。 「該版本具有新的網頁管理控制台。它是獨立的，不需要額外的安裝或第三方插件，」Doane 說。

經許可轉載安全作業系統

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

經許可轉載安全作業系統

更好支持的三個技巧

Betsy 是一輛 1999 年 Amazon Green Ford F-150，這是我購買的第一輛車。我不知道我的卡車是如何得到“貝特西”這個名字的，也不知道為什麼它被卡住了，但它確實被卡住了。在超過17 年的時間裡，貝特西做了各種各樣的事，從在海灘巡游到在跑道上比賽，拖運大量的園林綠化用品，再到帶著我不斷壯大的家人穿越東南部。經過很多英里和多年的學習如何保養卡車後，她開始展示磨損情況。在一次下午開車時，我注意到溫度計逐漸升至 H（高）。經過幾次交談後，我帶貝特西去了當地一家經銷商的服務部門，開始了一週的自我折磨。

第一次訪問時，我匆忙提供了高級細節。 「幾分鐘後，卡車就開始發熱了，」我說。六個小時後，我花了 100 美元取回了我的卡車。技術人員無法重現問題。因此，我被送回家，並支付了診斷費，並要求如果再次發生這種情況就回來。第二次來時，我匆匆補充說，問題發生在 18 分鐘或 14 英里的駕駛時間超過 45 分鐘的通勤時間之後。六個小時後，花了大約 375 美元，我取回了我的卡車。技術人員能夠用新的細節重現問題，並更換了恆溫器和軟管。第三次來的時候，技術員的電話提前打來：“先生。”魯，你需要一個新的散熱器。

這就是這個故事的簡短版本。較長的版本包括我未能向服務技術人員解釋在第一次和第二次訪問之間我已經更換了恆溫器。它還忽略了一個事實，即我對散熱器液體進行了沖洗和填充，並且很可能在此過程中使軟管夾鬆動。最重要的是，它忽略了一個事實：我的鄰居（一名機械師）在卡車出現此問題之前告訴我，要更換散熱器並進行其他預防性維護。現在，這與更好的客戶體驗有什麼關係呢？

以下是我從自己遭受的磨難中學到的三個教訓，它們將改善您的客戶體驗，而不僅僅是您的下一次汽車服務。

首先，取得並提供所有詳細資訊。

在我第一次訪問時，我匆忙向服務技術人員提供了最基本的詳細資訊。結果，無法實現適當的解決方案。世界上的許多事件發生在最不合時宜的時間，並帶來很大的壓力和時間限制，但向您的客戶體驗團隊提供盡可能多的詳細資訊仍然是最佳實踐。您什麼時候注意到這個問題，或者問題是什麼時候發生的？您注意到了什麼或問題的症狀是什麼？當時還發生了什麼其他事情？

考慮您可能提供的任何其他支援詳細信息，包括錯誤訊息和錯誤代碼、軟體系統日誌、客戶端日誌以及捕獲錯誤情況或症狀的任何圖片。很多時候我們喜歡認為軟體中的事物是不相關的，但事實上它們是非常相關的。

其次，描述你所做的事情（好的或壞的）。

當我第二次來的時候，我給自己和技術人員帶來了另一個極大的傷害。我沒有解釋我已經嘗試過的所有事情（好的和壞的），並分享解決問題的失敗嘗試，而是推遲了我的解決方案。如果我告訴大家我已經更換了恆溫器，對散熱器進行了沖洗和重新填充，也許技術人員會去其他地方尋找問題。當您分享您為解決問題所採取的措施以及您可能採取的措施使問題變得更糟時，它可以幫助您的客戶體驗團隊改進他們的回應，專注於其他問題領域，消除虛假的轉移注意力（不相關的問題或事情）偽裝成真實問題），並提供整體更出色的體驗。

最後，執行之前的建議。

在問題出現之前，我的鄰居根據他多年的經驗和我的卡車的車齡提供了建議。他告訴我更換散熱器，進行一些預防性維護，並對卡車的整體健康狀況進行例行檢查。最有可能的是，您的客戶體驗團隊在其知識庫中提供了與您的產品相關的建議以及與企業可用性要求營運相關的多年經驗。使用它們進行預防性維護、主動調整，並檢查您的可用性環境是否遵守這些最佳實踐。但最重要的是，當他們提出建議時，執行它。最後，您將節省大量時間、金錢和麻煩。

第三次訪問兩天后，新散熱器的缺貨到達，我更換了散熱器。我又繼續開著 Betsy 好幾年，最後才把它換成了一輛家用 SUV。

經許可轉載安全作業系統