家庭自動化設備應該「部署」在哪裡？根據您的可用性目標進行部署。

在最近的一次貿易展上，一個問題被反覆提及：SIOS LifeKeeper 實際運作在哪裡？

答案至關重要。 LifeKeeper 直接安裝在每台受保護伺服器的作業系統上。這種安裝方式使其能夠存取應用程式、其支援資源以及維持工作負載可用性所需的依賴項。

這與僅依靠基礎設施層或容器層的HA（高可用性）有所不同。

不同層級的故障各不相同

虛擬機器管理程式層級的高可用性可以偵測到發生故障的實體主機，並將其虛擬機器重新啟動到其他位置。容器編排平台可以替換故障的容器，或在節點之間遷移工作負載。

這些功能提供了有效的保護，但它們是在應用程式外部運行的。即使虛擬機器內部的資料庫掛起或 Web 服務崩潰，虛擬機器仍可能繼續運作。同樣，容器重新啟動後，可能並未徹底解決資料、儲存、網路或依賴服務方面的問題。

提供高可用性的層決定了它可以看到哪些故障以及如何精確地做出回應。

為什麼系統內高可用性 (HA) 能提供更深層的保護

由於 LifeKeeper 在作業系統內運行，因此它可以監控實際應用程式環境的運作狀況，而不僅僅是託管該應用程式的伺服器、虛擬機器或容器。

這使得 LifeKeeper 能夠：

• 監控申請流程和支援資源
• 了解應用程式、儲存、網路和其他依賴項之間的關係
• 偵測基礎設施監控可能遺漏的應用層故障
• 協調復原和故障轉移，確保以正確順序進行，以確保資料完整性
• 將整個應用程式環境遷移到健康的系統

這種應用感知方法有助於縮小「伺服器正在運行」和「應用程式可用」之間的差距。

投放位置應與可用性目標相符

HA（住房援助）的居住地點應根據必須保留的資源來決定。

如果主要目標是從硬體或主機故障中恢復，那麼基礎架構層級的高可用性可能就足夠了。但如果可用性目標涉及業務關鍵型應用程式及其數據，那麼更接近應用程式的保護措施可以提供更高的可見性和更有針對性的恢復。

這些方法並非必須互相排斥。基礎設施層、容器層和應用層高可用性可以協同工作，形成多層保護。關鍵在於理解每一層監控的內容，以及恢復責任的起始點和結束點。

高可用性解決方案與應用程式的貼近程度越高，出現故障時就能獲得越多的上下文資訊。對於服務等級協定 (SLA) 要求嚴格、復原時間目標 (RTO)/復原點目標 (RPO) 要求高的企業而言，這種情境資訊至關重要，它決定了企業是重啟基礎架構還是恢復使用者真正依賴的服務。

準備好彌合您環境中的可用性差距了嗎？聯絡我們的團隊，了解 SIOS LifeKeeper 如何幫助您實現最關鍵的正常運作時間目標。

作者：Ben Roy，SIOS 行銷項目專員

經許可轉載SIOS

為什麼 99.99% 的正常運作時間並不代表 100% 的正常運作時間

你有沒有仔細觀察過洗手液的包裝？ 「殺死99.99%的細菌」通常會醒目地印在包裝的某個位置。如果你跟我一樣，可能會產生一個很合理的疑問：「那剩下的0.01%呢？」究竟是什麼讓這最後的0.01%如此難以殺滅？我們在高可用性（HA）軟體方面也會遇到同樣的問題。在討論HA正常運作時間時，你很可能已經看過99.99%這個數字。問題依然存在：為什麼我們無法實現100%的正常運作時間？

首先，我們來談談 99.99% 正常運作時間究竟意味著什麼。正常運行時間指的是應用程式運行並可供最終用戶使用的時間。通常，這是以年為單位進行衡量的。要達到 99.99% 的正常運作時間，停機時間不得超過 52.60 分鐘。平均而言，這意味著：

每年52分36秒

每月 4 分 23 秒

每週 1 分 0 秒

每天 0 分鐘 8 秒

那隻是很短的時間，但算不了什麼，那麼它究竟是從哪裡來的呢？

有意造成的停機時間

讓我們先來看看一些最基本的停機原因。事實上，無論你的高可用性軟體多麼出色，執行諸如切換之類的常見操作總是需要一些時間。每次你主動發起切換時，都會產生極短的停機時間。根據層級結構的大小，這可能需要幾秒鐘到幾分鐘不等。為了理解其中的原因，我們需要了解切換發生時的具體情況。在資源層面，我們必須先將資源從目前活動節點上完全移除，然後再將資源完全啟用到新的活動節點上。根據應用程式的不同，這可能意味著運行幾個簡單的命令，也可能意味著運行冗長而複雜的優雅關閉操作，然後在另一台伺服器上進行緩慢的冷啟動。在層級層面，在許多情況下，我們必須一次執行一個操作。如果一個資源有任何子資源，那麼在開始移除初始資源之前，必須先將所有子資源完全移除；然後，在另一台伺服器上，我們必須先讓所有子服務完全投入運行，才能開始啟動主服務。對於多層級架構和複雜的切換流程，這會造成相當大的時間損失。這是一種固有的、不可避免的停機時間，但幸運的是，在大多數情況下，最終用戶除了感覺到加載時間略微延長或需要短暫重新連接之外，不會察覺到任何異常。然而，這確實會增加停機時間的計算。

另一種固有的停機形式是維護。幸運的是，大多數維護工作都可以以高可用性的方式進行。這意味著先在備份節點上執行維護，進行切換，然後在先前執行的系統上執行維護。如上所述，這會造成一定程度的停機，但停機時間應該很短。然而，有些維護工作無法以高可用性的方式進行。在這種情況下，可能會出現相當長的停機時間，從而增加全年的總停機時間。

無意造成的停機時間

一旦我們開始關注高可用性軟體的主要用途：災難恢復，就會發現其中的利害關係。即使一切都按計劃完美進行，任何故障都會造成一定程度的停機時間。我們首先來看看在成功故障轉移過程中停機時間是如何產生的。為了從故障中正確恢復，我們必須先檢測並驗證故障。這是一個需要權衡的難題。如果故障偵測過於激進，可能會偵測到實際上並未發生的故障（誤報故障）。如果偵測不夠激進，故障偵測速度可能會過慢。大多數故障首先會被定期運行的進程偵測到。對於單一資源故障，通常是檢查腳本失敗；對於整個伺服器故障，通常是心跳遺失。在這兩種情況下，我們都不會在發生一次故障後立即啟動恢復。相反，我們會進行重試，並等待多次故障以驗證真正的故障。例如，執行更複雜的資源狀態測試的深度檢查腳本預設每五分鐘執行一次。這意味著檢測某些故障可能需要長達五分鐘的時間，而根據故障類型的不同，驗證故障可能需要更長時間。在檢測並驗證故障後，根據故障類型，我們可能會嘗試多次本地恢復。如果恢復成功，可以節省一些停機時間；但如果恢復失敗，則會略微增加故障切換的停機時間。在檢測故障、驗證故障並嘗試本地恢復後，我們將執行故障切換。根據故障的具體類型，故障切換所需的時間可能與先前描述的切換停機時間類似。所有這些潛在的延遲因素加起來，可能會顯著增加停機時間。幸運的是，大多數故障都能快速偵測到，並且與上述切換類似，最終使用者幾乎不會察覺到故障的發生。

第二個導致意外停機的原因是故障轉移失敗。一旦發生故障轉移，停機時間會顯著增加，因為故障轉移需要合格的技術人員介入並正確地恢復系統。雖然這種情況比較少見，但確實會發生。幸運的是，故障轉移幾乎總是可以預防的。確保故障轉移按計劃進行的最佳方法是提前進行測試。配置錯誤很容易發生，但只需執行一次故障轉移測試即可發現任何此類問題。確保故障轉移成功的另一種方法是確保叢集盡可能頻繁地做好故障轉移準備。這意味著要確保備份系統正常運行，並且資源處於 ISP（服務保護）狀態。例如，未處於鏡像狀態的 DataKeeper 映像不會處於 ISP 狀態，因此發生故障時將無法進行故障轉移。為確保資源能夠順利切換，應採取措施確保 DataKeeper 盡可能頻繁地進行鏡像，並且其他資源也保持最新狀態，隨時準備進行故障轉移。

導致意外停機的最後一個原因是 LifeKeeper 無法控制的問題。網路問題可能導致故障轉移成功或失敗，但也可能使看似健康的叢集無法訪問，具體取決於系統的設定方式。同樣，底層雲端或虛擬化軟體的問題也可能導致 LifeKeeper 無法處理的問題。為了避免這些問題，盡可能地將系統隔離，可以讓 LifeKeeper 免受這些問題的影響。所有系統都位於同一可用區或同一網路上的叢集比包含分散系統的叢集更容易出現問題。 LifeKeeper 無法控制的另一個問題是內部應用程式問題和人為錯誤。例如，意外刪除關鍵資料可能會為最終用戶帶來問題，而這些問題很可能無法被 LifeKeeper 偵測到或修復。使用備份軟體可以幫助從這類問題中恢復，但無法彌補損失的正常運行時間。最後，高可用性不一定能抵禦惡意行為者和網路安全威脅。某些攻擊可能會導致正常運作時間損失。為防止此類問題，建議使用可信賴的防毒/反惡意軟體套件。

可避免的停機原因

正如上文多節所述，許多停機原因完全可以避免。我不會在此一一列舉所有可避免的停機類型，但會重點介紹幾種最常見的類型。

在初始設計叢集拓樸結構時，需要考慮以下幾點。腦裂是指兩個節點都認為自己是主節點的情況，可以透過某種形式的仲裁機制來避免。如果您正在開發一個通用應用程序，請務必編寫並使用快速檢查和深度檢查腳本，以便能夠真正檢測到故障。最後，請確保設定多條通訊路徑，這些路徑跨越多個網路卡和網路。

系統配置不當也會導致停機。前面已經提到了一些例子。首先，確保受保護的應用程式、底層作業系統和高可用性軟體都已更新至最新版本。許多停機是由於一些原本可以完全避免的、但已被修復的漏洞所造成的。其次，在叢集配置完成後以及之後定期進行切換和故障轉移測試。透過這些測試，可以提前發現並預防許多可能導致故障轉移失敗的問題。第三，確保始終有一個備用節點處於運作狀態並隨時準備接手。

配置不當的系統會導致停機。為避免這種情況，LifeKeeper 和 DataKeeper 提供了可調參數，用於最佳化效能、心跳間隔、資源檢查和重試設定。雖然預設設定通常足夠，但任何更改都應在充分了解其影響和必要性後進行。務必優先考慮 SIOS 支援團隊的指導，因為他們的建議是基於豐富的專業知識，應嚴格遵循以確保系統可靠性。

作者：Carter Chandler，SIOS公司副軟體工程師

經許可轉載SIOS

網路研討會：透過設計實現彈性－確保關鍵業務工作負載在 AWS 上持續運行

在 AWS EC2 上建立彈性、高可用性的工作負載對於執行關鍵業務應用程式的組織至關重要。本次網路研討會將探討如何設計和營運此類工作負載。AWS中的高可用性架構同時兼顧複雜性、合規性和成本。

探討如何應對單點故障、復原缺口和營運複雜性等常見挑戰，並結合真實案例進行分析。金融服務，衛生保健， 和建築維護系統取得實用指導，以增強韌性、降低風險並優化您的 AWS 環境。

經許可轉載SIOS

了解 CLI 在高可用性環境中的作用

當人們想到高可用性 (HA) 時，首先想到的是叢集、自動故障轉移、複製和災難復原等技術。這些功能對於確保應用程式和服務的可用性至關重要。然而，HA 解決方案中一個容易被忽視的方面是管理員如何與環境互動和管理環境。

如今，許多解決方案同時提供圖形使用者介面 (GUI) 和命令列介面 (CLI)。兩者各有其用，最佳選擇通常取決於手頭上的任務、環境規模以及組織的營運實踐。

雖然圖形使用者介面 (GUI) 提供了一種直覺的方式來視覺化叢集健康狀況並執行管理任務，但命令列介面 (CLI) 則提供了一系列不同的優勢，這些優勢在高可用性環境中特別有用。了解這些優勢有助於組織確定命令列介面如何融入其整體管理策略。

支援自動化和可重複性

CLI 最廣為人知的優勢之一是其與自動化工具和腳本的整合能力。諸如檢查叢集狀態、修改設定或執行例行維護等管理任務通常可以整合到 shell 腳本、編排平台或設定管理工具中。這使得組織能夠自動化重複性流程，從而提高跨環境的一致性並最大限度地減少人為錯誤。隨著基礎設施的擴展，自動化例行操作的能力對於簡化維護任務變得越來越重要。

隨著環境發展而擴展

單一集群的管理需求與數十個甚至數百個集群的管理需求截然不同。隨著環境的擴展，管理員通常需要尋找在多個系統中有效執行常見任務的方法。命令列介面 (CLI) 可以簡化重複性操作的腳本編寫、健康資訊收集、報告產生以及跨大型環境的協同維護等操作。命令列工具並非要取代圖形化管理，而是透過提供高效的介面來補充圖形化管理，從而實現大規模的管理操作。

鼓勵持續運營

在任何生產環境中，一致性都是一項重要的考量因素，尤其是在高可用性環境中。命令列介面 (CLI) 允許管理員在開發和生產環境中執行相同的命令。標準化流程可以被記錄、審查和重複使用，從而幫助團隊以一致的方式執行常見的管理任務。這種一致性有助於減少配置隨時間推移而發生的偏差，並使維護視窗期間的操作流程更容易重現。

遠端管理的靈活性

高可用性環境通常分佈在多個資料中心、雲端區域或地理位置。管理員可能需要遠端管理集群，有時需要在網路條件不佳的情況下進行。命令列介面 (CLI) 提供了一種輕量級的方法，可以透過安全連接與叢集進行互動。這在頻寬有限或圖形化管理工具不可用時尤其有用。雖然圖形使用者介面 (GUI) 通常提供更豐富的視覺體驗，但 CLI 提供了一種替代管理選項，在各種操作場景下都能保持有效。了解更多關於如何選擇高可用性雲的信息。

選擇合適的介面

對許多組織而言，選擇圖形使用者介面 (GUI) 還是命令列介面 (CLI) 的問題並非在於是否使用其中之一，而是如何有效地使用它們。 GUI 的優點在於能夠清楚地展示叢集運作狀況、視覺化資源關係，並使各種使用者都能輕鬆存取管理功能。另一方面，CLI 通常非常適合自動化、腳本編寫、重複性操作以及大型環境的管理。將這兩種介面結合使用，可以讓管理員充分利用各自的優勢，並為特定任務選擇最合適的工具。

結論

管理高可用性環境不僅僅是維持正常運作時間；它還需要工具來支援在維護或事件回應期間高效、一致且可靠的操作。命令列介面在自動化、可重複性和一致性等方面具有優勢。同時，圖形介面透過簡化視覺化和日常管理，繼續發揮重要作用。

與其將一種介面視為另一種介面的替代品，組織或許更應該了解每種介面如何為有效的集群管理做出貢獻。透過在最合適的地方充分利用這兩種介面，管理員可以建立能夠隨著其高可用性基礎架構而擴展的操作工作流程。。

作者Tristan Allen，SIOS Technology Corp 的助理軟體工程師

經許可轉載SIOS

網路研討會：從恐慌到主動：高可用性入門指南

伺服器嚴重故障不應該導致長達數小時的緊急停機。如果您是系統管理員、新上任的資料庫管理員，或被委以重任負責系統維護的「非專業」資料庫管理員，您絕不能將系統正常運作時間寄託於運氣。

在這節初學者的點播課程中，我們將深入淺出地講解高可用性的基本原理。您將了解導致意外中斷的根本原因、自動故障轉移的工作原理，以及叢集和雲端基礎架構等現代技術如何確保您的關鍵系統全天候穩定運作。

經許可轉載SIOS