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

Last reviewed 2025-02-03 UTC

本文說明將應用程式從地端部署網路環境遷移至 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。舉例來說，虛擬私有雲網路會在軟體定義網路中處理 ARP 要求，並忽略無償 ARP 訊框。此外，您無法透過 OSPF 或邊界閘道通訊協定 (BGP) 等標準轉送通訊協定，直接修改虛擬私有雲網路路由表。浮動 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. 如果是，且需要使用 IPv4 以外的通訊協定 (TCP 和 UDP 除外)，請參閱本文稍後的「使用等價多路徑 (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 位址，將應用程式遷移至 Google Cloud 使用 Cloud Load Balancing 的架構。您可以選擇使用內部直通式網路負載平衡器，因為在大多數情況下，地端部署遷移的服務只會對內部公開。本節和 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 實作這個模式的範例。

後續步驟