适当设置需要粘性会话的负载均衡网络？

Question

我在这个问题上找到了很多q＆amp; a，但我还没有找到适合我们服务器的配置。背景是：我们在负载均衡器后面有两个Web服务器，并且必须确保用户不会丢失其会话。

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

据我了解，必须确保以下内容：

• 在两台Web服务器上设置相同的机器密钥。
• 使用预编译的站点，以便程序集在两台计算机上获得相同的命名。
• 我们要么必须在ip-number或cookie上设置粘性会话（后者是首选的）

是否有必要预编译网站？ （我知道它更快，但我们失去了一些灵活性）

由于我们有粘性会话，使用相同的机器密钥只会影响用户会话超时并且因此他/她最终在另一台服务器上的情况（这意味着包含视图状态的回发信息可能无效）是否正确除非他们有相同的机器密钥？）

Answer 1

您在所有方面都是正确的 - LB上的粘性会话将确保在后续请求中点击相同的Web服务器，因此可以使用正确的进程内会话状态。但是，LB粘性必须与（或应该更多）与ASP.NET会话的超时值匹配。例如，如果LB使用cookie进行粘性，那么cookie的到期时间应该大于ASP.NET会话的时间。

相同的机器密钥参数对于请求的回发因任何原因转到其他服务器的情况很有用。客户端状态（例如视图状态和事件验证，可能是身份验证票证）使用机器密钥加密，因此具有相同的密钥可确保任何服务器都可以为后备提供服务。在旁注中，在所有Web场景中，在所有Web服务器上具有准确的S / W环境（以及可能的H / W环境）以避免任何意外，这是100％有意义。

需要预先编译网站以避免序列化冲突 - 序列化/反序列化时类型名称必须相同。因此，您无法从动态生成的程序集中获得序列化类型，并且每次编译都可以避免这种情况。 IMO，这更有可能影响视图状态存储而不是会话状态（因为您的会话状态是任何不共享的方式，并且在第二台服务器上不可用）。最后，如果您不使用网站而不是使用Web应用程序项目，那么这一点或多或少变得无关紧要，因为在构建项目时，代码文件无论如何都会被编译。只有页面（标记）会被动态编译，并且标记中可序列化类型的几率几乎为零（无论如何听起来都是坏主意）。