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

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

使用 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 憑證、相同的 Google 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 已改用其他區域，網際網路上的用戶端仍會繼續存取不健康的負載平衡器。

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