我的 Classic 负载均衡器会话粘性属于基于持续时间应用程序控制的会话粘性。负载均衡器配置为将客户端 HTTP 或 HTTPS 会话路由至相同的已注册实例,而将客户端请求路由至不同的已注册实例。如何排查有关 Elastic Load Balancing (ELB) 会话粘性的问题?

在默认情况下,Classic 负载均衡器会将每个请求都路由至待处理请求最少的已注册实例。使用粘性会话 (会话关联) 会将负载均衡器配置为将用户会话与特定实例绑定,从而确保在会话期间来自一个用户的所有请求都发送至同一实例。如果发生下列情况,粘性会话可能失败:

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

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

3.    已注册实例插入的 Cookie 格式不正确。

4.    使用基于持续时间的会话粘性时规定的有效期限已经过期。

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

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

应用程序控制的会话粘性

1.    使用 Classic 负载均衡器检查 HTTP 错误。有关更多信息,请参阅对 Classic 负载均衡器进行故障排除: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。 如果客户端未在请求包含应用程序 Cookie 或 AWSELB Cookie,则粘性功能将不会工作。如要验证客户端同时发出了应用程序 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 负载均衡器的访问日志

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,粘性功能将会失败。 


此页面对您有帮助吗? |

返回 AWS Support 知识中心

需要帮助? 请访问 AWS 支持中心

发布时间:2018 年 3 月 30 日