cookie 如何与非持久性负载均衡器一起工作

Question

我们有一个 Drupal 应用程序，它使用 sso 来登录用户。

我们正在使用 AWS 经典负载均衡器 (ELB)，AWS 告诉我们 ELB 上没有会话持久性。

我想弄清楚的是 cookie 如何在经典负载均衡器上与非持久性一起工作。

example.com DNS 指向 ELB。池 Server1 和 Server2 中有 2 台服务器

我们想要发生的是，如果用户http://example.com/user/12345/在服务器 1上点击他们的主页，如果他们尚未登录，他们将被重定向到 sso 页面http://example.com/user/login/sso，自动登录并获取 cookie SESS<hexnumber>，然后重定向回http://example.com/user/12345/

我们不允许添加任何会话服务器（redis），以保证它们将保留在服务器 1 上进行两次重定向。

据我所知，每次点击“example.com”时，用户最终都可能在服务器 1 或服务器 2 上。

我的问题：

如果他们在 server1 上获得了 cookie，然后被重定向到 server2，那么 server2 如何知道 cookie 已经分配给 server1 上的那个用户？

我似乎在思考自己的圈子。过去在使用没有会话持久性的 LB 进行此类设置时，我们使用了一个 redis 服务器来保存会话，并且每个请求都会查看 redis 服务器以获取会话信息。

Answer 1

cookie是在浏览器中设置的，而不是在服务器中设置的。它仅限于某个域以及 URL 中的特定路径（可选），因此只要两台服务器都由同一域访问，cookie 就会存在。

如果 cookie 指向会话，则 server1 和 server2 都必须能够以某种方式访问​​该会话。如果会话无法在服务器之间共享，那么您需要强制用户保留到特定服务器。这可以通过 DNS 和一点 URL 重写魔法轻松完成：

• www.example.com 指向两个服务器。
• www1.example.com 仅指向 server1
• www2.example.com 仅指向 server2

使用一组简单的重写规则和 cookie，用户可以被锁定到特定的服务器，确保他的会话持续存在。

以下是更多详细信息。

域名系统：

• example.com A 1.1.1.1、A 2.2.2.2
• www.example.com CNAME example.com
• www1.example.com A 1.1.1.1
• www2.example.com A 2.2.2.2

重写规则：

• 持久性cookie：“后端”
• 初始连接：“后端”未定义，将“后端”设置为 www1 或 www2，具体取决于哪个服务器已应答并重定向到该服务器。cookie 必须设置为域“example.com”，这样它将在 www1 和 www2 上加载
• 如果定义了“backend”，请确保其值与服务器实例匹配，并在必要时进行重定向。
• 确保会话 cookie 是在服务器的完整域名中定义的 - 即 www1.example.com 或 www2.example.com

重写逻辑将在 Web 服务器本身中定义。所有现代 Web 服务器都具有功能非常强大的重写语言，完全能够实现此功能。