本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Network Load Balancer 疑難排解
以下資訊可協助您就 Network Load Balancer 問題進行疑難排解。
已註冊目標處於非服務中狀態
如果目標進入 InService
狀態所花的時間超過預期,表示該目標可能未通過運作狀態檢查。您的目標將處於非服務中狀態,除非通過一次運作狀態檢查。如需詳細資訊,請參閱 Network Load Balancer 目標群組的 Health 檢。
確認您的執行個體是否未通過運作狀態檢查,然後檢查以下各項:
請求未路由至目標
檢查以下各項:
- 安全群組不允許流量
-
與執行個體相關聯的安全群組必須允許透過接聽程式連接埠來自用戶端 IP 地址的流量 (若目標是由執行個體 ID 指定) 或來自負載平衡器節點的流量 (若目標是由 IP 地址指定)。如需詳細資訊,請參閱 目標安全群組。
- 網路存取控制清單 (ACL) 不允許流量
-
與 VPC 的子網路相關聯的網路 ACL 必須允許負載平衡器和目標透過接聽程式連接埠進行雙向通訊。如需詳細資訊,請參閱 網路ACLs。
- 目標位於未啟用的可用區域
-
如果您在某個可用區域內註冊目標但未啟用該可用區域,這些已註冊目標將不會接收來自負載平衡器的流量。
- 執行個體位於對等的 VPC
-
如果您在與負載平衡器 VPC 對等的 VPC 中有執行個體,您必須依 IP 地址向負載平衡器註冊這些執行個體,而不是依執行個體 ID。
目標接收到比預期更多的運作狀態檢查請求
Network Load Balancer 的運作狀態檢查為分散式,並採用共識機制判定目標的運作狀態。因此,目標會接收超過由 HealthCheckIntervalSeconds
所設定次數的運作狀態檢查。
目標接收到比預期更少的運作狀態檢查請求
檢查是否已啟用 net.ipv4.tcp_tw_recycle
。此設定已知將導致負載平衡器出問題。使用 net.ipv4.tcp_tw_reuse
設定是較為安全的替代方法。
運作狀態不佳的目標接收到來自負載平衡器的請求
當所有已登錄目標運作狀態均不佳時,就會發生此情況。如至少有一個運作狀態良好的已登錄目標,則 Network Load Balancer 僅會路由請求至運作狀態良好的已登錄目標。
若僅存在運作狀態不佳的已登錄目標,則 Network Load Balancer 會路由請求至所有已登錄目標,這稱為故障開放模式。當所有目標運作狀態均不佳且其各自可用區域均無可傳送請求的運作狀態良好目標時,Network Load Balancer 會執行此動作,而非從 DNS 移除所有 IP 地址。
目標因為主機標頭不相符而無法進行 HTTP 或 HTTPS 運作狀態檢查
運作狀態檢查請求中的 HTTP 主機標頭包含負載平衡器節點的 IP 地址和接聽程式連接埠 (而不是目標的 IP 位址和運作狀態檢查連接埠)。如果您透過主機標頭映射傳入請求,則必須確保運作狀態檢查符合任何 HTTP 主機標頭。另一個選項是在不同的連接埠上新增個別的 HTTP 服務,並將目標群組設定為使用該連接埠進行運作狀態檢查。或者,請考慮使用 TCP 運作狀態檢查。
無法關聯安全群組與負載平衡器
如 Network Load Balancer 於建立時無安全群組,則在建立之後將無法支援安全群組。您僅能在建立期間關聯安全群組與負載平衡器,或關聯原本利用安全群組建立的現有負載平衡器。
無法移除所有安全群組
如 Network Load Balancer 於建立時具安全群組,則必須至少隨時有一個與其關聯的安全群組。您無法同時從負載平衡器移除所有安全群組。
增加 TCP_ELB_Reset_Count 指標
對於用戶端透過 Network Load Balancer 做出的每項 TCP 請求,將追蹤該連線狀態。若在比閒置逾時更長的時間內沒有由用戶端或目標透過連線傳送的資料,連線將關閉。如果用戶端或目標閒置逾時時間經過後傳送資料,就會收到一個 TCP RST 封包,表示連線不再有效。此外,如目標的運作狀態變為不佳,負載平衡器會針對關聯目標的用戶端連線所接收的封包傳送 TCP RST,除非運作狀態不佳的目標觸發負載平衡器進入故障開放。
如您在 TCP_ELB_Reset_Count
指標增加之前或增加當時看到 UnhealthyHostCount
指標遽增,很可能是因為目標開始出現故障但尚未標示為運作狀態不佳而傳送 TCP RST 封包。如您看到目標未標示為運作狀態不佳,但 TCP_ELB_Reset_Count
持續增加,您可檢查 VPC Flow Logs,了解是否有用戶端透過過期流量傳送資料。
目標向其負載平衡器發出的請求連線逾時
檢查目標群組是否啟用用戶端 IP 保留。當啟用用戶端 IP 保留時,不支援 NAT 迴路,也稱為假髮釘設定。如執行個體是其所登錄負載平衡器的用戶端,且已啟用其用戶端 IP 保留,則僅當路由請求至另一執行個體時連線才會成功。如路由請求至傳送來源的相同執行個體,則連線會因來源與目的地 IP 地址相同而逾時。
如果執行個體必須傳送請求至其註冊的負載平衡器,請執行以下其中一項操作:
-
停用用戶端 IP 保留。
-
確保必須相互通訊的各容器位於不同容器執行個體。
若將目標移至 Network Load Balancer,效能會下降
Classic Load Balancer 與 Application Load Balancer 均採用多工處理,但 Network Load Balancer 並非如此。因此,在 Network Load Balancer 後方的目標可接收更多 TCP 連線。請確定您的目標已準備好處理其可能接收到的連線請求量。
連接埠配置錯誤 AWS PrivateLink
如 Network Load Balancer 關聯 VPC 端點服務,則其針對每個唯一目標 (IP 地址與連接埠) 支援 55,000 個同時連線或每分鐘約 55,000 個連線。若超過上述連線數量,將提高連接埠配置錯誤機率。可以使用 PortAllocationErrorCount
指標追蹤連接埠配置錯誤。若要修復連接埠配置錯誤,請將更多目標加入目標群組。如需詳細資訊,請參閱 Network Load Balancer 的CloudWatch 指標。
當啟用用戶端 IP 保留時,發生間歇性連線失敗
當啟用用戶端 IP 保留時,您可能遇到 TCP/IP 連線限制,這與在目標觀察到的通訊端重複使用有關。當用戶端或用戶端前面的 NAT 裝置在同時連線至多個負載平衡器節點時,使用相同的來源 IP 地址與來源連接埠時,可能會發生這些連線限制。如果負載平衡器將這些連線路由至相同的目標,則連線會顯示在目標上,就像它們來自相同的來源通訊端一樣,這會導致連線錯誤。如發生此情況,用戶端可重試 (如連線失敗) 或重新連線 (如連線中斷)。您可以增加來源暫時連接埠的數目或增加負載平衡器的目標數目,以減少此類型的連線錯誤。您可停用用戶端 IP 保留或停用跨區域負載平衡來防止此類連線錯誤。
此外,當啟用用戶端 IP 保留時,如連線至 Network Load Balancer 的用戶端也連線至負載平衡器後方的目標,則連線可能失敗。若要解決此問題,您可停用受影響目標群組的用戶端 IP 保留功能。或者,讓用戶端僅連線 Network Load Balancer,或僅連線目標,但不能同時連線兩者。
TCP 連線延遲
當同時啟用跨區域負載平衡與用戶端 IP 保留時,若用戶端連線至相同負載平衡器的不同 Ip,可能被路由至相同目標。如用戶端對這兩個連線採用相同來源連接埠,則目標會收到看似重複的連線,這可能導致連線錯誤及 TCP 延遲建立新連線。您可停用跨區域負載平衡來防止此類連線錯誤。如需詳細資訊,請參閱 跨區域負載平衡。
佈建負載平衡器時的潛在故障
Network Load Balancer 在佈建時可能失敗的其中一個原因是,您使用已指派或配置到其他地方的 IP 地址 (例如,指派為 EC2 執行個體的次要 IP 地址)。此 IP 地址會讓負載平衡器無法進行設定,且其狀態為 failed
。您可取消配置關聯的 IP 地址並重試建立程序來解決此問題。
DNS 名稱解析所包含的 IP 地址少於已啟用可用區域
在理想情況,當可用區域至少有一個運作狀態良好的主機時,Network Load Balancer 會為每個已啟用的可用區域提供單一 IP 地址。若特定可用區域無運作狀態良好的主機,且已停用跨區域負載平衡,則該 AZ 的個別 Network Load Balancer IP 地址將從 DNS 移除。
例如,假設您的 Network Load Balancer 啟用三個可用區域,所有這些區域至少都有一個運作狀態良好的已登錄目標執行個體。
-
如可用區域 A 的已登錄目標執行個體運作狀態變為不佳,則會從 DNS 移除 Network Load Balancer 可用區域 A 的對應 IP 地址。
-
如任何兩個已啟用的可用區域無運作狀態良好的已登錄目標執行個體,則 Network Load Balancer 的相應兩個 IP 地址將從 DNS 移除。
-
如所有已啟用的可用區域均無運作狀態良好的已登錄目標執行個體,則會啟用故障開放模式,而 DNS 會因此提供來自三個已啟用 AZ 的所有 IP 地址。
使用資源對應疑難排解狀況不良的目標
如果您的 Network Load Balancer 目標未通過健康狀態檢查,您可以使用資源對應來尋找狀態不良的目標,並根據失敗原因程式碼採取動作。如需詳細資訊,請參閱 檢視 Network Load Balancer 資源地圖。
資源對應提供兩種檢視:「概觀」和「狀況不良目標對映」。預設情況下會選取「概觀」,並顯示所有負載平衡器的資源。選取狀態不良的目標對映檢視將只會顯示與 Network Load Balancer 相關聯之每個目標群組中狀況不良的目標。
注意
必須啟用「顯示資源詳細資訊」,才能檢視資源對映中所有適用資源的健全狀況檢查摘要和錯誤訊息。未啟用時,您必須選取每個資源以檢視其詳細資訊。
「目標群組」資料欄會顯示每個目標群組之狀況良好和狀況不良目標的摘要。這有助於判斷所有目標是否都未通過健康狀態檢查,或是只有特定目標失敗。如果目標群組中的所有目標都未通過健全狀況檢查,請檢查目標群組的健全狀況檢查設定。選取目標群組的名稱,即可在新索引標籤中開啟其詳細資訊頁面。
「目標」資料欄會顯示 TargetID 和每個目標的目前健康狀況檢查狀態。當目標狀況不良時,會顯示健全狀況檢查失敗原因代碼。當單一目標未通過健全狀況檢查時,請確認目標具有足夠的資源。選取目標的 ID 以在新索引標籤中開啟其詳細資訊頁面。
選取 [匯出] 可讓您選擇將網路負載平衡器資源對應的目前檢視匯出為 PDF。
確認您的執行個體未通過運作狀態檢查,然後根據失敗原因程式碼檢查下列問題:
-
健康狀況不良:請求逾時
-
確認與目標相關聯的安全群組和網路存取控制清單 (ACL),以及「Network Load Balancer」未封鎖連線。
-
確認目標有足夠的容量可用於接受來自 Network Load Balancer 的連線。
-
您可以在每個目標的應用程式記錄中檢視網路負載平衡器的健全狀況檢查回應。如需詳細資訊,請參閱 Health 檢查原因代碼。
-
-
不健康: FailedHealthChecks
-
確認目標正在接聽健全狀況檢查連接埠上的流量。
使用 TLS 接聽程式時
您可以選擇用於前端連線的安全性原則。系統會根據使用中的前端安全性原則,自動選取用於後端連線的安全性原則。
-
如果您的 TLS 接聽程式使用 TLS 1.3 安全性原則進行前端連線,則
ELBSecurityPolicy-TLS13-1-0-2021-06
安全性原則會用於後端連線。 -
如果您的 TLS 接聽程式未針對前端連線使用 TLS 1.3 安全性原則,則
ELBSecurityPolicy-2016-08
安全性原則會用於後端連線。
如需詳細資訊,請參閱安全性原則。
-
-
確認目標是否以安全性原則指定的正確格式提供伺服器憑證和金鑰。
-
確認目標支援一或多個相符的密碼,以及 Network Load Balancer 提供用於建立 TLS 交握的通訊協定。
-