在 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中進行變更。舉例來說，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 中實作可用性高且穩定的應用程式，請使用水平資源調度架構。這種架構可盡量減少單一節點故障的影響。

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

我們不建議使用在 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 位址 支援的通訊協定 部署模式 備用 應用程式健康檢查相容性要求 可整合心跳機制
使用負載平衡的模式
主動-主動負載平衡 內部或外部 僅限 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. 如果是，且不需要在 IPv4 上使用 TCP 和 UDP 以外的通訊協定，請參閱本文件後續的主動-主動負載平衡。主動-主動負載平衡會將 VM 用作內部 TCP/UDP 負載平衡器的後端。
    3. 如果不是，請繼續進行下一個決策點。
  4. 您的應用程式可以公開 Google Cloud 健康檢查嗎？
    1. 如果是，且需要在 IPv4 上使用 TCP 和 UDP 以外的通訊協定，請參閱本文後面的負載平衡與容錯移轉以及應用程式公開的健康狀態檢查。內含容錯移轉功能和應用程式公開的健康狀態檢查的負載平衡功能，會將 VM 用作內部 TCP/UDP 負載平衡器的後端。它也會使用內部 TCP/UDP 負載平衡 IP 位址做為虛擬 IP 位址。
    2. 如果是，且不需要在 IPv4 上使用 TCP 和 UDP 以外的通訊協定，請參閱本文後續的使用不同的優先順序路徑。使用優先順序不同的路徑有助於確保流量一律會流向主要執行個體，除非該執行個體發生故障。
    3. 如果不是，且需要在 IPv4 上使用 TCP 和 UDP 以外的通訊協定，請參閱本文後面的使用容錯和心跳公開健康狀態檢查的負載平衡。在具備容錯功能的負載平衡和心跳檢查模式中，健康狀態檢查並非由應用程式本身提供，而是由兩個 VM 之間執行的心跳機制提供。
    4. 如果沒有，且不需要在 IPv4 上使用 TCP 和 UDP 以外的通訊協定，請參閱本文後續的使用心跳機制切換路徑的下一個躍點。使用心跳機制切換路徑的下一個躍點時，會使用單一靜態路徑，並將下一個躍點指向主要 VM 執行個體。

使用負載平衡的模式

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

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

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

如果您嘗試遷移的服務可供外部存取，則可使用外部直通式網路負載平衡器，實作本節所述的所有模式。如果應用程式使用這些負載平衡選項支援的通訊協定和通訊埠，您也可以為主動-主動部署使用外部 Application Load Balancer、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 節點都會檢查自身的狀態，並將該狀態傳達至遠端節點。系統會根據本機節點的狀態和遠端節點收到的狀態，選出一個節點做為主要節點，另一個節點做為備用節點。您可以使用這項狀態資訊公開健康狀態檢查結果，確保在心跳機制中視為「primary」的節點也能接收來自內部轉送網路負載平衡器的流量。

舉例來說，您可以使用 Keepalived 搭配 notify_master、notify_backup 和 notify_fault 設定變數，藉此變更健康狀態檢查狀態。轉換至「primary」狀態 (在 Keepalived 中，這個狀態稱為 master) 後，您可以啟動監聽自訂 TCP 通訊埠的應用程式。轉換至備援或故障狀態時，您可以停止此應用程式。接著，如果這個自訂 TCP 通訊埠已開啟，健康狀態檢查可以是成功的 TCP 健康狀態檢查。

這個模式比使用應用程式公開的健康狀態檢查進行復原的模式更為複雜。不過，這麼做可以讓您進一步控管。舉例來說，您可以將其設為立即或手動回復，做為心跳機制實作的一環。

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

使用 Google Cloud 路徑的模式

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

在本節中，提及路徑一律是指屬於 VPC 網路的 Google Cloud 路徑。靜態路徑的參照項目一律會是 Google Cloud上的靜態路徑。

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

如果您希望浮動 IP 位址路由可從對等互連的 VPC 網路取得，請匯出自訂路徑，讓浮動 IP 位址路由傳播至所有對等互連的 VPC 網路。

如要透過 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 的主要路徑，並將 VM1 設為下一個躍點。優先順序值為 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. 刪除您建立的新靜態路徑。您不需要這麼做，系統會確保流量流向新的主 VM。

由於原始路線已遭取代，因此即使有分割網路，也只能同時啟用一個路線。

使用心跳機制切換路徑優先順序模式，而非其他路徑模式，可以縮短容錯時間。您不必透過自動修復功能刪除及取代 VM，以便進行容錯。您也可以透過這項功能，進一步控制何時要將服務切換回原始的主要伺服器 (在該伺服器恢復回應後)。

此模式的缺點之一，就是您必須自行管理心跳機制。管理機制可能會導致更複雜的情況。另一個缺點是，您必須將全域轉送表的變更權限授予執行心跳程序的 VM，或是從心跳程序呼叫的無伺服器函式。將全域轉送表改為無伺服器函式可提升安全性，因為這樣可縮小授予 VM 的權限範圍。不過，這種做法實作起來較為複雜。

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

使用自動修復功能的模式

視復原時間需求而定，使用單一 VM 執行個體遷移至 Compute Engine 可能是可行的選項。即使內部部署使用多個使用浮動 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 實作此模式的範例。

後續步驟