排解內部應用程式負載平衡器的問題

本指南說明如何排解 Cloud de Confiance by S3NS 內部應用程式負載平衡器的設定問題。在按照本指南操作之前，請先熟悉以下內容：

後端具有不相容的平衡模式

建立負載平衡器時，您可能會看到以下錯誤：

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

如果您嘗試在兩個不同的負載平衡器中使用相同的後端，但後端沒有相容的平衡模式，就會發生這種情況。

如要瞭解詳情，請參考下列資源：

經過負載平衡後的流量沒有原始用戶端的來源位址

請放心，這是正常情況。 內部應用程式負載平衡器會做為 HTTP(S) 反向 Proxy (閘道) 運作。當用戶端程式開啟與 INTERNAL_MANAGED 轉送規則 IP 位址的連線時，連線會終止於 Proxy 位置，Proxy 便會處理透過該連線傳送的要求。對於每個要求，Proxy 都會根據網址對應和其他因素選擇一個後端來接收要求。接著 Proxy 將要求傳送到選定的後端。因此從後端的觀點來看，傳入封包的來源是該地區僅限 Proxy 子網路的 IP 位址。

負載平衡器無法連線到後端

您需要設定保護後端伺服器的防火牆，以允許從您分配給內部 HTTP(S) 負載平衡器地區的僅限 Proxy 子網路範圍內的 Proxy 輸入流量。

Proxy 會使用後端服務設定所指定的連線設定連線到後端。如果這些值與您後端執行的伺服器設定不符，Proxy 就無法將要求轉送到後端。

健康狀態檢查探測無法連上後端

如要確認健康狀態檢查流量傳送至後端 VM，請啟用健康狀態檢查記錄，並搜尋成功的記錄項目。

用戶端無法連線到負載平衡器

Proxy 會偵聽連到負載平衡器的 IP 位址的連線和轉送規則中設定的通訊埠 (例如 10.1.2.3:80)，以及轉送規則 (HTTP 或 HTTPS) 中指定的通訊協定。如果您的用戶端無法連線，請確認他們使用的位址、通訊埠和通訊協定正確無誤。

確認防火牆沒有封鎖用戶端執行個體和負載平衡 IP 位址之間的通訊。

確認用戶端與負載平衡器位於相同的地區。內部 HTTP(S) 負載平衡是地區性產品，因此所有用戶端 (和後端) 都必須與負載平衡器資源位於相同的地區。

Shared VPC 的組織政策限制

如果您使用 Shared VPC，且無法在特定子網路中建立新的內部應用程式負載平衡器，原因可能在於組織政策。請在組織策略中，將該子網路新增到允許的子網路清單中，或是與您的機構組織管理員聯絡。詳情請參閱 constraints/compute.restrictSharedVpcSubnetworks。

負載平衡器無法將流量平均分配到各個可用區

您可能會發現內部應用程式負載平衡器在各個區域的流量不平均。如果後端容量使用率偏低 (低於 10%)，就特別容易發生這種情況。

由於流量只會傳送至單一區域中的少數幾部伺服器，這類行為可能會影響整體延遲。

如要平均分配各區域的流量，可以進行下列設定變更：

  • 使用 RATE 平衡模式，並設定較低的 max-rate-per-instance 目標容量。
  • 使用 LocalityLbPolicy 後端流量政策，並採用 LEAST_REQUEST 負載平衡演算法。

未說明的 5xx 錯誤

如果負載平衡器 Proxy 與後端之間的通訊發生問題，導致錯誤狀況，負載平衡器會產生 HTTP 狀態碼 (5xx)，並將該狀態碼傳回給用戶端。並非所有 HTTP 5xx 錯誤都是由負載平衡器產生。舉例來說，如果後端將 HTTP 5xx 回應傳送至負載平衡器，負載平衡器會將該回應轉送至用戶端。如要判斷 HTTP 5xx 回應是從後端轉送，還是由負載平衡器 Proxy 產生，請參閱負載平衡器記錄的 proxyStatus 欄位。

變更內部應用程式負載平衡器的設定 (例如新增或移除後端服務) 時，使用者可能會在短時間內看到 HTTP 狀態碼 503。這些設定變更會傳播至全球的 Envoy，您會看到 proxyStatus 欄位與 connection_refused 記錄字串相符的記錄項目。

如果完成負載平衡器設定後，HTTP 5xx 狀態碼持續出現超過幾分鐘的時間，請按照下列步驟排解 HTTP 5xx 回應問題：

  1. 確認已設定防火牆規則，允許健康狀態檢查。 如果沒有，負載平衡器記錄通常會有相符的 proxyStatusdestination_unavailable，表示負載平衡器認為後端無法使用。

  2. 確認健康狀態檢查流量傳送至後端 VM。如要使用這項功能，請啟用健康狀態檢查記錄功能，並搜尋成功的記錄項目。

    對於新的負載平衡器，缺少成功的健康狀態檢查項目，並不代表健康狀態檢查流量未到達後端。這可能表示後端的初始健康狀態尚未從 UNHEALTHY 變更為其他狀態。只有在健康狀態檢查探測器收到後端傳送的 HTTP 200 OK 回應後，才會看到成功的健康狀態檢查記錄項目。

  3. 確認後端執行個體上執行的 HTTP 伺服器軟體，其 Keep-Alive 設定參數不小於負載平衡器的 Keep-Alive 逾時 (固定為 10 分鐘 (600 秒)，無法設定)。

    當負載平衡器傳送 HTTP 要求時，或在收到完整的 HTTP 回應前，與後端的連線意外關閉，負載平衡器就會產生 HTTP 5xx 狀態碼。這是因為在後端執行個體上執行的網路伺服器軟體，其連線存續期設定參數小於負載平衡器的固定連線存續期逾時。請確保每個後端 HTTP 伺服器軟體的連線存續逾時設定略大於 10 分鐘 (建議值為 620 秒)。

建立轉送規則失敗，並顯示「Address is not an RFC 1918 address」(位址不是 RFC 1918 位址) 錯誤訊息

在子網路中建立含有常值 IP 位址的內部轉送規則時，如果子網路使用非 RFC 1918 範圍，您會看到類似下列的錯誤：

ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource:
 - Invalid value for field 'resource.IPAddress': '100.71.1.88'. Address '100.71.1.88' is not an RFC1918 address.

API 驗證工具會根據 RFC 1918 標準嚴格檢查字面值，防止意外的公開可轉送 IP 路由。不過，系統不會動態評估常值位址是否由 VPC 管理，因此直接提供非 RFC 1918 IP 時會失敗。

如要解決這個問題，請採取下列任一做法：

  • 從 gcloud compute forwarding-rules create 指令中省略 --address 標記。 Cloud de Confiance 會直接從子網路自動分配安全有效的 IP 位址。
  • 請先使用 gcloud compute addresses create 指令預留已命名的 IP 位址資源。接著，您必須使用 --address 旗標參照保留名稱：
    1. 將靜態 IP 位址保留為具名資源： bash gcloud compute addresses create ADDRESS_NAME \ --addresses=IP_ADDRESS \ --region=REGION \ --subnet=SUBNET \ --purpose=SHARED_LOADBALANCER_VIP
    2. 在轉送規則建立指令中，依名稱參照預留的 IP 位址：--address=ADDRESS_NAME。

限制

如果無法順利將內部應用程式負載平衡器與其他Cloud de Confiance 網路功能搭配使用，請注意目前的相容性限制。