如何疑難排解 Application Load Balancer 會話黏性的問題？

簡短說明

黏性會話使用 Cookie 協助用戶端在 Cookie 的生命週期內保持與相同目標的連接。黏性會話設定負載平衡器，將使用者工作階段連結至特定目標。這意味著使用者在工作階段期間所發出的所有請求都會傳送到相同的目標。但是，這種關於連接的假設可能會隨著時間的推移導致不平衡。

黏性會話可能會因以下原因失敗：

• 註冊的目標沒有產生 Cookie。
• 用戶端沒有傳回請求標頭中的 Cookie。
• Cookie 格式不正確。
• 基於持續時間的工作階段結束。
• 工作階段請求會通過多個負載平衡器。
• 目標健康狀況變更為不健康。
• AWS 服務已關閉黏性。

注意： 在開始之前，請務必檢視 Application Load Balancer 的黏性會話的需求和注意事項部分。

解決方法

以應用程式為基礎的會話黏性

1. 使用負載平衡器檢查 HTTP 錯誤。如需說明，請參閱疑難排解 Application Load Balancer。

2. 若要檢查放置在後端執行個體或負載平衡器上的 Cookie，請執行類似下列的 curl 命令。用負載平衡器名稱取代 DNS 名稱：

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-EXAMPLE-ELB-1430759361.eu-central-1.elb.amazonaws.com

   注意： 您也可以在 Windows 作業系統 (OS) 上安裝 Linux curl 公用程式。如需詳細資訊，請參閱 curl 網頁上適用於 Windows 的 curl 8.10.1。

   curl 命令的輸出看起來類似於下列：

   ...
   < Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/
   
   < Set-Cookie:
   
   AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
   
   ...

3. 若要驗證註冊目標已產生的應用程式 Cookie，請將 HTTP 請求傳送到執行個體 IP 位址類似於下列：

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168

   命令的輸出看起來類似於下列：

   ...
   < Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/
   
   ...

4. 驗證註冊目標所產生的 Cookie 名稱，是從步驟 2 和 3 中負載平衡器上的 Cookie 名稱。

5. 當目標產生應用程式 Cookie，以及負載平衡器產生 AWSALBAPP Cookie 時，請檢查用戶端是否在後續請求中傳送兩種 Cookie。如果用戶端沒有包含應用程序或 AWSELB Cookie，則黏性失敗。若要驗證用戶端是否傳送應用程式和 AWSALBAPP Cookie，請在用戶端進行封包擷取。若要擷取請求標頭中的 Cookie 資訊，請使用下列其中一個選項：

   來自 tcpdump 網頁的 tcpdump
   來自 Wireshark 網頁的 Wireshark 公用程式
   瀏覽器網頁偵錯工具

   注意： 如果您正在與 AWS Support 合作，請建立 HAR 檔案來收集這些資訊。由於 HAR 檔案可以擷取敏感資訊，例如使用者名稱、密碼和金鑰，請確保從 HAR 檔案中刪除敏感資訊。

6. 檢查負載平衡器請求路由的後端執行個體。若要使用執行個體中繼資料來顯示執行個體 ID，請執行類似下列指令碼：

   <?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');echo "instance id = " . $instance_id . "\\xA";?>

7. 若要檢查來自同一使用者的請求是否路由到不同的註冊目標，請檢視 Elastic Load Balancing (ELB) 存取日誌。如需指示，請參閱 Application Load Balancer 的存取日誌。

8. 驗證已開啟黏性的目標群組下，所有目標的健康狀態是否為健康。如果目標健康狀態變更為不健康，則黏性會中斷且負載平衡器不會將請求路由到該目標。負載平衡器接著會自動選擇一個新的健康目標，並建立一個黏性會話。即使健康狀態為不健康，負載平衡器仍會將請求路由到新目標。如需有關運作狀態檢查的詳細資訊，請參閱 Application Load Balancer 目標群組的運作狀態檢查。

9. 檢查可能已在負載平衡器中關閉黏性的 AWS 服務，例如 Amazon Elastic Kubernetes Service (Amazon EKS)。檢查 CloudTrail 事件歷史記錄。使用 API 名稱 ModifyTargetGroupAttributes 和屬性 stickiness.enabled。

基於持續時間的會話黏性

1. 若要檢查 AWSALB Cookie，請執行類似下列的 curl 命令。請確定您使用負載平衡器 DNS 名稱：

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com

   curl 命令的輸出看起來類似於下列：

   ...
   < Set-Cookie: AWSALB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
   ...

   注意： 如果回應中沒有 AWSALB Cookie，則用戶端和後端執行個體之間沒有黏性。

2. 如果負載平衡器產生了 AWSALB Cookie，請檢查用戶端在後續請求中傳送此 Cookie。如果用戶端包含 AWSALB Cookie 失敗，則黏性將不會作用。若要驗證用戶端是否傳送 AWSALBAPP Cookie，請在用戶端進行封包擷取。若要擷取請求標頭中的 Cookie 資訊，請使用下列其中一個選項：

   來自 tcpdump 網頁的 tcpdump
   來自 Wireshark 網頁的 Wireshark 公用程式
   瀏覽器網頁偵錯工具

   注意： 如果您正在與 AWS Support 合作，請建立 HAR 檔案來收集這些資訊。由於 HAR 檔案可以擷取敏感資訊，例如使用者名稱、密碼和金鑰，請確保從 HAR 檔案中刪除敏感資訊。

3. 檢查負載平衡器上設定的持續時間。如果 Cookie 過期，則在負載平衡器發出新 Cookie 之前，用戶端工作階段將不再與註冊目標黏著。

4. 如果您的請求通過多個負載平衡器，請驗證僅在一個負載平衡器上啟用黏性。如果有多個負載平衡器產生 Cookie，則負載平衡器會取代原始 Cookie，進而導致黏性失敗。

針對 Classic Load Balancer，請參閱如何疑難排解 Classic Load Balancer 會話黏性特徵？

相關資訊

為什麼 Elastic Load Balancing 會不平等地路由我的負載平衡器流量？

設定 Classic Load Balancer 的黏性會話

如何為我的 Application Load Balancer 設定加權目標群組？