外部應用程式負載平衡器的容錯移轉

本頁說明外部應用程式負載平衡器的容錯移轉機制。容錯移轉設定包含兩個負載平衡器：主要負載平衡器和備份負載平衡器。就本次討論而言，「主要負載平衡器」是指您要設定容錯移轉的負載平衡器。備用負載平衡器：當主要負載平衡器開始無法通過健康狀態檢查時，備用負載平衡器會接收連線。

容錯移轉和容錯回復是自動程序，可將流量轉送至負載平衡器，以及從負載平衡器轉送流量。當 Cloud DNS 偵測到服務中斷，並將流量從主要負載平衡器路由至備份負載平衡器時，這個程序稱為容錯移轉。當 Cloud DNS 反向操作這個程序，並將流量重新導向至主要負載平衡器，這個過程就稱為容錯回復。

故障轉移的運作方式

如要為外部應用程式負載平衡器執行全域至區域的容錯移轉，請在您希望流量移轉的區域中，建立兩個以上的區域外部應用程式負載平衡器。只有區域性外部應用程式負載平衡器可以做為備份負載平衡器。區域性外部應用程式負載平衡器不僅獨立於個別Google Cloud 區域，也與在相同區域執行的任何全域外部應用程式負載平衡器或傳統版應用程式負載平衡器基礎架構隔離。

區域性外部應用程式負載平衡器最適合做為全域外部應用程式負載平衡器的容錯移轉負載平衡器，因為兩者都以 Envoy Proxy 為基礎，且處理流量的方式非常相似。這與流量處理方式有顯著差異的傳統版應用程式負載平衡器不同。

總而言之，系統支援下列容錯移轉情境：

  • 從全域外部應用程式負載平衡器遷移至區域性外部應用程式負載平衡器
  • 從區域性外部應用程式負載平衡器到區域性外部應用程式負載平衡器
  • 從傳統版應用程式負載平衡器遷移至區域性外部應用程式負載平衡器

容錯移轉和容錯回復工作流程

下列設定示範如何從全域外部應用程式負載平衡器容錯移轉至兩個區域外部應用程式負載平衡器，每個區域各有一個，而全域負載平衡器已在這些區域部署後端。

從全域外部應用程式負載平衡器容錯移轉至兩個區域性外部應用程式負載平衡器。
從全域外部應用程式負載平衡器容錯移轉至兩個區域外部應用程式負載平衡器 (按一下即可放大)。

以下各節說明一般工作流程，以及容錯移轉設定中涉及的不同元件。

  1. 偵測主要負載平衡器中的故障

    Google Cloud 會使用健康狀態檢查，偵測主要外部應用程式負載平衡器是否正常運作。您設定這些健康狀態檢查，從三個來源區域傳送探測。這三個來源區域必須代表用戶端存取負載平衡器的區域。舉例來說，如果您有全域外部應用程式負載平衡器，且大部分的用戶端流量來自北美和歐洲，您可以設定探測器，讓探測器來自北美兩個區域和歐洲一個區域。

    如果來自其中兩個以上區域的健康狀態檢查失敗，就會觸發容錯移轉至備用區域性外部應用程式負載平衡器。

    其他注意事項：

    • 建立健康狀態檢查時，必須指定剛好三個來源區域。只有全域健康狀態檢查可以指定來源區域。
    • 支援 HTTP、HTTPS 和 TCP 健康狀態檢查。
    • 健康狀態檢查探測器實際上是來自網際網路上的網路連接點 (PoP)，與設定的 Google Cloud來源區域距離不遠。

  2. 將流量轉送至備份負載平衡器

    如果主要負載平衡器開始無法通過健康狀態檢查， Google Cloud會使用 Cloud DNS 容錯移轉轉送政策，判斷如何將流量轉送至備用負載平衡器。

    中斷時間長度，或流量從主要負載平衡器容錯移轉至備份負載平衡器所需的時間，取決於 DNS TTL 值、健康狀態檢查間隔，以及健康狀態檢查的不良健康狀態判定門檻。如需建議設定，請參閱「最佳做法」。

  3. 回復至主要負載平衡器

    健康狀態檢查再次通過後，系統會自動回復使用主要負載平衡器。由於備份和主要負載平衡器都會處理流量，因此預期在容錯回復期間不會發生停機。

  4. 定期測試容錯移轉

    建議您定期測試容錯移轉工作流程，確保營運持續計畫正常運作。請務必測試從主要負載平衡器到備份負載平衡器的流量是否會逐漸轉移，以及是否會立即轉移。確認容錯移轉功能正常運作後，請觸發容錯回復，確認流量是否如預期重新導向至主要負載平衡器。

設定容錯移轉

如要設定容錯移轉，請執行下列步驟：

  1. 檢查現有的主要負載平衡器設定，確認主要負載平衡器使用的功能 (例如安全性功能、流量管理和路徑功能，以及 CDN) 適用於備份區域外部應用程式負載平衡器。如果沒有類似功能，這個負載平衡器可能就不適合用於容錯移轉。
  2. 建立備份區域外部應用程式負載平衡器，並盡可能採用與主要負載平衡器相同的設定。
  3. 建立健康狀態檢查和 DNS 轉送政策，偵測中斷情形，並在容錯移轉期間將流量從主要負載平衡器轉送至備份負載平衡器。

查看主要負載平衡器設定

開始前，請先確認備份區域性外部應用程式負載平衡器支援目前主要負載平衡器使用的所有功能。

為避免流量中斷，請注意下列差異：

  • GKE 部署作業。GKE 使用者請注意，相較於使用 GKE Ingress 控制器部署的負載平衡器，使用 GKE Gateway 部署的負載平衡器與這項容錯移轉機制更相容。這是因為 GKE Gateway 支援設定全域和區域外部應用程式負載平衡器。不過，GKE Ingress 控制器僅支援傳統版應用程式負載平衡器。

    為獲得最佳效果，請使用 GKE Gateway 部署主要和備份負載平衡器。

  • Cloud CDN。區域性外部應用程式負載平衡器不支援 Cloud CDN。因此，如果發生故障，任何依賴 Cloud CDN 的作業也會受到影響。為提升備援能力，建議您設定第三方 CDN 解決方案，做為 Cloud CDN 的備援。

  • Cloud Armor。如果主要負載平衡器使用 Cloud Armor，請務必在設定備份區域外部應用程式負載平衡器時，也設定相同的 Cloud Armor 功能。Cloud Armor 在區域和全域範圍內提供的功能有所不同。詳情請參閱 Cloud Armor 說明文件中的下列章節：

  • SSL 憑證。如要為主要和備份負載平衡器使用通用安全資料傳輸層 (SSL) 憑證，請確認主要負載平衡器使用的安全資料傳輸層 (SSL) 憑證類型與備份區域外部應用程式負載平衡器相容。查看全域、區域和傳統版負載平衡器提供的 SSL 憑證差異。詳情請參閱以下各節：

  • 後端 bucket。區域性外部應用程式負載平衡器不支援將 Cloud Storage bucket 設為後端。使用後端值區的負載平衡器無法設定容錯移轉。

設定備份負載平衡器

備份負載平衡器是區域性外部應用程式負載平衡器，您可以在發生故障時，將流量重新導向至該區域。

設定備用負載平衡器時，請注意下列事項：

  • 您必須盡可能將備份區域外部應用程式負載平衡器的功能設定，與主要負載平衡器相似，這樣兩個部署作業處理流量的方式才會相同。

    • 全域外部應用程式負載平衡器。區域性外部應用程式負載平衡器支援的功能，與全域外部應用程式負載平衡器大致相同，只有少數例外。區域負載平衡器也支援與全域負載平衡器相同的進階流量管理功能，因此更容易在主要和備份負載平衡器之間實現等效性。

    • 傳統版應用程式負載平衡器。使用傳統版應用程式負載平衡器時，由於區域性外部應用程式負載平衡器是以 Envoy 為基礎的負載平衡器，處理流量的方式不同，因此較難在主要和備份負載平衡器之間實現功能對等。部署至正式環境前，請務必徹底測試容錯移轉和容錯回復。

    如要查看區域、全域和傳統版應用程式負載平衡器的具體功能，請參閱「負載平衡器功能比較」頁面。

    建議您使用 Terraform 等自動化架構，協助在主要和備份部署作業中，達成並維持負載平衡器設定的一致性。

  • 建議您在每個有後端的區域中，設定備份區域性外部應用程式負載平衡器。舉例來說，如果您從全域部署 (在五個區域中都有執行個體群組) 容錯移轉至備份區域負載平衡器 (僅在三個區域中)，則這三個區域的後端服務可能會過載，而其餘兩個區域的後端服務則會閒置。

    此外，我們建議您設定 Cloud DNS，在將容錯移轉流量從主要全域負載平衡器重新導向至這些備份區域負載平衡器時，使用加權循環配置政策。考量不同區域中後端執行個體群組的大小上限，為每個備份負載平衡器指派權重。

  • 區域性外部應用程式負載平衡器支援進階和標準網路服務級別。如果容錯移轉期間的延遲不是您主要考量的問題，建議您使用標準層級設定備份區域外部應用程式負載平衡器。使用標準級基礎架構可進一步隔離全域外部應用程式負載平衡器使用的進階級基礎架構。

  • 如要讓主要和備份負載平衡器使用相同的後端，請在後端所在的區域建立備份區域外部應用程式負載平衡器。如果已為後端執行個體群組啟用自動調度資源功能，您必須符合跨部署作業共用後端的規定。

  • 如有需要，請為區域性外部應用程式負載平衡器預留額外的 Envoy 代理程式，確保在發生容錯移轉事件時，額外流量不會中斷同一區域中的任何其他負載平衡器部署作業。詳情請參閱「保留額外的僅限 Proxy 子網路容量」。

如要瞭解如何設定區域性外部應用程式負載平衡器，請參閱「設定具有 VM 執行個體群組後端的區域性外部應用程式負載平衡器」。

預留額外的僅限 Proxy 子網路容量

區域和虛擬私有雲網路中的所有區域 Envoy 型負載平衡器，都會共用相同的 Envoy Proxy 集區。發生容錯移轉事件時，備份區域外部應用程式負載平衡器的 Proxy 使用量會增加，以處理來自主要負載平衡器的容錯移轉流量。為確保備份負載平衡器一律有可用容量，建議您檢查僅限 Proxy 的子網路大小。建議您計算預估的 Proxy 數量，以處理特定區域的流量，並視需要增加容量。這也有助於確保容錯移轉事件不會中斷相同區域和網路中的其他區域 Envoy 負載平衡器。

一般來說，區域性外部應用程式負載平衡器 Proxy 最多可管理：

  • 每秒 600 (HTTP) 或 150 (HTTPS) 個新連線
  • 3,000 個有效連線
  • 每秒 1,400 個要求

如果您使用 DNS 政策將流量分散到不同區域的多個備份負載平衡器，請務必在估算每個區域和網路的 Proxy 需求時，將這點納入考量。較大的 Proxy 專用子網路可讓系統在必要時，為負載平衡器Google Cloud 指派更多 Envoy Proxy。

您無法以擴展主要位址範圍的方式 (使用 expand-ip-range 指令) 擴展僅限 Proxy 的子網路。您必須建立符合需求的備份僅限 Proxy 子網路，然後將其升級為活動角色。

如要瞭解如何變更僅限 Proxy 子網路的大小，請參閱「變更僅限 Proxy 子網路的大小或位址範圍」。

在主要和備份負載平衡器之間共用後端

如要實現完整的基礎架構備援，您必須在負載平衡器和後端層級導入備援機制。也就是說，您必須設定備份區域外部應用程式負載平衡器，並使用與主要負載平衡器不重疊的後端 (執行個體群組或網路端點群組)。

不過，如果確實想在主要和次要負載平衡器之間共用後端執行個體群組，且已為執行個體群組啟用自動調度資源功能，則必須符合下列需求，確保系統能正確執行容錯移轉：

  • 自動調度器必須僅根據 CPU 設定調度資源。不支援負載平衡器的使用率調整方法。
  • 全域和區域後端服務都只能使用 UTILIZATION 平衡模式。不建議使用 RATE 平衡模式，因為在容錯移轉程序期間，執行個體可能會從全域和區域負載平衡器接收 2 倍的流量。
  • 您必須設定向內縮減控制項，防止自動調度器在流量從全域負載平衡器切換至區域負載平衡器時，於停機期間過早縮減群組。這段停機時間可能高達 DNS TTL 加上設定的健康狀態檢查間隔的總和。

如果未正確設定自動調度資源，容錯移轉期間可能會發生次要中斷，因為全域負載平衡器流量流失會導致執行個體群組快速縮減。

設定 Cloud DNS 和健康狀態檢查

本節說明如何使用 Cloud DNS 和Google Cloud 健康狀態檢查，設定 Cloud Load Balancing 環境，偵測中斷情形並將流量轉送至備份負載平衡器。

請按照下列步驟設定必要的健康狀態檢查和轉送政策：

  1. 為主要負載平衡器的轉送規則 IP 位址建立健康狀態檢查。

    gcloud compute health-checks create http HEALTH_CHECK_NAME \
    --global \
    --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
    --use-serving-port \
    --check-interval=HEALTH_CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --request-path=REQUEST_PATH

    更改下列內容：

    • HEALTH_CHECK_NAME：健康狀態檢查的名稱
    • SOURCE_REGION：執行健康狀態檢查的三個 Google Cloud區域。您必須指定剛好三個來源區域。
    • HEALTH_CHECK_INTERVAL：從某個探測系統發出一次探測作業開始，到同一系統發出下一次探測作業開始之間的時間長度 (以秒為單位)。支援的最小值為 30 秒。 如需建議值，請參閱「最佳做法」。
    • HEALTHY_THRESHOLD 和 UNHEALTHY_THRESHOLD：探測作業必須要連續成功或失敗多少次，才會讓系統認定該 VM 執行個體的健康狀態良好或不良。只要您省略其中一個標記， Google Cloud 就會採用 2 的預設判定門檻值。
    • REQUEST_PATH：Google Cloud 將健康狀態檢查探測要求傳送至此網址路徑。如果省略這個旗標， Google Cloud 會將探測要求傳送至根路徑「/」。如果接受健康狀態檢查的端點是私人端點 (這並非外部轉送規則 IP 位址的典型情況)，您可以將這個路徑設為 /afhealthz。

  2. 在 Cloud DNS 中建立 Cloud DNS 記錄集，並對其套用路由政策。您必須設定轉送政策，將網域名稱解析為主要負載平衡器的轉送規則 IP 位址，或在健康狀態檢查失敗時，解析為其中一個備份負載平衡器的轉送規則 IP 位址。

    gcloud dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type=FAILOVER \
    --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
    --health-check=HEALTH_CHECK_NAME \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO

    更改下列內容：

    • DNS_RECORD_SET_NAME：要新增的記錄集 DNS 或網域名稱，例如 test.example.com
    • TIME_TO_LIVE：記錄集的存留時間 (TTL)，以秒為單位。如需建議值，請參閱「最佳做法」。
    • RECORD_TYPE：記錄類型，例如 A
    • MANAGED_ZONE_NAME：要管理的記錄集所屬的代管區域名稱，例如 my-zone-name
    • PRIMARY_LOAD_BALANCER_FORWARDING_RULE：主要負載平衡器的轉送規則名稱
    • BACKUP_REGION：部署備份負載平衡器的區域
    • BACKUP_LOAD_BALANCER_IP_ADDRESS：與各區域對應的備份負載平衡器轉送規則 IP 位址
    • BACKUP_DATA_TRICKLE_RATIO：即使主要負載平衡器健康狀態良好，仍要傳送至備份負載平衡器的流量比率。比率必須介於 0 到 1 之間，例如 0.1。預設值為 0。

最佳做法

設定 Cloud DNS 記錄和健康狀態檢查時，請注意以下最佳做法：

  • 流量從主要負載平衡器容錯移轉至備份負載平衡器所需的時間 (即服務中斷時間)，取決於 DNS TTL 值、健康狀態檢查間隔，以及健康狀態檢查的不良健康狀態判定門檻參數。

    使用 Google Cloud DNS 時，這段期間的上限可透過下列公式計算：

    Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold

    如要設定容錯移轉，建議將 DNS TTL 設為 30 到 60 秒。TTL 較高會導致停機時間較長，因為即使 DNS 已容錯移轉至備份區域性外部應用程式負載平衡器，網際網路上的用戶端仍會繼續存取主要外部應用程式負載平衡器。

  • 在健康狀態檢查中設定良好和不良健康狀態判定門檻參數，避免因暫時性錯誤導致不必要的容錯移轉。門檻越高，流量容錯移轉至備份負載平衡器的時間就越長。

  • 為確保容錯移轉設定能正常運作，您可以設定 DNS 路由政策，即使主要負載平衡器運作正常，仍將一小部分流量傳送至備用負載平衡器。建立 DNS 記錄集時，可以使用 --backup-data-trickle-ratio 參數完成這項操作。

    您可以設定傳送至備份的流量比例，設定的值須為介於 0 到 1 之間的分數。一般值為 0.1，但 Cloud DNS 可讓您將所有流量傳送至備用 VIP 位址，手動觸發容錯移轉。