正如我們所討論的，在一個高可用性集群環境中有一個活動節點和一個或多個備用節點，當活動節點發生故障或停止響應時，它們將接管服務。

在考慮節點之間的網絡層之前，這聽起來像是一個合理的假設。 如果節點之間的網絡路徑出現故障怎麼辦？

任何一個節點現在都不能與另一個節點通信，在這種情況下，備用服務器可能會在它認為活動節點發生故障的基礎上將自己提升為活動服務器。 這導致兩個節點都變得“活躍”，因為每個節點都會認為另一個節點已經死了。 結果，數據完整性和一致性受到損害，因為兩個節點上的數據都會發生變化。 這被稱為“裂腦” .

為避免出現腦裂情況，應在集群中安裝 Quorum 節點（也稱為“見證”）。 添加仲裁節點（到由偶數個節點組成的集群）會創建奇數個節點（3、5、7 等），節點投票決定哪個應該充當集群中的活動節點。

在下面的示例中，包含節點 B 的服務器機架丟失了局域網連接性。 在這種情況下，通過在集群環境中添加第 3 個節點，系統仍然可以確定哪個節點應該是活動節點。

Quorum/Witness 功能包含在西歐保護套件。 安裝時，在所有節點（不僅是仲裁節點）上選擇 Quorum / Witness，並在所有節點（包括仲裁節點）之間定義通信路徑。

仲裁節點不託管任何活動服務。 它的唯一作用是參與節點通信，以確定哪些是活動的，並在通信中斷的情況下提供“平局投票”。

西歐也支持IO 防護和存儲作為仲裁設備，在這些配置中不需要額外的仲裁節點。

如前所述，一旦高可用性集群已配置，兩個或多個節點同時運行，用戶連接到“活動”節點. 當活動節點上出現問題時，會發生“故障轉移”情況，“備用”節點將成為新的“活動”節點。 當發生故障轉移時，必須有一種機制允許客戶端檢測故障轉移條件並重新連接，或者將用戶的活動客戶端會話無縫傳輸到活動節點。

虛擬 IP 地址

通常在配置集群並且客戶端與活動節點使用虛擬 IP 地址。 發生故障轉移時，虛擬 IP 地址會重新分配給新的活動節點，並且客戶端會重新連接到相同的虛擬 IP 地址。

例如，假設有兩個節點 A 和 B，其 IP 地址為10.20.1.10和10.20.2.10 . 在此示例中，我們將定義一個虛擬 IP 地址 10.20.0.10，應將其視為分配給當前活動節點。

這類似於為一個節點上的一個網絡接口卡分配第二個 IP 地址。 如果命令ipa在活動節點上輸入，兩個 IP 地址都將出現（如本 Linux 示例中的第 10 行和第 12 行）：

這ARP協議

當客戶端嘗試使用 IP 地址查找服務器時，客戶端通常使用ARP （地址解析協議）找到蘋果電腦（媒體訪問控制）目標機器的地址。

一旦客戶端廣播一條消息以找到目標 IP 地址，活動節點就會用它的蘋果電腦地址和客戶端解析請求並連接到它。

ARP雲環境的替代方案

但是，在雲環境中，無法使用以下方法識別活動節點ARP在虛擬環境中抽象了盡可能多的層。 可能需要基於在特定雲環境中使用的網絡基礎設施的替代方法。 通常有幾個選項，應從以下列表中進行選擇。

• AWS路由表場景

• AWS彈性IP場景

• AWS Route53 場景

• Azure 內部負載均衡器方案

• Google Cloud 內部負載均衡器方案