SIOS LifeKeeper 與 Red Hat 高可用性附加元件：

SIOS LifeKeeper 與 Red Hat 高可用性附加元件：

如何為運行在 Linux 上的關鍵應用程式選擇合適的高可用性解決方案？

SIOS LifeKeeper for Linux 和 Red Hat High Availability Add-On 都能透過監控資源並在發生故障時將工作負載遷移到另一個叢集節點來保護應用程式。然而，它們在平台支援、應用程式整合、儲存靈活性以及配置和管理叢集所需的專業知識水平方面存在差異。

了解這些差異可以幫助組織選擇最適合其基礎設施和營運資源的解決方案。

SIOS LifeKeeper 與 Red Hat HA 附加元件：主要差異一覽

紅帽高可用性附加組件為運行在 Red Hat Enterprise Linux 上的應用程式提供故障轉移叢集。它使用 Pacemaker 進行資源管理，Corosync 進行叢集通信，並採用隔離和仲裁機制來保護資料完整性並防止腦裂情況的發生。

管理員可以透過 pcs 命令列介面、RHEL Web 控制台 HA 外掛程式或 Red Hat Enterprise Linux 系統角色來設定和管理集群，以實現自動化部署。

這種方法可能非常適合以下類型的組織：

• 他們已將基礎設施標準化為 Red Hat Enterprise Linux。
• 我們已擁有強大的心律調節器和Corosync技術專長。
• 希望對叢集資源和策略進行詳細控制
• 具備建置、測試和維護特定應用程式配置的內部資源

Pacemaker 的靈活性固然重要，但也可能帶來複雜性。管理員必須正確定義資源、依賴、限制、監控行為和隔離機制。應用程式保護可能需要選擇、配置或自訂資源代理程式和腳本。

適用於 Linux 的 SIOS LifeKeeper

適用於 Linux 的 SIOS LifeKeeper為 Red Hat Enterprise Linux、SUSE Linux Enterprise Server、Oracle Linux 和 Rocky Linux 提供應用程式感知的高可用性和災難復原保護。

一個關鍵區別在於使用了應用程式復原工具包（ARK）。這些軟體模組包含特定於應用程式的智慧功能，用於保護資料庫和應用程序，例如 SAP、SAP HANA、Oracle、PostgreSQL、SQL Server 和其他關鍵工作負載。

ARK 有助於自動化發現應用程式元件、驗證配置詳情、建立資源層次結構、監控應用程式堆疊以及根據應用程式最佳實踐管理復原的過程。此外，還提供通用應用程式復原工具包，用於客製化和內部開發的應用程式。

LifeKeeper可能更適合以下類型的組織：

• 可在多個Linux發行版上運行
• 需要特定應用的自動化和監控
• 需要減少對專業聚類技術的依賴
• 需要同時支援共用儲存和無 SAN 叢集配置。
• 在本地端、雲端或混合式環境中運行工作負載

LifeKeeper 還包含一個集中式 Web 管理控制台，可直觀地顯示應用程式和資源相依性。這使得配置叢集、了解資源關係以及監控應用程式運行狀況變得更加容易，而無需透過單獨的命令來管理每個元件。

儲存和雲端靈活性

儲存架構是另一個需要考慮的重要因素。

Red Hat HA 叢集可以設計用於多種儲存配置，但組織必須為其環境選擇和配置適當的儲存資源、隔離機制和支援元件。

LifeKeeper 支援傳統的共享儲存以及使用整合式、基於主機的區塊級複製的無 SAN 叢集。這使得組織能夠在共享儲存不可用或不切實際的情況下，在叢集節點之間複製本地存儲，包括在 AWS、Microsoft Azure、Google Cloud、虛擬化環境以及地理位置分散的環境中。

這種靈活性對於雲端和混合部署尤其有價值，因為傳統的共享儲存架構可能與可用的基礎架構不符。

選擇合適的HA解決方案

最佳選擇不僅取決於產品是否能夠啟動故障轉移。企業也應考慮如何輕鬆地配置、驗證、運作和更新環境。

Red Hat 高可用性附加元件為致力於 RHEL 並具備必要 Pacemaker 專業知識的組織提供了一個靈活的叢集框架。 SIOS LifeKeeper 則提供了一種更以應用為中心的方案，它內建了復原工具包、整合了複製選項、支援多發行版，並提供了一系列旨在簡化叢集管理的工具。

無論選擇何種平台，組織都應驗證整個應用程式環境，包括儲存、網路、資料庫、應用程式服務、相依性和用戶端連線。高可用性並非只是將工作負載遷移到另一台伺服器，而是要確保在發生故障時，整個應用程式仍然可存取且可正常運作。

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

經許可轉載SIOS

應用彈性現況：2026 年 SIOS 高可用性調查

應用彈性現況：2026 年 SIOS 高可用性調查

來自 250 多位 IT 領導者的見解，探討如何彌合混合基礎架構複雜性與真正應用程式正常運作時間之間的差距。

SIOS 對北美和英國的 250 多位 IT 主管進行了調查，以了解企業目前如何保護關鍵業務應用程式。研究揭示了複雜的 IT 環境與傳統高可用性和災難復原 (HA/DR) 策略的可靠性之間存在日益擴大的差距，表明儘管在混合雲和多雲基礎設施方面投入巨資，應用程式停機問題依然存在。

立即下載完整的 SIOS 2026 高可用性調查報告，了解現代 IT 痛點、隱藏的系統漏洞以及高可用性 (HA) 和災難復原 (DR) 的未來支出重點。

經許可轉載SIOS

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

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

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

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

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

不同層級的故障各不相同

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

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

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

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

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

這使得 LifeKeeper 能夠：

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

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

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

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

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

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

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

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

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

經許可轉載SIOS

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

為什麼 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 上持續運行

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

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

經許可轉載SIOS