本頁面由 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 Gateway 部署的負載平衡器與此備援機制相容性較高，而非使用 GKE Ingress 控制器部署的負載平衡器。這是因為 GKE Gateway 支援全域和區域外部應用程式負載平衡器的設定。不過，GKE Ingress 控制器僅支援傳統版應用程式負載平衡器。

為獲得最佳效果，請使用 GKE 閘道部署主要和備用負載平衡器。
Cloud CDN。區域性外部應用程式負載平衡器不支援 Cloud CDN。因此，在發生失敗時，任何仰賴 Cloud CDN 的作業都會受到影響。為提供更完善的備援機制，建議您設定可做為 Cloud CDN 備援的第三方 CDN 解決方案。
Google Cloud Armor。如果您將 Google Cloud Armor 用於主要負載平衡器，請務必在設定備用區域外部應用程式負載平衡器時，也設定相同的 Google Cloud Armor 功能。Google Cloud Armor 在區域和全球範圍內提供不同的功能。如需詳細資訊，請參閱 Google Cloud Armor 說明文件中的以下部分：
- 區域性 Google Cloud Armor 安全性政策
- 全球 Google Cloud Armor 安全性政策
SSL 憑證。如果您想在主要和備用負載平衡器上使用通用的安全資料傳輸層 (SSL) 憑證，請確認主要負載平衡器使用的安全資料傳輸層 (SSL) 憑證類型，與備用區域外部應用程式負載平衡器相容。查看全域、區域和傳統版負載平衡器可用的 SSL 憑證之間的差異。詳情請參閱以下各節：
- Compute Engine SSL 憑證
- 憑證管理工具 SSL 憑證
後端值區。區域性外部應用程式負載平衡器不支援使用 Cloud Storage 值區做為後端。您無法為使用後端值區的負載平衡器設定容錯移轉。

設定備用負載平衡器

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

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

您必須將備用區域性外部應用程式負載平衡器的功能設定為盡可能與主要負載平衡器相似，以便在兩個部署中以相同方式處理流量。
- 全域外部應用程式負載平衡器。區域性外部應用程式負載平衡器支援的功能與全域外部應用程式負載平衡器大致相同，但有幾項例外情況。區域性負載平衡器也支援與全域負載平衡器相同的進階流量管理功能，因此更容易在主要負載平衡器和備用負載平衡器之間達到相同的效果。
- 傳統版應用程式負載平衡器。使用傳統版應用程式負載平衡器時，主負載平衡器和備用負載平衡器之間的功能相容性較難達成，因為區域性外部應用程式負載平衡器是一種以 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 環境，以偵測停機情形並將流量路由至備用負載平衡器。

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

為主要負載平衡器的轉送規則 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 位址，以便手動觸發備援。

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