如何解决应用程序负载均衡器会话粘性问题？

简短描述

粘性会话使用 Cookie 来帮助客户端在 Cookie 的生命周期内保持与同一目标的连接。粘性会话配置负载均衡器以将用户会话绑定到特定目标。这意味着在会话期间来自用户的所有请求都将发送到同一个目标。但是，随着时间的推移，这种关于连接的假设可能会导致不平衡。

粘性会话可能由于以下原因而失败：

• 注册的目标未生成 Cookie。
• 客户端未在请求标头中返回 Cookie。
• 这些 Cookie 的格式不正确。
• 基于时长的会话已结束。
• 会话请求通过多个负载均衡器。
• 目标运行状况变为不正常。
• AWS 服务关闭了粘性。

**注意：**在开始之前，请务必查看应用程序负载均衡器的粘性会话中的要求和注意事项部分。

解决方法

基于应用程序的会话粘性

1. 检查负载均衡器中是否存在 HTTP 错误。有关说明，请参阅应用程序负载均衡器故障排除。

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，请向实例 IP 地址发送 HTTP 请求，如下所示：

   [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 实用程序
   浏览器 Web 调试工具

   **注意：**如果您使用 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. 要检查来自同一用户的请求是否被路由到不同的注册目标，请查看您的弹性负载平衡 (ELB) 访问日志。有关说明，请参阅应用程序负载均衡器的访问日志。

8. 验证启用粘性的目标组下所有目标的运行状况是否正常。如果目标运行状况变为 unhealthy（不正常），则粘性会中断，负载均衡器不会将请求路由到该目标。然后，负载均衡器会自动选择一个新的运行状况良好的目标并建立粘性会话。即使运行状况为 unhealthy（不正常），负载均衡器也会继续将请求路由到新目标。有关运行状况检查的详细信息，请参阅应用程序负载均衡器目标组的运行状况检查。

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，则粘性不起作用。要验证客户端是否发送了 AWSALB Cookie，请在客户端上捕获数据包。要检索请求标头中的 Cookie 信息，请使用以下选项之一：

   来自 tcpdump 网站的 tcpdump
   来自 Wireshark 网站的 Wireshark 实用程序
   浏览器 Web 调试工具

   **注意：**如果您使用 AWS Support，请创建 HAR 文件来收集这些信息。由于 HAR 文件可以捕获敏感信息，例如用户名、密码和密钥，因此请确保从 HAR 文件中删除敏感信息。

3. 检查负载均衡器上配置的时长。如果 Cookie 已过期，则在负载均衡器发布新的 Cookie 之前，客户端会话将不再停留在注册的目标上。

4. 如果您的请求通过多个负载均衡器，请验证是否仅在一个负载均衡器上激活粘性。如果多个负载均衡器生成 Cookie，则负载均衡器会替换原始 Cookie，粘性就会失效。

对于经典负载均衡器，请参阅如何对经典负载均衡器会话粘性功能进行故障排除？

相关信息

为什么 Elastic Load Balancing 不平等地路由我的负载均衡器流量？

为您的经典负载均衡器配置粘性会话

如何为我的应用程序负载均衡器设置加权目标组？