本頁面由 Cloud Translation API 翻譯而成。

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

本頁說明外部應用程式負載平衡器的容錯移轉運作方式。容錯移轉設定包含兩個負載平衡器：主要負載平衡器和備份負載平衡器。在本文中，主要負載平衡器是指您要設定容錯移轉的負載平衡器。備用負載平衡器：主要負載平衡器開始無法通過健康狀態檢查時，備用負載平衡器會接收連線。

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

故障轉移的運作方式

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

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

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

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

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

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

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

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

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

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

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

其他注意事項：
- 建立健康狀態檢查時，必須指定剛好三個來源區域。只有全域健康狀態檢查可以指定來源區域。
- 支援 HTTP、HTTPS 和 TCP 健康狀態檢查。
- 健康狀態檢查探測器實際上是來自網際網路上的服務據點 (PoP)，與設定的 Google Cloud來源區域距離不遠。
將流量轉送至備份負載平衡器

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

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

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

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

設定容錯移轉

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

檢查現有的主要負載平衡器設定，確認備份地區外部應用程式負載平衡器支援主要負載平衡器使用的功能 (例如安全性功能、流量管理和轉送功能，以及 CDN)。如果沒有類似功能，這個負載平衡器可能就不適合用於容錯移轉。
建立備份區域性外部應用程式負載平衡器，並盡可能採用與主要負載平衡器相同的設定。
建立健康狀態檢查和 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 說明文件中的下列章節：
- 區域性 Cloud Armor 安全性政策
- 全域 Cloud Armor 安全性政策
SSL 憑證。如要為主要和備份負載平衡器使用通用安全資料傳輸層 (SSL) 憑證，請確認主要負載平衡器使用的安全資料傳輸層 (SSL) 憑證類型與備份區域外部應用程式負載平衡器相容。查看全域、區域和傳統版負載平衡器提供的 SSL 憑證差異。詳情請參閱以下各節：
- Compute Engine SSL 憑證
- 憑證管理工具 SSL 憑證
後端值區。區域性外部應用程式負載平衡器不支援將 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 平衡模式，因為在容錯移轉程序期間，執行個體可能會收到來自全域和區域負載平衡器的雙倍流量。
您必須設定向內縮減控制項，防止自動調度器在流量從全域負載平衡器切換至區域負載平衡器時，於停機期間過早縮減群組。這段停機時間可能高達 DNS TTL 加上設定的健康狀態檢查間隔的總和。

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

設定 Cloud DNS 和健康狀態檢查

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

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

為主要負載平衡器的轉送規則 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。
在 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 允許您將 100% 的流量傳送至備份 VIP 位址，手動觸發容錯移轉。

外部應用程式負載平衡器的容錯移轉 透過集合功能整理內容 你可以依據偏好儲存及分類內容。