當組織的計算機系統和應用程序由于計劃外停機而無法訪問時，聲譽損害可能與財務損失一樣嚴重。如果受影響的系統需要數小時才能重新上線，則尤其如此。為防止停機時間延長，您應該為您的 IT 基礎架構實施高可用性 (HA) 架構，使您能夠實現高達 99.999% 的正常運行時間并將服務中斷降至最低。本文更詳細地解釋了 HA 架構。

HA架構的定義

有些組織要求他們的系統 24/7 全天候運行。對于這些組織，HA 架構是必不可少的。雖然 HA 不保證系統不會受到計劃外中斷的影響，但它可以最大限度地減少此類中斷對您的操作的影響。響應速度更快的系統是 HA 的另一個好處。

HA 架構可確保您的系統啟動并運行，并且在面對不可預見的情況（如硬件和軟件故障）時可供用戶訪問。有了它，您可以使用多個組件來確保持續且響應迅速的服務。您必須確保這些組件相互補充，否則您只會為您的應用程序添加潛在的故障點，從而增加停機的可能性。

以下是 HA 架構必須具備的四個特征：

• 冗余硬件：缺乏冗余硬件意味著在服務器崩潰后重新啟動之前無法處理任何請求。發生這種情況時，停機是不可避免的。因此，您的 HA 架構必須包括備份硬件，例如在生產硬件崩潰時自動接管的服務器或服務器集群。
• 冗余軟件和應用程序：為防止在生產環境中使用的軟件和應用程序出現故障時出現潛在的停機時間，您的 HA 架構必須包含備份軟件和應用程序。
• 冗余數據：由于某種原因而離線的數據庫服務器可能會對您的生產環境造成嚴重破壞。您的 HA 架構應該包括備份數據庫服務器的規定，只要生產數據庫服務器脫機，就可以將處理轉移到這些服務器上。
• 無單點故障：單個組件的故障不應使整個基礎架構崩潰。通過硬件、軟件和數據的冗余，消除了單點故障。

對于不需要持續運行的組織，HA 可能不是必需的，尤其是因為它需要投資新的硬件和軟件，并且會增加您的維護和其他相關成本。在決定 HA 架構之前，請確保將與向基礎架構添加更多組件相關的成本考慮在內。如果您決定將 HA 集成到您的基礎架構中，那么選擇云而不是本地基礎架構可以幫助您的組織節省成本。確保回報值得您投入額外組件的投資。

如何獲得高可用性

理想的 HA 架構應包括確保冗余、數據備份和恢復、自動故障轉移和負載平衡的元素。

冗余

如上所述，冗余是 HA 的一個關鍵特征，盡管它會增加實現 HA 的成本。采用冗余時，您可以從五種模型中進行選擇，隨著需要更多組件，每種模型的成本都會逐漸增加。

• N+1 模型：這需要對基礎架構中的每個組件進行獨立備份。它可以是主動/被動的，這意味著備用組件處于待機狀態并準備好在主要組件出現故障時接管，也可以是主動/主動，這意味著備用組件與主要組件同時運行。盡管這是成本最低的模型，但它并非完全多余。因此，它可能并不完全適合大型系統。
• N+2 模型：這類似于 N+1 模型，但每個主要組件需要兩個備用組件。如果一個備份組件也發生故障，則另一個備份組件將接管。
• 2N 模型：這使運行系統所需的資源數量增加了一倍。例如，如果一個系統需要四臺服務器來運行，那么 2N 模型會向系統添加另外四臺服務器，從而使服務器總數為八臺。因此，即使多個組件出現故障，系統也始終具有運行能力。
• 2N+1 模型：這類似于 2N 模型，只是它添加了另一個備份組件，當額外容量出現停機問題時可以接管。
• 地理冗余：這是最昂貴的模型，因為它將系統分布在多個位置的服務器中。當一個位置出現故障時，另一個站點會接管，從而保持您的運營正常運行。鑒于其成本，如果您決定采用這種模式，那么與在全球擁有數據中心的云服務提供商簽約是您的最佳選擇。

數據備份與恢復

需要定期進行完整的數據備份以確保 HA，并且應該包含在您的災難恢復計劃中。確保定期測試您的數據備份，并確保它們可以立即恢復。此外，您應該通過將數據存儲在多個位置的輔助服務器或備用實例中來復制數據。這些位置中的數據應始終與您的主要位置中的數據同步。當災難襲擊您的主要位置時，其他位置應該準備好接管。

帶故障檢測的自動故障轉移

在發生故障的情況下，備份系統應準備好在稱為自動故障轉移的過程中立即接管。及時的故障檢測對于該系統的工作至關重要。

具有自動故障轉移的 HA 架構如下所示：

• 有一個主系統和一個稱為熱備用的備份系統。
• 在主系統和備用系統之間進行持續監控。
• 當主系統出現故障時，備用系統或熱備用系統會自動接管。新請求現在由備份系統處理，它現在就像主系統一樣。
• 當主系統中的問題得到解決后，它會重新上線并恢復其原來的角色。熱備用恢復為備份。

用戶在上述過程中不知道有任何變化。如果處理得當，故障轉移對他們來說是透明的。

負載均衡

HA 架構使用負載平衡確保更好和更可靠的應用程序性能，該過程涉及使用基于硬件或軟件的解決方案在多個服務器之間分配網絡流量。您應該配置負載均衡器以使用適合您要求的算法。常見的負載均衡算法包括：

• 循環：負載平衡器將傳入請求定向到第一臺服務器，然后是第二臺服務器，依此類推。
• 最少連接：負載均衡器找到連接數量最少的服務器，并將傳入流量定向到該服務器。
• 源 Internet 協議 (IP) 哈希：負載均衡器始終根據源的 IP 地址定向請求。這涉及尋找最接近傳入請求的服務器。

負載平衡本身并不能保證 HA，因為它仍然可能是單點故障。要解決此潛在問題，您應該為負載平衡解決方案實施冗余。

如何衡量高可用性

雖然經常互換使用，但可用性和正常運行時間彼此不同。雖然系統可以啟動并運行，但由于網絡問題等因素，用戶不一定可以使用它。此外，正常運行時間只是可用性的一個方面，而停機時間是另一個方面。

可用性是指系統在特定時期內工作的概率。以百分比表示，它是評估與托管解決方案的潛在供應商的服務水平協議 (SLA) 時要考慮的重要指標。

要計算可用性，請考慮以下因素：

• 年營業時間
• 待機時間
• 用于年度預防性維護的總時間
• 用于年度糾正性維護的總時間
• 等待行政和后勤延誤所花費的時間

可用性的理想度量被稱為五個 9或給定時間段內的 99.999% 可用性。這意味著一年中的停機時間略高于五分鐘。如果 24/7 運營對您的組織至關重要，那么您應該爭取 99.999% 的可用性。

高可用性集群的類型

服務器集群是支持 HA 架構的服務器組。使用專用網絡連接持續監控集群中每個節點的運行狀況。當一個節點宕機時，另一個節點接管它的操作。

在設計 HA 架構時，您可以從不同的集群類型中進行選擇，包括：

• 主動/被動集群：在這種集群類型中，有一個始終處于活動狀態的主節點，這意味著它處理來自用戶的所有請求。備份節點是被動的或非活動的，這意味著它無法處理傳入的請求。但是，當主節點出現故障時，被動節點會接管。當主節點的問題得到解決后，它會繼續處理所有請求，而備份節點會再次回到被動狀態。
• 主動/主動集群：在這種集群類型中，節點都是活動的，可以處理傳入的請求。當一個節點出現故障時，其他活動節點之一將接管。當另一個節點的問題得到解決時，請求會再次分發到集群內的所有節點。
• 無共享與共享磁盤集群：對于無共享集群，每個節點都有自己的數據庫，該數據庫與其他節點中的數據庫同步。因此，當一個節點出現故障時，其他節點仍然可以運行。因此，無共享集群對于實現 HA 至關重要。相比之下，共享磁盤集群的特點是所有節點共享一個數據庫，這意味著當數據庫宕機時，所有節點也會宕機。