什麼是高可用性（HA）？

如今世界上充斥著各種各樣的縮寫詞；有時，要記住它們的含義著實不易，尤其對於沒有技術背景的普通用戶而言更是如此。 HA 這個縮寫已經存在了幾十年。那麼，用簡單易懂的語言來解釋它的意義是什麼呢？ HA 代表高可用性（High Availability）。 HA 指的是，公司賴以生存的電腦系統（公司和客戶都依賴這些系統）在客戶每天任何時間存取時都能正常運作。例如，您嘗試透過手機或筆記型電腦上的應用程式存取您的銀行帳戶，查看餘額或進行電子存款。但您收到一條錯誤訊息，提示系統無法連接，請稍後再試。您可能認為只有您遇到了這個錯誤，於是重新啟動了筆記型電腦和手機。但您仍然收到相同的錯誤提示：「系統無法連線」。這意味著什麼？這意味著銀行的電腦系統似乎宕機了，您無法存取！您可能會疑惑－銀行的電腦系統怎麼會離線呢？如果企業未能為其營運系統實施高可用性 (HA) 解決方案，則可能會發生這種情況。

HA 的工作原理

那麼，高可用性（HA）在實際應用上是如何運作的呢？讓我們來詳細了解一下。 HA 可以透過運行在企業電腦上的軟體或內建在企業電腦的硬體來實現。本文重點在於概括性地描述 HA 軟體在企業電腦上提供的功能。 HA 的作用是確保電腦始終保持運作狀態，以便企業及其客戶可以隨時存取資料和資訊。 HA 如何保證電腦始終保持運作狀態？ HA 由幾個關鍵組件組成。

• 計算機之間的監控– 在高可用性 (HA) 系統中，通常會有兩台電腦協同工作，以確保其中一台始終處於運作狀態。每台電腦都會按照可設定的時間間隔與另一台電腦通信，並詢問「你在線上嗎？」。如果沒有收到「你在線上嗎？」的回复，HA 軟體就會決定讓另一台電腦運行業務，並即時自動執行此切換，無需人工幹預。
• 監控電腦上運行的應用程式企業高效運作依賴於電腦上運行的各種應用程式和關鍵程式。監控就像主電腦詢問每個應用程式：“你運作正常嗎？”如果應用程式和關鍵程式回答“不正常”，則高可用性軟體會嘗試在主電腦上修復問題。如果主電腦上的「不正常」狀態持續存在，則高可用性軟體會自動決定讓另一台電腦運行業務，並即時實施此變更。

價值論證

現在我們已經了解了高可用性 (HA) 的概念及其基本工作原理，其價值顯而易見。 HA 硬體、軟體和架構為企業提供了一種確保系統高可用性、持續運作的方法，無需手動監控系統以確保其正常運作。如果沒有 HA，企業將面臨停機、客戶流失和銷售損失的風險。在當今世界，任何企業都無法承受這些問題。企業高度依賴其電腦、應用程式、服務和數據來維持不間斷的運營，因為停機會直接影響其獲利能力。當系統無法使用時，公司不僅會損失收入，還可能面臨客戶流失的風險。如果客戶無法及時存取所需的服務或數據，他們很可能會轉向競爭對手，這是任何企業都不願看到的局面！

作者：Sandi Hamilton，SIOS產品支援工程總監

經許可轉載SIOS

如何在周五晚上的系統崩潰中倖存下來：從簡陋的裸機到無縫的數據複製

那是我高二那年。週五晚上很晚了，像大多數青少年一樣，我正對著電視發呆。突然，螢幕的光亮被手機的亮屏打斷了。一陣嗡嗡聲。接著又是一陣。然後是一陣持續不斷的震動，這只能說明一件事：Discord 又崩潰了，客服工單如潮水般湧來，服務器又宕機了。

當伺服器停機成為業務的一部分

那時，災難性的宕機幾乎成了我日常生活的一部分。遊戲託管產業簡直就是基礎建設領域的蠻荒西部。競爭對手伺服器發起的定向DDoS攻擊、經驗不足的客戶誤操作導致配置崩潰，以及廉價裸機伺服器不可避免的硬體故障，混亂成了這個行業不可或缺的一部分。當我的同學們還在為生物考試焦頭爛額時，我卻在凌晨兩點瘋狂地透過SSH登入伺服器，祈禱一次強制重啟就能讓節點恢復在線。

最終，這種持續不斷的混亂開始造成沉重的代價。就我個人而言，獨自一人24小時不間斷地負責故障回應，這種巨大的壓力已經讓我精疲力竭。但從商業角度來看，損失更加慘重。每一分鐘的停機都意味著要從本就微薄的利潤中支付服務等級協定（SLA）補償金。這意味著自然成長的流失、潛在客戶的流失，以及應對玩家理所當然的沮喪。我痛苦地意識到，停機不僅是技術故障，更是一筆巨大的財務損失。

尋找更佳的高可用性策略

我知道必須做出改變。我花了幾個小時研究企業架構，但作為一個獨自運作、資金匱乏的青少年，我的高可用性策略本質上只是一堆臨時拼湊的 Bash 腳本。我找到了一些實現基本故障轉移的方法，但始終找不到可靠且經濟實惠的方法來確保真正的資料複製。

最終，我交出了鑰匙，把主機託管業務賣給了競爭對手，之後便離開了伺服器機架，走進了大學的講堂。但隨著我學業的深入，那些令人抓狂的宕機事故留下的創傷卻始終揮之不去。我總是忍不住去想基礎設施、停機時間，以及那些科技巨頭是如何輕鬆應對曾經讓我的網路癱瘓的故障的。我孜孜不倦地努力理解這種差距，最終促使我獲得了在SIOS的實習機會。

探索 SIOS DataKeeper 和無縫資料複製

走進這個工程環境，感覺就像踏入了一個平行世界，我青少年時期對基礎設施的種種擔憂都已迎刃而解。當我第一次親眼目睹 SIOS DataKeeper 的運作時，我被深深震撼了。這正是我多年前苦苦尋找的東西。

看著一台機器上的編輯內容無縫轉移到另一台機器上，並在模擬故障轉移期間完全按照預期運行，真是令人難以置信。它與其他系統無縫集成，徹底杜絕了停機時間，這讓我確信，我曾經夢寐以求的完美基礎設施真的存在。

從簡陋的基礎設施到關鍵任務型高可用性

如今，我的工作完美地融合了我早年奮鬥的經驗和業界頂尖標準。我直接站在技術支援的第一線，確保我們的軟體和客戶的架構完美運作。每一天，我都能幫助企業保障其關鍵業務資料的線上安全。

這讓我感到一種無比深刻、圓滿的滿足感。每當我幫助客戶建立高可用性系統時，我都會想起那個獨自一人在周五晚上摸黑摸索的少年。如今，我不再只是渴望擁有一個安全網，而是積極地幫助其他企業打造堅如磐石、無需恐慌的基礎設施，這種感覺真是太棒了。

作者：Brit Weinstein，SIOS客戶體驗工程師實習生

經許可轉載SIOS

接地氣：錯過Percona Live Amsterdam讓我對HA有了哪些新的認識

坐在機場的地板上，眼睜睜地看著出發航班資訊牌因為關鍵系統故障而變成一片紅色的取消航班，而你這週的日程安排卻是全力以赴地維護數據庫的高可用性，這真是莫大的諷刺。

與其在 Percona Live 大會上一邊吃著焦糖華夫餅一邊討論同步複製與異步複製、災難恢復策略和連接路由等問題，我不如花幾個小時觀看英國空中交通管制基礎設施實時演示系統故障時會發生什麼。

當中央飛行處理系統發生故障時，飛機不會墜毀…人工操作員會手動降低處理能力以確保安全。這對於航空電子設備來說是良好的工程設計。但從操作和使用者角度來看，吞吐量會立即降至零。

在資料基礎設施領域，我們沒有條件對交易進行接地處理。

單點故障剖析

一個系統可以擁有分佈在三個可用區的冗餘硬體、雙電源以及昂貴的供應商合約。然而，如果所有流量都通過單一狀態協調器、集中式配置攝取管道或共享控制平面，那麼你擁有的就不是分散式系統，而是一個代價高昂的分散式單點故障（SPOF）。

當飛行處理流程因輸入格式錯誤或集中式狀態偏差而阻塞時，主節點和輔助節點通常會同時觸發安全模式鎖定。在我們的系統中，這相當於：

• 裂腦情景當兩個主資料庫節點鎖定表或退出仲裁以防止資料損壞時，就會發生這種情況。
• 健康檢查協調器將網路延遲誤判為完全故障，導致主連線頻繁切換，直到連線池耗盡。
• 一個備份集群，能夠在幾毫秒內忠實地複製損壞的元資料或毒丸交易。

冗餘只是指擁有兩份相同的東西。而彈性則是指知道備用件不會重蹈覆轍。

真正的HA需要什麼

如果你的系統在凌晨 2 點主路徑突然中斷後，無法在無人幹預的情況下繼續運行，那麼你並沒有實現高可用性，而只是擁有了一個連接在焦慮的工程師身上的警報系統。

• 基於法定人數的共識制應對脆弱的初選：依賴簡單主動/被動複製和手動 DNS 故障轉移的系統極易導致停機。現代集群（無論是使用 Galera、群組複製或 Raft/Paxos 等共識協議）都需要奇數個節點和法定人數，以確保自動、安全地選舉領導者，避免腦裂。
• 智慧交通脫鉤：應用程式絕不應直接指向資料庫節點的硬編碼 IP 位址。七層代理程式、智慧連線池（例如 ProxySQL）和虛擬 IP 將應用程式用戶端與底層基礎架構的頻繁變更隔離。如果節點 A 發生故障，節點 B 會接管寫入操作，應用程式只需不到一秒鐘即可完成重新連接，而不會完全中斷。
• 隔離故障域：真正的高可用性 (HA) 會隔離輸入。如果包含致命查詢或格式錯誤的設定封包進入系統，則必須將其隔離。如果主節點在執行過程中崩潰，故障轉移不應自動將完全相同的致命查詢重播到備用節點上，從而導致整個叢集宕機。
• 重在鑽探而非文檔：如果你還沒有在模擬網路分區和高負載條件下測試過自動故障轉移，那麼你的故障轉移計畫就只是一個假設。

總結

錯過阿姆斯特丹的走廊巡演和現場演示令人遺憾。但凝視著停滯不前的機場航站樓，卻讓我更加深刻地意識到：停機時間絕不是 Grafana 儀表板上的抽象指標。它會導致真實的人員滯留、營運中斷，並摧毀信任。

做好容錯設計。實現故障恢復自動化。測試集群。

作者Aaron West，SIOS 銷售工程師

經許可轉載SIOS

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 高可用性調查

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

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

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

經許可轉載SIOS