區域性外部應用程式負載平衡器的高可用性

本頁面說明如何使用區域性外部應用程式負載平衡器，設定高可用性部署作業。如要達到高可用性，請在最能支援應用程式流量的區域中，部署多個個別的區域性外部應用程式負載平衡器。這是因為不同區域的區域性外部應用程式負載平衡器不僅彼此隔離，也與在相同區域執行的任何全域外部應用程式負載平衡器或傳統版應用程式負載平衡器基礎架構隔離。

使用 Cloud DNS 地理位置轉送政策，將流量轉送至不同區域的兩個以上負載平衡器。這項政策會根據用戶端要求的來源，將流量轉送至最接近的可用區域。此外，我們也建議您使用健康狀態檢查，以便 Google Cloud 偵測任何區域性中斷，並只將流量轉送至健康狀態良好的負載平衡器。

以下是範例設定，顯示兩個不同區域中的兩個區域性外部應用程式負載平衡器。

以下各節說明一般工作流程，以及這項設定涉及的不同元件。

1. 使用健康狀態檢查偵測區域性故障

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

   其他注意事項：

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

2. 將流量轉送至健康狀態良好的負載平衡器

   Google Cloud 使用 Cloud DNS 地理位置路徑政策，將流量導向負載平衡器。如果所有負載平衡器都運作正常，Cloud DNS 會將流量轉送至地理位置最接近用戶端要求來源的負載平衡器。

   當特定區域的負載平衡器開始無法通過健康狀態檢查時，流量會轉送至其他區域中健康狀態良好的負載平衡器。

3. 恢復使用所有負載平衡器

   健康狀態檢查再次通過時，系統會自動執行容錯回復。由於所有可用的負載平衡器都會提供流量服務，因此預期在容錯回復期間不會發生停機。

設定跨地區負載平衡

請按照下列步驟，設定可提高可用性的跨區域部署：

1. 在您認為最適合支援應用程式流量的區域中，建立區域性外部應用程式負載平衡器。這些負載平衡器必須具有相同的流量管理和安全性設定。
2. 建立健康狀態檢查和 DNS 轉送政策，根據用戶端位置將流量導向負載平衡器，並在發生中斷時，將流量從健康狀態不良的負載平衡器轉送出去。

在多個區域中建立負載平衡器

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

• 設定所有具備類似功能的區域性外部應用程式負載平衡器，確保無論哪個負載平衡器處理要求，流量都會以一致的方式處理。舉例來說，您必須確保所有區域外部應用程式負載平衡器都使用相同類型的 SSL 憑證、相同的 Cloud Armor 政策，以及相同的流量管理設定。

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

• 建議您在每個區域中設定區域性外部應用程式負載平衡器，以判斷最適合支援應用程式流量的區域。

• 區域性外部應用程式負載平衡器支援進階和標準網路服務級別。建議您在進階層級中設定額外的區域性外部應用程式負載平衡器，確保低延遲。

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

設定 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 中建立記錄集，並套用地理位置轉送政策。

   gcloud dns record-sets create DNS_RECORD_SET_NAME \
       --ttl=TIME_TO_LIVE \
       --type=RECORD_TYPE \
       --zone="MANAGED_ZONE_NAME" \
       --routing-policy-type="GEO" \
       --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
       --health-check=HEALTH_CHECK_NAME
   

   更改下列內容：

   • DNS_RECORD_SET_NAME：要新增的記錄集 DNS 或網域名稱，例如 test.example.com
   • TIME_TO_LIVE：記錄的存留時間 (TTL)，單位為秒。如需建議值，請參閱「DNS 注意事項」。
   • RECORD_TYPE：記錄類型，例如 A
   • MANAGED_ZONE_NAME：要管理記錄集的代管區域名稱，例如 my-zone-name
   • FORWARDING_RULE_NAME：每個 REGION 中負載平衡器的轉送規則名稱
   • REGION：部署各負載平衡器的區域

最佳做法

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

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

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

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

  建議將 DNS TTL 設為 30 到 60 秒。TTL 較長會導致停機時間較長，因為即使 DNS 故障轉移至其他區域，網際網路上的用戶端仍會繼續存取狀況不佳的負載平衡器。

• 在健康狀態檢查中設定良好和不良健康狀態判定門檻參數，避免因暫時性錯誤而導致流量不必要地突然重新導向。如果提高門檻，流量轉移至其他區域負載平衡器的時間就會變長。