你可以透過在架構的每一層中建置備援，來設計一個高可用伺服器叢集。高可用性能讓你的應用程式即使在基礎設施部分元件發生故障時，也依然保持可存取且回應迅速。當某個元件失效時，備援元件會立即接手；而多可用區部署則能幫助你抵禦局部區域故障。災難復原方案則讓你能夠在發生重大中斷時快速恢復服務。在開始之前，你需要先評估應用程式的需求，並選擇合適的基礎設施型態，無論是雲端環境、裸機，還是邊緣部署。

高可用架構原則

什麼是高可用性？

你希望應用程式即使在出現問題時也能持續上線。高可用性意味著即便部分元件失效，系統仍然能夠持續運作。在高可用伺服器叢集中，你要盡可能消除單點故障。這種方式能夠確保使用者始終可以存取你的服務。大多數組織都會將全年至少達到 99.99% 的可用性作為目標。你可以從下表看出，不同可用性等級對停機時間的影響：

  • 高可用性的核心在於持續運作與盡可能高的上線率。
  • 四個 9（99.99%）代表每年大約只有 52 分鐘的停機時間。
  • 五個 9（99.999%）代表每年僅允許約 5 分鐘的停機時間。
  • 100% 上線是理想目標，但幾乎不可能真正實現。

為什麼高可用性對應用程式至關重要

停機會損害你的業務，也會讓使用者感到挫折。你需要一套高可用策略來保護應用程式，避免常見的當機情境。這些原因包括人為失誤、硬體故障、網路攻擊以及網路問題。下表展示了最常見的停機原因：

原因說明
人為失誤43% 的非計畫性停機源於設定錯誤等人為操作失誤。
硬體故障電力問題或硬體零件損壞都可能導致伺服器停止運作。
網路攻擊（DDoS）攻擊者可能利用大量虛假流量癱瘓你的伺服器。
DNS 故障DNS 問題會導致網站無法存取。
資料庫瓶頸資料庫回應緩慢會讓應用程式看起來像是已經當機。
網路基礎設施問題網路元件損壞可能會切斷使用者對服務的存取。

穩健的高可用架構能夠幫助你避免這些問題。你需要建置備援、使用多個叢集，並為快速復原做好規劃。

關鍵指標與 SLA

你需要使用明確的指標和服務等級協議（SLA）來衡量高可用性。下表展示了不同可用性水準下預期的停機時間：

可用性百分比「幾個 9」等級每年停機時間
99%兩個 93.65 天
99.9%三個 98.77 小時
99.99%四個 952.60 分鐘
99.999%五個 95.26 分鐘

你還應該追蹤 RTO（復原時間目標）與 RPO（復原點目標）。RTO 指系統最長可接受的停機時間；RPO 指你最多可以接受的資料遺失量。對於高可用設計而言，這兩個數值都應該盡可能低。雲端服務供應商通常承諾 99.9% 的可用性，而真正的高可用方案通常會追求 99.99% 甚至更高。

設計高可用伺服器叢集

伺服器叢集中的備援設計

要實現高可用伺服器環境，你必須在伺服器叢集中建置備援。備援意味著當某一部分發生故障時，你已經準備好可以立即接手的備用系統。這種方法能夠保障應用程式持續運作，並減少使用者感知到的停機。

叢集中的常見故障點包括：電力中斷、網路硬體故障、磁碟損壞、記憶體問題、軟體缺陷，甚至人為失誤。下表列出了一些典型風險：

故障點說明
電力故障停電會讓節點離線，並在重新啟動完成前中斷叢集服務。
網路硬體故障交換器、路由器或網路卡故障如果沒有備援，會導致節點效能異常甚至不可用。
磁碟故障硬碟可能因老化磨損而損壞，從而影響叢集功能。
記憶體問題資料損毀或 RAM 故障可能導致伺服器關機，或影響堆疊中的其他元件。
軟體相容性問題衝突的軟體指令會擾亂節點運作，導致效能不一致。
安全漏洞應用程式中的弱點可能被攻擊者利用，導致伺服器關閉或無法存取。
軟體缺陷軟體中的錯誤可能引發異常行為，甚至導致伺服器完全失效。
資源耗盡不合理的網路設定可能使節點過載並最終當機。
延遲過高的延遲會使節點失去回應，破壞叢集功能。
網路分割叢集部分區域彼此隔離時，即使節點本身正常，也可能觸發系統故障。
環境因素與人為失誤環境事故和操作錯誤都可能嚴重擾亂伺服器叢集的工作流程。

為了應對這些風險，你應採用 3 節點或 5 節點拓樸。這種部署方式具有較高備援度，能夠幫助叢集在多種故障情境下持續運作。當某個節點失效時，自動故障轉移會把工作負載遷移到健康節點上，從而維持服務可用與穩定。

建構高可用叢集時，常見的備援策略包括：

  • 同時採用主動-主動（Active-Active）與主動-被動（Active-Passive）設定，以平衡流量並提供備援。
  • 在不同節點上維護關鍵資源的多個副本。
  • 設定自動故障轉移，在節點失效時快速遷移工作負載。
  • 妥善管理仲裁（quorum），防止出現「腦裂」問題，即叢集兩部分各自獨立運作。
  • 持續監控資源與應用程式，及早發現問題。

多可用區叢集部署

透過跨多個可用區部署叢集，你可以顯著提升上線率與整體韌性。每個可用區都擁有獨立的電力、冷卻與網路資源。這種隔離能夠降低單一事件拖垮整個部署的風險。

下表說明了多可用區部署如何強化你的高可用策略：

面向說明
備援即使某個可用區發生故障，應用程式也能依靠備援與故障轉移機制持續保持可用。
基礎設施獨立性各可用區擁有獨立的電力、冷卻與網路資源，可減少同時發生大規模故障的機率。
容量分布工作負載分散在獨立故障域中，因此某一個可用區失效時，只會影響部分容量。

當你將多個虛擬機器或容器分布到不同可用區時，通常可以獲得更高等級的上線率 SLA。區域備援架構能夠幫助你的服務抵禦本地故障、極端天氣事件或資料中心故障。Kubernetes 可以幫助你更輕鬆地管理跨可用區叢集。你可以藉助 Kubernetes 在不同可用區之間排程 Pod、平衡工作負載並自動執行故障轉移。這種方式有助於打造更具韌性的叢集架構，確保應用程式持續上線。

容錯策略

容錯意味著即使部分元件失效，叢集也能夠繼續運作。你需要為不同故障情境提前做好規劃，並確保復原步驟清晰、簡潔且可執行。要打造穩健的高可用設計，請遵循以下最佳實務：

  1. 盤點所有關鍵服務及其相依關係。
  2. 根據對業務的影響程度，對可能的故障情境進行排序。
  3. 優先對最高風險區域實施控制措施。
  4. 透過故障模擬或在計畫性維護期間測試故障轉移。
  5. 持續監控叢集，並根據真實執行情況調整閾值。
  6. 用簡潔明瞭的語言為值班團隊記錄復原步驟。

定期測試至關重要。透過模擬故障，你可以提前發現叢集中的薄弱環節，並在它們引發真實事故之前完成修復。Kubernetes 可以自動完成許多這類任務。它能夠重新啟動失敗的 Pod、重新排程工作負載，並維持你設定的目標狀態。你還可以利用 Kubernetes 的健康檢查機制及早發現問題，並觸發自我修復動作。

高可用伺服器叢集離不開穩健的高可用策略、審慎的架構設計以及合適的工具。Kubernetes 為現代高可用叢集提供了所需的自動化與編排能力。當你將備援、多可用區部署與容錯策略結合起來時，就能建構出能夠持續支撐應用程式運作、提升使用者滿意度的叢集。

架構層與 Kubernetes 整合

高可用伺服器叢集依賴三大核心架構層。要建構穩健方案，你需要理解每一層如何發揮作用。下表列出了關鍵層級及其職責：

架構層說明
運算層高可用性透過將多台伺服器組成叢集來實現，這些伺服器共享工作負載並相互監控健康狀態。一旦某台伺服器失效，工作負載就會遷移到其他伺服器上，從而確保應用程式持續運作。
儲存層高可用性透過將資料分布到多個儲存節點來實現。即使某個儲存裝置發生故障，資料依然可以存取，這對應用程式效能至關重要。
網路層高可用性透過多條網路路徑實現，依賴備援交換器、防火牆、路由器和鏈路。當某條路徑失效時，流量可以重新路由，從而避免連線中斷。

運算層備援

你可以透過將多台伺服器組成叢集來實現運算層備援。這種方法允許你在多台伺服器之間共享工作負載並監控每台伺服器的健康狀態。如果某台伺服器失效，系統會自動將工作負載轉移到健康伺服器上，從而確保應用程式不中斷運作。為了獲得更好的韌性，你應當至少使用三個節點。

  • 將多台伺服器組成叢集
  • 在伺服器之間共享工作負載
  • 監控伺服器健康狀態
  • 啟用自動工作負載轉移

儲存層高可用

你必須保護好資料，才能確保應用程式持續可用。儲存層的高可用意味著你要將資料分布到不同的儲存節點上。這樣即使某個裝置故障，資料依然可以存取。像 SIOS DataKeeper 和 DxEnterprise 這樣的技術可以幫助你實現儲存備援管理。SIOS DataKeeper 無需共享儲存，並支援災難復原，但它更適合 Windows 環境。DxEnterprise 則支援跨平台叢集，也能很好地適配 kubernetes 叢集。它還提供面向 kubernetes 的原生編排能力，使管理更加容易。

技術優勢限制
SIOS DataKeeper無需共享儲存，支援災難復原主要面向 Windows，且需要額外的管理工作
DxEnterprise跨平台，原生支援 kubernetes對部分團隊來說，可能需要建立新的維運流程

網路層韌性

你需要確保網路層具備足夠的韌性，以防止因網路故障導致的停機。使用備援交換器、路由器與網路路徑，可以在某一路徑失效時自動改道流量。啟用 IPv4、IPv6 與鏈路層發現等特性，也有助於維持連線可靠性。下表列出了一些重要的網路設定：

網路特性設定
Microsoft 網路用戶端啟用
QoS 封包排程器可選
檔案與印表機共用啟用
IPv6啟用
IPv4啟用
鏈路層發現對應程式啟用
鏈路層發現回應程式啟用

Kubernetes 用於叢集編排

Kubernetes 為高可用與編排提供了強大的工具。你可以部署多個控制平面節點，並使用外部 etcd 資料庫來提升可靠性。Kubernetes 透過複寫與備援機制，確保即使部分元件失效，叢集仍能持續運作。例如，你可以在負載平衡器後部署多個 kube-apiserver 副本。這樣能夠分散 API 請求，避免單點故障。

Kubernetes 還可以透過 node ports、Ingress 與 LoadBalancer 服務來管理流量。這些功能能夠在整個部署中分發流量，並實現快速故障轉移。如果某個節點或 Pod 失效，kubernetes 會重新路由流量，確保應用程式持續上線。你可以依賴 kubernetes 自動執行復原，並維持目標狀態。這種方式能讓架構更加穩健，也更易於管理。

負載平衡與應用程式可用性

負載平衡器設定

為了讓高可用伺服器叢集平穩運作，你需要一個穩健的負載平衡器設定。負載平衡會將流量分散到多個節點上，避免單台伺服器被壓垮。這種方式既提高了資源利用效率，也支撐了你的高可用策略。你可以使用不同演算法來分配流量。下表列出了常見方法：

負載平衡方法說明
輪詢（Round Robin）依序將請求分發到各台伺服器。
最少連線（Least Connections）將新請求路由到目前活動工作階段最少的伺服器。
基於健康狀態的路由（Health-based Routing）自動將不健康目標移出服務池。

主動-主動叢集通常會使用專門的 loadbalancer 來分發流量。你可以根據架構需求選擇加權輪詢（Weighted Round Robin）或隨機（Random）等演算法。Kubernetes 支援這些方法，並能幫助你為應用程式自動實現負載平衡。

流量路由與工作階段管理

為了維持應用程式可用性，你必須有效率地進行流量路由。良好的工作階段管理能夠確保使用者資料安全，並帶來順暢體驗。下表說明了不同因素如何影響應用程式可用性：

面向對應用程式可用性的影響
工作階段管理在各項服務之間維持使用者狀態，提供平順體驗。
負載平衡防止瓶頸與單點故障。
容錯能力在故障期間保持工作階段不中斷，從而提升可靠性。
可擴充性允許你在擴充服務時仍然保持工作階段完整。
安全性保護工作階段資料，降低影響可用性的安全風險。

Kubernetes 的 Ingress 與 Service 物件可以幫助你管理流量路由與工作階段保持。你可以使用 Source IP Hash 演算法，讓使用者工作階段持續落在同一個節點上。這種方式有助於支撐高可用方案，並提升服務穩定性。

資料庫高可用

你需要一個高可用資料庫來保護資料，並讓應用程式維持上線。高可用資料儲存通常依賴叢集、複寫與自動故障轉移。下表列出了主要策略：

策略說明
故障轉移當某個節點失效時，將服務遷移到健康節點。
健康檢查監控系統健康狀態，以便快速偵測故障。
叢集使用多台伺服器，在節點故障時維持服務不中斷。
負載平衡分散請求，防止系統過載。
複寫在多個系統之間複製資料，以提升可用性。
消除單點故障透過備援設計，避免依賴單一元件。

你應當消除單點故障、快速偵測問題並實現自動故障轉移。還要定期測試高可用策略與復原路徑。Kubernetes Operator 可以幫助你管理有狀態工作負載與儲存，從而支撐高可用伺服器叢集。

監控、復原與災難規劃

健康檢查與監控

你必須持續監控高可用伺服器叢集，才能讓應用程式穩定運作。持續性的健康檢查可以幫助你快速發現故障。你應重點追蹤節點健康、應用程式回應、儲存延遲、CPU 壓力、記憶體使用、複寫延遲以及網路封包遺失情況。

以下是你應實作的關鍵健康檢查：

健康檢查項目說明
驗證叢集資源確保所有資源都按預期運作。
時間同步確認已設定 NTP，避免時鐘漂移。
執行叢集驗證使用工具檢查儲存、網路與設定是否正常。
監控服務故障關注服務崩潰等常見問題。
檢查 CSV、仲裁磁碟或見證磁碟檢查關鍵磁碟的執行狀態。
執行 chkdsk 並查看診斷資訊執行磁碟檢查並分析健康報告。
驗證憑證確保所有憑證有效且未過期。

自動故障轉移與自我修復

自動故障轉移與自我修復能力可以讓你的叢集更具韌性。你可以使用 kubernetes 來重新啟動失敗的 Pod，並重新排程工作負載。像 Netflix 這樣的公司會使用混沌工程，透過主動注入故障來驗證復原能力。Google 的系統能夠自動重新啟動失敗容器並回滾部署。AWS 則會在故障發生時將執行個體遷移到健康硬體上。這些策略可以幫助你在面對流量激增和意外停機時，無需人工介入也能維持服務穩定。

  • 藉助 kubernetes 重新啟動失敗的 Pod 與容器
  • 使用混沌工程工具測試復原能力
  • 使用自動擴縮容應對突發流量變化

備份與災難復原

你需要一套穩健的備份與災難復原方案來保護資料與服務。請遵循以下最佳實務：

最佳實務說明
備份頻率根據資料變化的頻率進行調整。
保留策略規劃同時滿足短期與長期的備份保留需求。
統一命名與歸檔為備份使用清楚的命名方式，避免復原時出錯。
3-2-1 原則保留三份資料副本，存放於兩種不同媒介上，並確保其中一份異地保存。
空氣隔離副本離線儲存一份備份，以防禦網路攻擊等安全威脅。
災難復原架構設計服務復原方案，包括故障轉移流程與資料相依關係。

常見的災難復原情境包括多站點叢集與主動-被動架構。多站點叢集會在不同地理位置部署一個次要站點，以便在主站點發生區域級故障時維持服務運作。主動-被動架構則允許你在需要時切換到備用系統。你應該經常測試備份復原流程，並明確設定復原時間目標與復原點目標。

高可用檢查清單

你可以使用下列清單來檢查你的高可用部署是否完善：

檢查項目說明
人員配置確保有足夠且受過訓練的人員來管理系統。
變更管理控制更新與修補程式發布，降低風險。
存取控制建立分級帳號權限，阻止未授權人員執行關鍵指令。
測試流程在預備生產環境中測試、執行備份，並定期演練災難復原。

你可以按照以下步驟設計高可用伺服器叢集：

  1. 在真正需要之前就先完成故障轉移測試。
  2. 以實現應用程式 99.99% 的上線率為目標。
  3. 讓架構設計與你的上線率目標保持一致。
  4. 消除單點故障。
  5. 使用可靠的故障轉移機制。

常見問題

高可用伺服器叢集的主要目標是什麼？

你的目標是在發生故障時，依然讓應用程式保持上線。其核心目標就是盡可能減少停機時間，並讓服務持續對使用者可用。

Kubernetes 如何幫助實現高可用？

Kubernetes 能自動執行故障轉移與工作負載分配。你可以利用它來重新啟動失敗的 Pod、重新排程工作負載，並維持期望狀態。

備援與容錯有什麼差別？

備援容錯
備用系統在元件失效時進行替換接手。即使發生故障，系統仍能持續運作。

災難復原計畫應該多久測試一次？

你應至少每半年測試一次災難復原計畫。定期測試能夠幫助你發現薄弱環節，並持續優化應變流程。