需要粘性会话的负载均衡Web的正确设置方式是什么？

Question

需要粘性会话的负载均衡Web的正确设置方式是什么？

asp.netiisload-balancing

6

我在这个主题上找到了许多问答，但我仍然没有弄清楚我们服务器的正确配置。背景如下：我们有两台 Web 服务器位于负载均衡器后面，必须确保用户不会丢失他们的会话。

Web 服务器为 IIS7/ASP.NET 4。
我们目前无法设置单独的会话状态服务器，因此必须在 LB 上使用粘性会话。

据我所知，必须确保以下内容：

在两台 Web 服务器上设置相同的机器密钥。
使用预编译站点，以便在两台机器上获得相同的程序集命名。
我们必须将粘性会话基于 IP 地址或 cookie（后者更可取）。

是否需要预编译站点？（我知道这样做更快，但我们会失去一些灵活性）

由于我们有粘性会话，因此是否正确地认为只有在用户会话超时并因此被转到另一台服务器时（这意味着包含视图状态的回发可能无效，除非它们具有相同的机器密钥），才会影响相同的机器密钥？

- Sten

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VinayC · Accepted Answer

您的所有观点都是正确的 - 负载均衡器上的粘性会确保在后续请求中命中相同的Web服务器，因此可以使用正确的进程内会话状态。然而，负载均衡器的粘性必须与ASP.NET会话的超时值匹配（或者应该更长）。例如，如果LB使用cookie进行粘性，则cookie到期时间应该比ASP.NET会话的到期时间更长。

相同的机器密钥参数对于请求的后退发送到其他服务器的情况非常有用。客户端状态（例如视图状态和事件验证，可能是身份验证票证）使用机器密钥进行加密，因此具有相同的密钥可确保任何服务器都可以提供后退服务。另外，在所有Web农场方案中，将所有Web服务器上的确切S/W环境（以及可能的H/W环境）保持一致，以避免任何意外情况，这是有100％的意义的。

需要对网站进行预编译以避免序列化冲突 - 在序列化/反序列化时类型名称必须相同。因此，您不能从动态生成的程序集中获取序列化类型，并且通过编译可以避免这种情况。在我看来，这更可能会影响视图状态存储而不是会话状态（因为您的会话状态无论如何都不共享，并且在第二个服务器上不可用）。最后，如果您没有使用网站而是使用Web应用程序项目，则此点变得更加无关紧要，因为构建项目时代码文件将被编译。只有页面（标记）将被动态编译，并且在标记中具有可序列化类型的机会几乎为零（并且听起来也不是一个好主意）。