在 Compute Engine 中使用浮動 IP 位址的模式

本文說明將應用程式從內部部署網路環境遷移至 Compute Engine 時，如何使用浮動 IP 位址實作模式。本文適用於將應用程式遷移至Google Cloud的網路工程師、系統管理員和作業工程師。

浮動 IP 位址也稱為共用或虛擬 IP 位址，通常用於提升內部部署網路環境的可用性。在多個具有相同設定的實體或虛擬伺服器之間，您可以使用浮動 IP 位址來傳遞 IP 位址。這項做法可進行容錯移轉，或升級生產軟體。不過，如要直接在 Compute Engine 環境中導入浮動 IP 位址，就必須將架構變更為本文件所述的其中一種模式。

本文隨附的 GitHub 存放區包含各模式的部署範例，您可以使用 Terraform 自動部署。

內部部署環境中的浮動 IP 位址

浮動 IP 位址常用於內部部署環境中。使用案例範例如下：

要在內部部署環境中採用浮動 IP 位址的方法有好幾種，共用浮動 IP 位址的伺服器通常也會透過活動訊號機制分享狀態資訊。這種機制能讓伺服器針對各自的健康狀態進行通訊，並可在主要伺服器故障時，讓次要伺服器接手管理浮動 IP 位址。這種配置通常是利用虛擬路由器備援通訊協定來實作的，但您也可以使用其他類似的機制來進行。

當 IP 位址容錯移轉啟動之後，接管浮動 IP 位址的伺服器就會將該位址加入自己的網路介面。伺服器會藉由傳送無償位址解析通訊協定 (ARP) 訊框，向使用第 2 層的其他裝置公告這項接管事宜。或者，有時會透過開放式最短路徑優先 (OSPF) 等轉送通訊協定，向上游第 3 層的路由器公告 IP 位址。

下圖說明內部部署環境的一般設定。

典型的內部部署環境。

上圖顯示主要伺服器和次要伺服器如何透過心跳機制，交換連線至相同交換器的回應資訊。如果主要伺服器發生故障，次要伺服器會將無償 ARP 訊框傳送至交換器，接管浮動 IP 位址。

您使用的設定會因不同的內部部署負載平衡解決方案而稍有調整，例如 Windows 網路負載平衡或 Linux 負載平衡會採用 IPVS 等伺服器直接回應。在這些情況下，服務也會送出無償 ARP 訊框，但會使用另一個伺服器的 MAC 位址做為無償 ARP 來源。這項動作實質上是假冒 ARP 訊框，並接管另一部伺服器的來源 IP 位址。

這項動作是為了在不同伺服器之間分配一個 IP 位址的負載。不過，這類設定不在本文的討論範圍。在幾乎所有情況下，如果浮動 IP 位址用於內部部署負載平衡，建議遷移至 Cloud Load Balancing。

將浮動 IP 位址遷移至 Compute Engine 的挑戰

Compute Engine 在虛擬私有雲 (VPC) 網路中使用虛擬化的網路堆疊，因此一般的實作機制無法運作，必須變更Google Cloud。舉例來說，VPC 網路會在軟體定義網路中處理 ARP 要求，並忽略無償 ARP 訊框。此外，您無法透過 OSPF 或邊界閘道通訊協定 (BGP) 等標準轉送通訊協定，直接修改 VPC 網路路由表。浮動 IP 位址的典型機制是仰賴交換基礎架構處理 ARP 要求，或是仰賴可透過 OSPF 或 BGP 程式設計的網路。因此，IP 位址不會在Google Cloud中使用這些機制容錯移轉。如果您使用地端浮動 IP 位址遷移虛擬機器 (VM) 映像檔，則浮動 IP 位址無法在不變更應用程式的情況下容錯移轉。

您可以使用覆蓋網路建立設定，以便透過 ARP 要求啟用完整的第 2 層通訊和 IP 接管功能。不過，設定覆蓋網路的程序很複雜，還會讓 Compute Engine 網路資源難以管理。而且，那種方法也超出了本文的討論範圍，本文將說明如何在 Compute Engine 網路環境中導入容錯移轉機制，而不需建立疊加網路。

如要在 Compute Engine 中實作高可用性且穩定的應用程式，請使用水平資源調度架構。這類架構可將單一節點故障的影響降至最低。

本文說明多種模式，可將現有應用程式從內部部署環境遷移至 Compute Engine，並使用浮動 IP 位址，包括：

不建議使用在 VM 執行個體之間移動的別名 IP 位址做為容錯移轉機制，因為這不符合高可用性需求。在某些故障情況下 (例如區域故障事件)，您可能無法從執行個體移除別名 IP 位址。因此，您可能無法將其新增至其他執行個體，導致無法進行容錯移轉。

選取適合您用途的模式

視需求而定，您可能需要採用本解決方案中說明的一或多個模式，在內部部署環境中實作浮動 IP 位址。

決定最適合使用應用程式的模式時，請考量下列因素：

  • 浮動內部或外部 IP 位址：大多數需要浮動 IP 位址的應用程式，都會使用浮動內部 IP 位址。很少有應用程式會使用浮動外部 IP 位址，因為通常外部應用程式的流量應進行負載平衡。

    本節稍後的表格會建議您用於浮動內部 IP 位址和浮動外部 IP 位址的模式。如果您的用途需要浮動內部 IP 位址，這些模式可能都適用。不過，建議您將依賴浮動外部 IP 位址的使用案例，遷移至使用負載平衡的模式。

  • 應用程式通訊協定：如果 VM 只使用 TCP 和 UDP，您可以使用表格中的所有模式。如果使用 IPv4 以外的通訊協定連線，則只適用部分模式。

  • 主動-主動部署相容性：部分應用程式在內部部署環境中使用浮動 IP 位址時，可以主動-主動部署模式運作。這表示他們不一定需要從主要伺服器容錯移轉至次要伺服器。您有更多模式可選擇，將這類應用程式遷移至 Compute Engine。如果應用程式隨時只需要單一應用程式伺服器接收流量，就不適合採用雙主動部署。您只能使用下表中的部分模式實作這些應用程式。

  • 主要 VM 復原後的容錯回復行為：容錯移轉後，如果原始主要 VM 復原，流量會根據所用模式執行下列其中一項操作。系統會立即移回原始主要 VM，或留在新的主要 VM，直到手動啟動容錯回復或新的主要 VM 發生故障為止。在所有情況下，只有新建立的連線會回復。現有連線會保留在新主要 VM，直到連線關閉為止。

  • 健康狀態檢查相容性：如果您無法輕鬆使用 Compute Engine 健康狀態檢查，檢查應用程式是否回應，就無法使用下表所述的部分模式。

  • 執行個體群組：任何與健康狀態檢查相容的模式，也與執行個體群組相容。如要自動重建故障的執行個體，可以使用具備自動修復功能的代管執行個體群組。如果 VM 會保留狀態，可以使用具狀態的代管執行個體群組。如果 VM 無法自動重建，或您需要手動容錯移轉，請使用非代管執行個體群組，並在容錯移轉期間手動重建 VM。

  • 現有的心跳機制：如果應用程式的高可用性設定已使用心跳機制觸發容錯移轉 (例如 Heartbeat、Pacemaker 或 Keepalived)，則可使用下表所述的某些模式。

下表列出模式功能。以下各節將說明每種模式：

模式名稱 IP 位址 支援的通訊協定 部署模式 Failback 必須相容於應用程式健康檢查 可整合心跳機制
使用負載平衡的模式
主動-主動負載平衡 內部或外部 僅限 TCP/UDP 主動-主動 不適用 是 否
負載平衡 (含容錯移轉和應用程式公開健康狀態檢查) 內部或外部 僅限 TCP/UDP 主動/被動 立即 (現有連線除外) 是 否
透過容錯移轉和心跳公開健康狀態檢查進行負載平衡 內部或外部 僅限 TCP/UDP 主動/被動 可自行設定 否 是
使用 Google Cloud 路徑的模式
使用 ECMP 路徑 內部 所有 IP 通訊協定 主動-主動 不適用 是 否
使用優先順序不同的路徑 內部 所有 IP 通訊協定 主動/被動 立即 (現有連線除外) 是 否
使用心跳機制切換路徑下一個躍點 內部 所有 IP 通訊協定 主動/被動 可自行設定 否 是
使用自動修復的模式
使用自動修復單一執行個體 內部 所有 IP 通訊協定 不適用 不適用 是 否

決定要為您的用途採用哪種模式時，可能需要考量多項因素。下面的決策樹可幫助您縮小選擇範圍，找出合適的選項。

決策樹狀圖，可協助您選擇負載平衡器。

上圖概述下列步驟：

  1. 單一自動修復執行個體是否能提供足夠的可用性，滿足您的需求？
    1. 如果是，請參閱本文件稍後的「使用自動修復單一執行個體」一節。自動修復功能會使用 VM 執行個體群組中的機制，自動取代故障的 VM 執行個體。
    2. 如果不是，請繼續下一個決策點。
  2. 除了 TCP 和 UDP，您的應用程式是否需要 IPv4 頂層的通訊協定？
    1. 如果是，請繼續下一個決策點。
    2. 如果沒有，請繼續下一個決策點。
  3. 您的應用程式是否能在主動-主動模式下運作？
    1. 如果是，且需要使用 TCP 和 UDP 以外的 IPv4 頂端通訊協定，請參閱本文稍後的「使用等價多路徑 (ECMP) 路徑」。ECMP 路徑會將流量分配到所有候選路徑的下一個躍點。
    2. 如果是，且不需要 TCP 和 UDP 以外的 IPv4 頂端通訊協定，請參閱本文稍後的「作用中-作用中負載平衡」。主動-主動負載平衡會將 VM 當做內部 TCP/UDP 負載平衡器的後端。
    3. 如果不是，請繼續下一個決策點。
  4. 您的應用程式是否可以公開 Google Cloud 健康狀態檢查？
    1. 如果是，且不需要 TCP 和 UDP 以外的 IPv4 頂端通訊協定，請參閱本文稍後的「使用容錯移轉和應用程式公開健康狀態檢查進行負載平衡」。使用容錯移轉和應用程式公開健康狀態檢查進行負載平衡時，VM 會做為內部 TCP/UDP 負載平衡器的後端。並使用內部 TCP/UDP 負載平衡 IP 位址做為虛擬 IP 位址。
    2. 如果是，且需要使用 TCP 和 UDP 以外的 IPv4 頂端通訊協定，請參閱本文稍後的「使用不同優先順序的路徑」。使用優先順序不同的路徑，可確保流量一律會流向主要執行個體，除非該執行個體發生故障。
    3. 如果不需要，但需要 TCP 和 UDP 以外的 IPv4 頂端通訊協定，請參閱本文稍後的「使用容錯移轉和公開心跳健康狀態檢查進行負載平衡」。在負載平衡與容錯移轉和心跳公開健康狀態檢查模式中，健康狀態檢查並非由應用程式本身公開，而是由在兩個 VM 之間執行的心跳機制公開。
    4. 如果不需要 TCP 和 UDP 以外的 IPv4 頂端通訊協定，請參閱本文稍後的「使用心跳機制切換路徑的下一個躍點」。使用心跳機制切換路徑的下一個躍點時，會使用單一靜態路徑，下一個躍點指向主要 VM 執行個體。

使用負載平衡的模式

通常，您可以使用浮動 IP 位址，將應用程式遷移至使用 Cloud Load Balancing 的 Google Cloud 架構。您可以採用內部直通式網路負載平衡器，因為這個選項最適合僅在內部公開的遷移後地端服務。本節和 GitHub 範例部署中的所有範例，都會使用這個負載平衡選項。如有用戶端從其他區域存取浮動 IP 位址，請選取全域存取權選項。

如果您的應用程式使用 IPv4 上的通訊協定 (TCP 或 UDP 除外) 進行通訊，則必須選擇不使用負載平衡的模式。本文稍後會說明這些模式。

如果應用程式使用 HTTP(S)，您可以透過內部應用程式負載平衡器實作主動-主動模式。

如果您嘗試遷移的服務可供外部存取，則可使用外部直通式網路負載平衡器，實作本節討論的所有模式。如果是主動-主動部署作業，如果應用程式使用的通訊協定和通訊埠支援這些負載平衡選項，您也可以使用外部應用程式負載平衡器、TCP Proxy 或 SSL Proxy。

請注意，以內部部署浮動 IP 位址為基礎的實作方式，與所有以負載平衡為基礎的模式之間有下列差異：

  • 容錯移轉時間：在內部部署環境中，將 Keepalived 與無償 ARP 配對，可能會在幾秒內完成 IP 位址容錯移轉。在 Compute Engine 環境中，從容錯移轉到復原的平均時間取決於您設定的參數。如果虛擬機器 (VM) 執行個體或 VM 執行個體服務發生錯誤，則容錯移轉平均時間的流量會依據 Check Interval 和 Unhealthy Threshold 等健康狀態檢查參數而有不同。當這些參數設為預設值時，容錯移轉通常需要花 15 至 20 秒的時間。您可以減少這些參數值，縮短時間。

    在 Compute Engine 中，區域內或區域之間的容錯移轉所需的時間是相同的。

  • 通訊協定和通訊埠：在內部部署設定中，浮動 IP 位址會接受所有流量。在內部直通式網路負載平衡器的內部轉送規則中，選擇下列其中一種通訊埠規格：

    • 用數字指定至少一個 (最多五個) 通訊埠。
    • 指定 ALL 即可將 TCP 或 UDP 流量轉送至所有通訊埠。
    • 使用具有相同 IP 位址的多個轉送規則，轉送 TCP 和 UDP 流量的組合，或使用單一 IP 位址搭配超過五個通訊埠：
      • 僅限 TCP 或 UDP，且通訊埠數量為 1 至 5 個：使用一個轉送規則。
      • TCP 和 UDP，以及 1 到 5 個通訊埠：使用多個轉送規則。
      • 6 個以上的通訊埠，以及 TCP 或 UDP：使用多個轉送規則。

  • 健康狀態檢查：在內部部署環境中，您可以透過下列方式檢查機器上的應用程式回應：

主動-主動負載平衡

在「作用中-作用中」負載平衡模式中，VM 是內部直通式網路負載平衡器的後端。您可以使用內部直通式網路負載平衡器 IP 位址做為虛擬 IP 位址。流量會平均分配到兩個後端執行個體。屬於相同工作階段的流量會前往工作階段相依性設定中定義的後端執行個體。

如果應用程式只使用以 TCP 和 UDP 為基礎的通訊協定，且不需要在機器之間進行容錯移轉，請使用「主動-主動」負載平衡模式。如果應用程式可根據要求內容本身回答要求，請在這種情境中使用模式。如果機器狀態並非持續同步，請勿使用此模式，例如在主要或次要資料庫中。

下圖顯示主動-主動負載平衡模式的實作方式：

內部用戶端如何瀏覽主動-主動負載平衡模式。

上圖顯示內部用戶端如何透過內部直通式網路負載平衡器，存取在兩部 VM 上執行的服務。兩個 VM 都屬於執行個體群組。

主動-主動負載平衡模式需要服務使用其中一種支援的健康狀態檢查通訊協定公開健康狀態檢查，確保只有回應的 VM 會接收流量。

如需這個模式的完整範例實作，請參閱 GitHub 上的 Terraform 部署範例。

負載平衡 (含容錯移轉和應用程式公開健康狀態檢查)

與作用中-作用中模式類似，透過容錯移轉和應用程式公開健康狀態檢查模式進行負載平衡時，會將 VM 做為內部直通式網路負載平衡器的後端。此外，它也會使用內部直通網路負載平衡器 IP 位址做為虛擬 IP 位址。為確保一次只有一個 VM 接收流量，這個模式會套用內部直通式網路負載平衡器的容錯移轉。

如果您的應用程式只有 TCP 或 UDP 流量，但不支援主動-主動部署，建議採用這種模式。套用這個模式後，所有流量都會流向主要 VM 或容錯移轉 VM。

下圖顯示負載平衡的實作方式，包括容錯移轉和應用程式公開的健康狀態檢查模式：

內部用戶端如何瀏覽內部直通式網路負載平衡器後方的服務。

上圖顯示內部用戶端如何存取內部直通式網路負載平衡器後方的服務。兩個 VM 位於不同的執行個體群組。一個執行個體群組設為主要後端。另一個執行個體群組則設為內部直通式網路負載平衡器的容錯移轉後端。

如果主要 VM 上的服務停止回應，流量就會切換至容錯移轉執行個體群組。主要 VM 恢復回應後，流量會自動切換回主要後端服務。

如需這個模式的完整範例實作，請參閱 GitHub 上的 Terraform 部署範例。

透過容錯移轉和心跳公開健康狀態檢查進行負載平衡

具有容錯移轉和心跳公開健康狀態檢查的負載平衡模式，與先前的模式相同。不同之處在於，健康狀態檢查並非由應用程式本身公開，而是由兩個 VM 之間執行的心跳機制公開。

下圖顯示負載平衡的實作方式，以及容錯移轉和心跳公開健康狀態檢查模式：

內部用戶端如何存取內部負載平衡器後方的服務，其中有兩個 VM 分別位於不同的執行個體群組。

這張圖表顯示內部用戶端如何存取內部負載平衡器後方的服務。兩個 VM 位於不同的執行個體群組。其中一個執行個體群組設為主要後端。另一個執行個體群組則設為內部直通式網路負載平衡器的容錯移轉後端。Keepalived 可做為 VM 節點間的心跳機制。

VM 節點會使用所選的心跳機制，交換服務狀態資訊。每個 VM 節點都會檢查自身狀態，並將該狀態傳達給遠端節點。系統會根據本機節點的狀態和遠端節點收到的狀態，選出一個主要節點和一個備份節點。您可以使用這項狀態資訊公開健康狀態檢查結果，確保心跳機制中視為「主要」的節點，也會接收來自內部直通式網路負載平衡器的流量。

舉例來說，您可以使用 Keepalived 叫用指令碼，方法是透過 notify_master、notify_backup 和 notify_fault 設定變數變更健康狀態檢查狀態。轉換為「主要」狀態 (在 Keepalived 中，這個狀態稱為 master) 時，您可以啟動監聽自訂 TCP 通訊埠的應用程式。轉換為備份或錯誤狀態時，您可以停止這個應用程式。健康狀態檢查接著可以成為 TCP 健康狀態檢查，如果這個自訂 TCP 通訊埠已開啟，檢查就會成功。

這個模式比使用容錯移轉和應用程式公開健康狀態檢查的模式更複雜。但可讓您進一步控管。舉例來說，您可以設定立即或手動回復，做為心跳機制實作的一部分。

如需使用 Keepalived 的這個模式完整實作範例，請參閱 GitHub 上的 Terraform 部署範例。

使用 Google Cloud 路徑的模式

如果應用程式在 IPv4 頂端使用 TCP 或 UDP 以外的通訊協定，您可以將浮動 IP 位址遷移至以路徑為準的模式。

本節中提及的路徑一律是指虛擬私有雲網路的一部分Google Cloud 路徑。凡是提及靜態路徑，一律是指 Google Cloud上的靜態路徑。

使用其中一種模式，為特定 IP 位址設定多個靜態路徑，並將不同執行個體設為下一個躍點。這個 IP 位址會成為所有用戶端使用的浮動 IP 位址。因為靜態路徑無法覆寫現有子網路路徑，所以必須位於所有虛擬私有雲子網路 IP 位址範圍之外。您必須在目標執行個體上啟用 IP 位址轉送功能。啟用 IP 位址轉送功能後，您就能接受未指派給執行個體的 IP 位址流量 (在本例中為浮動 IP 位址)。

如要讓對等互連的虛擬私有雲網路使用浮動 IP 位址路徑，請匯出自訂路徑，將浮動 IP 位址路徑傳播至所有對等互連的虛擬私有雲網路。

如要從透過 Cloud Interconnect 或 Cloud VPN 連線的內部部署網路建立連線，您需要使用自訂 IP 位址路徑通告，在內部部署通告浮動 IP 位址。

相較於以負載平衡為基礎的模式，以路徑為基礎的模式具有下列優點：

  • 通訊協定和通訊埠：路徑型模式適用於傳送至特定目的地的所有流量。以負載平衡為準的模式僅允許 TCP 和 UDP 流量。

相較於以負載平衡為基礎的模式，以路徑為基礎的模式有下列缺點：

  • 健康狀態檢查：健康狀態檢查無法附加至Google Cloud 路徑。無論基礎 VM 服務的健康狀態為何，系統都會採用路徑。只要 VM 正在執行，即使服務健康狀態不良，路徑仍會將流量導向執行個體。將自動修復政策附加至這些執行個體，即可在您指定的不良時間間隔後，取代這些執行個體。不過，這些執行個體重新啟動後，流量會立即恢復，即使服務尚未啟動也一樣。如果狀況不佳的執行個體仍在處理流量或重新啟動，就可能導致服務錯誤。
  • 容錯移轉時間：刪除或停止 VM 執行個體後，Compute Engine 會忽略指向該執行個體的任何靜態路徑。不過，由於路徑沒有健康狀態檢查，只要執行個體仍可供使用，Compute Engine 就會繼續使用靜態路徑。此外，停止執行個體需要一些時間，因此容錯移轉花費的時間會遠比負載平衡模式還長。
  • 僅限內部浮動 IP 位址：雖然您可以使用外部直通式網路負載平衡器實作模式，建立外部浮動 IP 位址，但以路徑為準的模式僅適用於內部浮動 IP 位址。
  • 浮動 IP 位址選擇：您只能將路徑設定至不屬於任何子網路的內部浮動 IP 位址，子網路路徑無法在 Google Cloud中覆寫。請追蹤這些浮動 IP 位址，以免不小心將其指派給其他網路。
  • 路徑可連線性：如要讓內部浮動 IP 位址可從內部部署網路或對等互連網路連線，您需要如先前所述分配這些靜態路徑。

使用等價多路徑 (ECMP) 路由

等價多路徑 (ECMP) 路由模式與主動-主動負載平衡模式類似，流量會平均分配到兩個後端執行個體。使用靜態路徑時，ECMP 會使用相依性的五項雜湊碼，將流量分配到所有候選路徑的下一個躍點。

如要實作這個模式，請建立兩個優先順序相同的靜態路徑，並將 Compute Engine 執行個體做為下一個躍點。

下圖顯示 ECMP 路由模式的實作方式：

內部用戶端如何透過其中一條 ECMP 路徑存取服務。

上圖顯示內部用戶端如何透過其中一個路徑存取服務，下一個躍點指向實作服務的 VM 執行個體。

如果某個 VM 上的服務沒有回應，自動修復功能會嘗試重新建立沒有回應的執行個體。自動修復功能刪除執行個體後，指向該執行個體的路徑會失效，然後才會建立新執行個體。新執行個體建立完成後，系統會立即自動使用指向該執行個體的路徑，並在執行個體之間平均分配流量。

ECMP 路徑模式需要服務使用支援的通訊協定公開健康狀態檢查， 這樣自動修復功能才能自動替換沒有回應的 VM。

您可以在與本文相關聯的 GitHub 存放區中，找到使用 Terraform 實作這個模式的範例。

使用優先順序不同的路徑

優先順序不同的路徑模式與先前的模式類似，但會使用優先順序不同的靜態路徑，因此除非主要執行個體發生故障，否則流量一律會流向該執行個體。

如要實作這個模式，請按照 ECMP 路由模式中的相同步驟操作。 建立靜態路徑時，請為下一個躍點指向主要執行個體的路徑指定較低的優先順序值 (主要路徑)。為下一個中繼站指向次要執行個體的執行個體指派較高的優先順序值 (次要路徑)。

下圖顯示不同優先順序路徑模式的實作方式：內部用戶端存取服務時，如何根據網路狀況使用主要或次要路徑。

上圖顯示在一般情況下，存取服務的內部用戶端如何使用優先順序值為 500 的主要路徑，將 VM 1 指向下一個躍點。另一個優先順序值為 1,000 的路徑可用，指向 VM 2 (次要 VM) 做為下一個躍點。

如果主要 VM 上的服務沒有回應，自動修復功能會嘗試重新建立執行個體。自動修復功能刪除執行個體後，在建立新執行個體之前，以主要執行個體做為下一個躍點的主要路徑會失效。然後，模式會使用以次要執行個體做為下一個躍點的路徑。新的主要執行個體啟動後，主要路徑會再次啟用，所有流量都會流向主要執行個體。

與先前的模式相同，不同優先順序路徑模式也需要服務使用支援的通訊協定公開健康狀態檢查，這樣自動修復功能才能自動取代沒有回應的 VM。

您可以在本文件隨附的 GitHub 存放區中，找到使用 Terraform 實作這個模式的範例。

使用心跳機制切換路徑的下一個躍點

如果應用程式實作了心跳機制 (例如 Keepalived) 來監控應用程式回應，您可以套用該機制模式來變更靜態路由的下一個躍點。在此情況下，您只會使用單一路徑，下一個躍點指向主要 VM 執行個體。在容錯移轉時，心跳機制會將路徑的下一個躍點指向次要 VM。

下圖顯示心跳機制的實作方式，可切換路徑的下一個躍點模式：

內部用戶端如何存取服務，以及主要和次要 VM 交換心跳資訊的方式。

上圖顯示內部用戶端如何使用路徑存取服務，而下一個躍點指向主要 VM。主要 VM 會透過 Keepalived 與次要 VM 交換心跳資訊。在容錯移轉時，Keepalived 會呼叫 Cloud Run 函式，該函式會使用 API 呼叫，將下一個躍點指向次要 VM。

節點會使用所選的心跳機制，彼此交換服務狀態資訊。每個 VM 節點都會檢查自身狀態，並將狀態傳達給遠端 VM 節點。系統會根據本機 VM 節點的狀態和遠端節點收到的狀態，選出一個 VM 節點做為主要節點，另一個 VM 節點則做為備份節點。節點成為主要節點後，會將浮動 IP 位址的路徑下一個躍點指向自己。如果您使用 Keepalived，可以透過notify_master 設定變數 叫用指令碼，使用 API 呼叫或 Google Cloud CLI 取代靜態路由。

切換路徑下一個躍點模式的心跳機制，不需要 VM 屬於執行個體群組。如要讓系統在 VM 發生故障時自動更換，可以將 VM 放入自動修復執行個體群組。您也可以手動修復及重新建立無回應的 VM。

在容錯移轉時叫用下列程序，可確保容錯移轉時間縮到最短，因為流量會在步驟 1 中完成單一 API 呼叫後容錯移轉：

  1. 建立新的靜態路徑，將浮動 IP 位址設為目的地，並將新的主要執行個體設為下一個躍點。新路徑的名稱應與原始路徑不同，且路徑優先順序應較低 (例如 400)。
  2. 刪除舊主 VM 的原始路徑。
  3. 建立與剛刪除的路徑名稱和優先順序相同的路徑。將其指向新的主要 VM 做為下一個躍點。
  4. 刪除您建立的新靜態路徑。您不需要這個 IP，即可確保流量流向新的主要 VM。

由於原始路徑會遭到取代，因此即使有分割網路，一次也只能啟用一條路徑。

使用心跳機制切換路徑優先順序模式，而非其他路徑模式，可以縮短容錯移轉時間。您不必透過自動修復功能刪除及取代 VM，即可進行容錯移轉。此外，您也能更靈活地控制何時要還原為原始主要伺服器。

這個模式的缺點之一是您必須自行管理心跳機制。管理機制可能會導致作業更加複雜。另一個缺點是，您必須將變更全域路由表的權限授予執行心跳程序的 VM，或是心跳程序呼叫的無伺服器函式。將全域轉送表變更為無伺服器函式，可縮減授予 VM 的權限範圍，因此更加安全。不過，這種做法的實作難度較高。

如需使用 Keepalived 實作這個模式的完整範例，請參閱 GitHub 上的 Terraform 部署範例。

使用自動修復功能的模式

視復原時間需求而定，使用 Compute Engine 時，遷移至單一 VM 執行個體可能是可行的選項。即使您在內部部署環境中使用多部伺服器和浮動 IP 位址，這個選項仍為 true。儘管 VM 數量減少，有時仍可使用這種模式，是因為您可以在幾秒或幾分鐘內建立新的 Compute Engine 執行個體，而內部部署故障通常需要數小時甚至數日才能修復。

使用自動修復單一執行個體

使用這種模式時，您會依賴 VM 執行個體群組中的自動修復機制，自動更換故障的 VM 執行個體。應用程式會公開健康狀態檢查，如果應用程式健康狀態不良，自動修復功能會自動替換 VM。

下圖顯示自動修復單一執行個體模式的實作方式：

內部用戶端如何直接連線至 Compute Engine 執行個體。

上圖顯示內部用戶端如何直接連線至 Compute Engine 執行個體。該執行個體位於大小為 1 的代管執行個體群組中，且已啟用自動修復功能。

與使用負載平衡的模式相比，自動修復單一執行個體模式具有下列優點：

  • 流量分配：只有一個執行個體，因此該執行個體一律會接收所有流量。
  • 易於使用：由於只有一個執行個體，這個模式的實作最簡單。
  • 節省成本：不使用兩個 VM 執行個體，而改用單一執行個體，可降低一半的實作成本。

不過，這種模式有下列缺點：

  • 容錯移轉時間：這個程序的執行速度比以負載平衡為基礎的模式慢得多。當健康狀態檢查偵測到機器故障之後，系統至少得花一分鐘的時間才能刪除並重新建立故障的執行個體，但通常需要更久的時間。這種模式在正式環境中並不常見。不過，對某些內部或實驗性服務而言，容錯移轉時間可能已足夠
  • 區域故障的應對情形：大小為 1 的代管執行個體群組無法應對區域故障的情況。如要針對區域故障採取因應措施，請考慮加入服務失敗的 Cloud Monitoring 快訊，並於區域發生故障時在其他區域建立執行個體群組。由於您無法在這種情況下使用相同的 IP 位址，請使用 Cloud DNS 私人區域來處理 VM，並將 DNS 名稱切換至新的 IP 位址。

您可以在 GitHub 存放區中，找到使用 Terraform 實作這個模式的範例。

後續步驟