如何使用 aws 应用程序在 ELB 中生成 session 粘性

how to use aws application generated session stickiness in ELB

我一直在纠结这个问题

我在 ELB 后面的两个 EC2 实例上实现了一个非常简单的 HTTP 服务器。 HTTP 服务器仅从 header 读取 cookie,并在响应 header 中使用相同的 cookie 发回响应。

在客户端,我使用

curl --cookie "mychannelid=mytest; Expires=Sat, 27-Jun-2017 02:48:17 GMT" --header "Accept-Language: en" "http://myelb.elb.amazonaws.com:8000/test"

此外,在 elb 上,我使用 cookie 名称 mychannelid 启用了应用程序粘性。但是当我运行这个系统时,我仍然得到50/50的服务器分配。我该如何实施?

另外一个信息是,如果在HTTP服务器上生成cookie,然后发回给客户端,同样,我需要用firefox访问HTTP服务器,那么我就可以得到我想要的。如果我用 curl 访问 HTTP 服务器,我不能。我不知道为什么,我检查了数据包,cookies 在 header.

当使用 Application-Controlled Session Affinity 时,ELB 在技术上不会根据您的应用程序 cookie 决定粘性,而是分配它自己的 AWSELB cookie ,类似于基于持续时间的 cookie,但与您的应用程序 cookie 具有相同的到期日期。因此,每当浏览器(或任何其他客户端)返回 ELB 时,它应该发送两个 Cookie 而不仅仅是应用程序 Cookie。

首先,我们需要一个常规的 curl,不像您使用 --cookie "mychannelid=mytest" 那样发送 cookie,而是将收到的 cookie 保存到名为 cookies.txt:[=26= 的文件中]

curl -c cookies.txt -v http://example.com/cookie.php 

(注意服务器上的cookie.php需要设置application cookie,对我来说,我叫它STICKINESSID并将值设置为tomtest31mar1030)

显示正在返回 cookie 的卷曲输出:

...
* Added cookie STICKINESSID="tomtest31mar1030" for domain example.com, path /, expire 1459525228
< Set-Cookie: STICKINESSID=tomtest31mar1030; expires=Fri, 01-Apr-2016 15:40:28 GMT
* Added cookie AWSELB="85937D8F08DC213046BA84053FDD6504FB203E36C25DA455A6835969F6D49F8DF9878D0F954A8EC75B8EE2AE208ECFE0AC2CE02E2EDE8DD014D2F17F4C80301EDBC4AE5CC3EBD730BD3127FF8DAAD636359B592B73" for domain example.com, path /, expire 1459525228
< Set-Cookie: AWSELB=85937D8F08DC213046BA84053FDD6504FB203E36C25DA455A6835969F6D49F8DF9878D0F954A8EC75B8EE2AE208ECFE0AC2CE02E2EDE8DD014D2F17F4C80301EDBC4AE5CC3EBD730BD3127FF8DAAD636359B592B73;PATH=/;EXPIRES=Fri, 01-Apr-2016 15:40:28 GMT
...

即创建了一个文件 cookies.txt,其中包含 STICKINESSIDAWSELB cookie:

$ cat cookies.txt 

#  Netscape HTTP Cookie File
# http://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

example.com FALSE   /   FALSE   1459525228  STICKINESSID    tomtest31mar1030
example.com FALSE   /   FALSE   1459525228  AWSELB  85937D8F08DC213046BA84053FDD6504FB203E36C25DA455A6835969F6D49F8DF9878D0F954A8EC75B8EE2AE208ECFE0AC2CE02E2EDE8DD014D2F17F4C80301EDBC4AE5CC3EBD730BD3127FF8DAAD636359B592B73

现在,有了保持粘性所需的两个 cookie,让我们测试在请求中发送它们:

$ for i in {1..20}; do curl --silent -b cookies.txt http://example.com/cookie.php | grep Instance; done
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
...

(假设http://example.com/cookie.php输出了一些调试信息,可以看到ELB后面实例的IP,可以测试粘性)

这表明,粘性在多个请求中得以保留。在没有 -b cookies.txt 的情况下尝试相同的测试以测试没有粘性。