Application Load Balancer 的黏性工作階段 - Elastic Load Balancing

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Application Load Balancer 的黏性工作階段

在預設情況下,應用程式負載平衡器會根據所選的負載平衡演算法,將每個請求獨立路由到已註冊的目標。不過,您可以使用黏性工作階段功能(也稱為工作階段親和性)來啟用負載平衡器將使用者的工作階段綁定到特定目標。這樣能確保該工作階段期間所有來自的請求都能傳送到相同的目標。此功能對於維護狀態資訊以便為用户端提供持續體驗的伺服器來説很實用。若要使用黏性工作階段,客户端必須支援 Cookie。

應用程序負載均衡器支持基於持續時間的 Cookie 和基於應用程序的 cookie。粘性工作階段在目標羣組級別啟用。您可以使用基於持續時間的粘性、基於應用的粘性和不粘性在目標羣體之間的組合。

管理黏性工作階段的關鍵是決定您的負載平衡器應該持續將用户請求路由到同一個目標的時間。如果您的應用程式有其自己的工作階段 Cookie,則您可以使用基於應用程式的黏性,並且負載平衡器工作階段 Cookie 遵循應用程式的工作階段 Cookie 指定的持續時間。如果您的應用程式沒有自己的工作階段 Cookie,則您可用指定的持續時間來產生負載平衡器工作階段 Cookie。

系統會使用輪換金鑰來對負載平衡器生成的 Cookie 的內容進行加密。您無法解密或修改負載平衡器生成的 Cookie。

對於這兩種粘性類型,Application Load Balancer 會重置它在每次請求後生成的 cookie 的到期時間。如果 Cookie 過期,該工作階段不再有黏性,客户端應該從其 Cookie 存放區移除 Cookie。

要求

  • HTTP/HTTPS 負載平衡器。

  • 在各個可用區域內啟動至少一個正常運作的執行個體。

考量

  • 對於基於應用程序的 cookie,必須為每個目標羣體單獨指定 Cookie 名稱。但是,對於基於持續時間的 Cookie,AWSALB是所有目標組中使用的唯一名稱。

  • 如果您使用多層級的應用程式負載平衡器,則您可用基於應用程式的 Cookie 在所有層級啟用黏性工作階段。但是,使用基於持續時間的 cookie,您只能在一個層上啟用粘性會話,因為AWSALB是唯一可用的名稱。

  • 基於應用的粘性不適用於加權目標羣體。

  • 如果您有轉送動作,並且已將黏性工作階段設定為一或多個目標羣組啟用黏性工作階段,則您必須在目標羣組層級啟用黏性。

  • WebSocket 連線本質上具黏性。如果用戶端請求將連線升級到 WebSocket,傳回 HTTP 101 狀態碼以接受連線升級的目標,為 WebSocket 連線中使用的目標。之後 WebSockets 升級完成,不會使用 Cookie 為基礎的黏性。

  • Application Load Balancer 使用Expires屬性,而非Max-Age屬性。

  • 應用程式負載平衡器不支援 URL 編碼的 Cookie 值。

持續時間為基礎的粘着性

基於持續時間的黏性會使用負載平衡器產生的 Cookie(AWSALB。Cookie 用於對應工作階段到目標。如果您的應用程式沒有自己的工作階段 Cookie,您可用指定自己的黏性持續時間,並管理負載平衡器應該持續將用户請求路由到相同目標的時間。

當負載平衡器第一次接收來自用户端的請求,它會將請求路由到一個目標(基於所選的算法),並產生一個名為AWSALB。它會將有關所選目標的資訊編碼,加密 cookie,並包含響應到用户端的 cookie。負載均衡器生成的 cookie 有自己的有效期為 7 天,這是不可配置的。

在後續請求中,客户端應該包含AWSALBCookie。當負載平衡器包含從 Cookie 的用户端收到要求時,它會檢測此請求並將請求路由到相同目標。如果 Cookie 存在但無法解碼,或者它參照了已取消註冊或狀況不良的目標,負載平衡器會選取新的目標,並以新目標的相關資訊更新 Cookie。

對於跨來源資源分享 (CORS) 請求,某些瀏覽器需要SameSite=None; Secure以啟用粘性。在這種情況下,負載均衡器會生成第二個粘性 cookie,AWSALBCORS,其中包含與原始綁定 Cookie 加上與SameSite屬性。用戶端會同時收到這兩個 Cookie。

使用主控台啟用持續時間為基礎的黏性

  1. https://console.aws.amazon.com/ec2/ 開啟 Amazon EC2 主控台。

  2. 在導覽窗格的負載平衡,選擇目標群組

  3. 選取目標羣組的名稱,來開啟其詳細資訊頁面。

  4. 羣組詳細資訊選項卡中的Attributes (屬性)部分中,選擇Edit (編輯)

  5. Edit attributes (編輯屬性) 頁面上,執行下列動作:

    1. 選擇黏性工作

    2. 適用於黏性工作類型,選擇負載均衡器生成的 cookie

    3. 針對 Stickiness duration (黏性持續期間),指定介於 1 秒到 7 天之間的值。

    4. 選擇 Save changes (儲存變更)。

使用啟用持續時間為基礎的黏性AWS CLI

使用 modify-target-group-attributes 命令搭配 stickiness.enabledstickiness.lb_cookie.duration_seconds 屬性。

請使用下列命令來啟用基於持續時間的粘性。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

輸出應類似下列範例。

{ "Attributes": [ ... { "Key": "stickiness.enabled", "Value": "true" }, { "Key": "stickiness.lb_cookie.duration_seconds", "Value": "86500" }, ... ] }

用途為基礎的粘着性

基於應用的粘性使您能夠靈活地設置自己的客户端-目標粘性標準。啟用基於應用程序的粘性時,負載均衡器會根據所選算法將第一個請求路由到目標組內的目標。目標應該設置一個自定義應用程序 cookie,該 cookie 與負載均衡器上配置的 cookie 相匹配,以啟用粘性。此自定義 cookie 可以包含應用程序所需的任何 cookie 屬性。

當 Application Load Balancer 從目標接收自定義應用程序 cookie 時,它會自動生成一個新的加密應用程序 cookie 以捕獲粘性信息。此負載均衡器生成的應用程序 Cookie 捕獲啟用了基於應用程序的粘性的每個目標組的粘性信息。

負載均衡器生成的應用程序 cookie 不會複製目標設置的自定義 cookie 的屬性。它自己的有效期為 7 天,這是不可配置的。在響應客户端時,Application Load Balancer 僅驗證在目標組級別配置自定義 cookie 時使用的名稱,而不驗證自定義 cookie 的值或過期屬性。只要名稱匹配,負載均衡器就會在響應客户端中同時發送 cookie、目標設置的自定義 cookie 以及負載均衡器生成的應用程序 cookie。

在後續請求中,客户端必須發回兩個 cookie 以保持粘性。負載均衡器解密應用程序 cookie,並檢查配置的粘性持續時間是否仍然有效。然後,它會使用 Cookie 中的資訊將請求傳送到目標羣組中相同目標,以保持黏性。負載均衡器還將自定義應用程序 cookie 代理到目標,而無需檢查或修改它。在後續響應中,將重置負載均衡器生成的應用程序 Cookie 的到期以及在負載均衡器上配置的粘性持續時間。為了保持客户和目標之間的粘性,cookie 的到期和粘性的持續時間不應過去。

如果目標發生失敗或變成運作狀態不佳,負載平衡器停止路由請求到該目標,並根據所選的負載平衡演算法選擇新的運作狀態良好的目標。負載平衡器會將工作階段視為「卡住」到運作狀態良好的目標,並持續路由請求到即使失敗的目標返回到新的運作狀態良好的目標。

使用跨來源資源分享 (CORS) 請求,若要啟用粘性,負載平衡器會將SameSite=None; Secure屬性添加到負載均衡器生成的應用程序 cookie,僅當用户代理版本為 Chromium80 或更高版本時。

由於大部分瀏覽器會將 Cookie 大小限制在 4K,負載平衡器會將大小大於 4K 的應用程式 Cookie 分成多個 Cookie。應用程序負載均衡器支持最大 16K 大小的 cookie,因此最多可以創建 4 個分片,發送給客户端。客户端看到的應用程序 cookie 名稱以「AWSALBAPP-」開頭,幷包含一個片段編號。例如,如果 Cookie 大小為 0-4K,則客户端會看到 AWSALBAPP-0。如果 Cookie 的大小為 4-8 千,則客户端會看到 AWSALBAPP-0 和 AWSALBAPP-1,依此類推。

使用主控台啟用應用程式黏性

  1. https://console.aws.amazon.com/ec2/ 開啟 Amazon EC2 主控台。

  2. 在導覽窗格的負載平衡,選擇目標群組

  3. 選取目標羣組的名稱,來開啟其詳細資訊頁面。

  4. 羣組詳細資訊選項卡中的Attributes (屬性)部分中,選擇Edit (編輯)

  5. Edit attributes (編輯屬性) 頁面上,執行下列動作:

    1. 選擇黏性工作

    2. 適用於黏性工作類型,選擇基於應用程式的 cookie

    3. 針對 Stickiness duration (黏性持續期間),指定介於 1 秒到 7 天之間的值。

    4. 適用於應用程序 Cookie 名稱中,輸入應用程式型 Cookie 的名稱。

      請勿使用AWSALBAWSALBAPP, 或AWSALBTG作為 Cookie 名稱;它們保留供負載平衡器使用。

    5. 選擇 Save changes (儲存變更)。

使用啟用應用程式黏性AWS CLI

使用修改目標-組屬性命令,包含下列屬性:

  • stickiness.enabled

  • stickiness.type

  • stickiness.app_cookie.cookie_name

  • stickiness.app_cookie.duration_seconds

請使用下列命令來啟用基於應用程式的粘性。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

輸出應類似下列範例。

{ "Attributes": [ ... { "Key": "stickiness.enabled", "Value": "true" }, { "Key": "stickiness.app_cookie.cookie_name", "Value": "MyCookie" }, { "Key": "stickiness.type", "Value": "app_cookie" }, { "Key": "stickiness.app_cookie.duration_seconds", "Value": "86500" }, ... ] }

手動重新平衡

在擴大規模時,如果目標數量大幅度增加,則可能由於粘性而導致負載分佈不均。在這種情況下,您可以使用以下兩個選項重新平衡目標上的負載:

  • 在當前日期和時間之前的應用程序生成的 cookie 上設置過期。這將阻止客户端將 cookie 發送到 Application Load Balancer,這將重新啟動建立粘性的過程。

  • 在負載均衡器基於應用程序的粘性配置上設置一個非常短的持續時間,例如 1 秒。這會強制 Application Load Balancer 重新建立粘性,即使目標設置的 cookie 尚未過期。