如何对 Classic Load Balancer 会话粘性功能进行问题排查？

上次更新日期：2018 年 3 月 30 日

默认情况下，Classic Load Balancer 会将每个请求路由至具有最少未完成请求的注册实例。使用粘性会话（会话绑定）时，会将负载均衡器配置为将用户会话绑定到特定实例，因此用户在会话期间发出的所有请求会被发送至同一个实例。如果出现以下情况，粘性会话可能会失败：

1.    注册实例未插入应用程序 Cookie。

2.    客户端没有返回请求标头中的 Cookie。

3.    注册实例插入的 Cookie 格式有误。

4.    使用基于持续时间的粘性会话时，指定的有效期过期。

5.    HTTP 或 HTTPS 请求正在通过多个已启用粘性功能的负载均衡器。

注意：只有 HTTP 或 HTTPS 侦听器支持负载均衡器会话粘性功能。

应用程序控制的会话粘性

1.    检查 Classic Load Balancer 是否存在 HTTP 错误。有关更多信息，请参阅对 Classic Load Balancer 进行问题排查：HTTP 错误。

2.    运行与以下负载均衡器 DNS 名称类似的命令。检查响应中的这两个 Cookie： 

• 应用程序 Cookie 由在后端实例上运行的应用程序插入。
• AWSELB Cookie 由负载均衡器插入。

注意：在运行此命令之前，请务必将 DNS 名称替换为负载均衡器的名称。

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

注意：尽管 curl 实用程序是 Linux 的本机工具，但也可以安装在 Windows 上。

以下是对该命令的响应示例：

...

< Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/
< Set-Cookie: 
AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

注意：如果响应中没有 AWSELB Cookie，则客户端和后端实例之间没有粘性。 

3.    通过运行与以下内容类似的命令，直接向注册实例 IP 发送 HTTP 请求，以验证注册实例是否正在插入应用程序 Cookie： 

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

该命令会返回与以下示例类似的响应：

...

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

...

4.    验证由注册实例生成的 Cookie 名称是否与负载均衡器上配置的 Cookie 名称相同。 

5.    如果注册实例在其响应中插入应用程序 Cookie，并且负载均衡器插入 AWSELB Cookie，请确保客户端在后续请求中同时发送这两个 Cookie。如果客户端无法包括应用程序或 AWSELB Cookie，则粘性无效。要验证客户端是否同时发送了应用程序和 AWSELB Cookie，请在客户端上捕获数据包或使用浏览器的网络调试工具检索请求标头中的 Cookie 信息。

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 访问日志，以检查来自同一用户的请求是否已被路由至不同的注册实例。有关查看 ELB 访问日志的更多信息，请参阅 Classic Load Balancer 的访问日志。 

8.    验证应用程序插入的 Cookie 是否针对 HTTP 设置了正确格式。

9.    如果请求通过多个负载均衡器，请验证粘性是否仅在一个负载均衡器上启用。如果某个 Cookie 由多个负载均衡器插入，它将替换原始 Cookie，并且粘性失效。 

基于持续时间的会话粘性

1.    运行与以下负载均衡器 DNS 名称类似的命令，以检查响应中是否有 AWSELB Cookie： 

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

该命令会返回与以下示例类似的响应：

...

< Set-Cookie: 
AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

注意：如果响应中没有 AWSELB Cookie，则客户端和后端实例之间没有粘性。

2.    如果负载均衡器插入了 AWSELB Cookie，请确保客户端在后续请求中发送此 Cookie。如果客户端无法包括 AWSELB Cookie，则粘性无效。要验证客户端是否发送了 AWSELB Cookie，请在客户端上捕获数据包，或使用浏览器的网络调试工具检索请求标头中的 Cookie 信息。

3.    检查负载均衡器上配置的持续时间。如果 Cookie 的有效期已过，则在负载均衡器发出新的 Cookie 之前，客户端会话将不再停留在注册实例上。

4.    如果请求通过多个负载均衡器，请验证粘性是否仅在一个负载均衡器上启用。如果某个 Cookie 由多个负载均衡器插入，它将替换原始 Cookie，并且粘性失效。