使用 IIS NLB 时如何将用户请求保留在同一服务器上？
我有两台使用 NLB 运行的 IIS 服务器。 不幸的是，我无法使用共享会话服务器，因此每个服务器都使用自己的会话。 如何确保来自同一用户的所有请求都转发到同一 IIS 服务器？
I have two IIS servers running using NLB. Unfortunatelly I cannot use shared session server, so every server is using its own session. How can I ensure, that all requests from the same user are forwarded to the same IIS server?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
发现这个并决定与其他人分享：
使用客户端亲和力功能。 启用客户端关联性后，网络负载平衡会将所有 TCP 连接定向到同一群集主机。 这允许在主机内存中维护会话状态。 您可以在网络负载平衡管理器的“添加/编辑端口规则”对话框中启用客户端关联。 选择“单一”或“C 类”关联性，以确保只有一台群集主机能够处理属于同一客户端会话的所有连接。 如果集群主机上运行的服务器应用程序维护连接之间的会话状态（例如服务器 cookie），这一点非常重要。 有关网络负载平衡关联性的详细信息，请参阅网络负载平衡管理单元中的帮助。
Found this and decided to share with others:
Use the client affinity feature. When client affinity is enabled, Network Load Balancing directs all TCP connections to the same cluster host. This allows session state to be maintained in host memory. You can enable client affinity in the Add/Edit Port Rules dialog box in Network Load Balancing Manager. Choose either Single or Class C affinity to ensure that only one cluster host will handle all connections that are part of the same client session. This is important if the server application running on the cluster host maintains session state (such as server cookies) between connections. For more information about Network Load Balancing affinity, see Help in the Network Load Balancing snap-in.
我认为您正在寻找的是粘性会话。 不过，粘性会话是由负载均衡器实现的。 您可能需要设置一个可以执行粘性会话的外部负载均衡器（BIG-IP、HAProxy 等）。
I think what you're looking for is Sticky Sessions. Sticky sessions are implemented by your load balancer though. You probably need to setup an outside load balancer (BIG-IP, HAProxy, etc.) that can do sticky sessions.
只要您的客户没有使用分布式代理系统，您就可以轻松做到这一点：
在 NLB 集群的 protieries 中，选项卡“端口规则”您可以选择“过滤模式”和关联性：
您不能选择“无”，因为您没有中央会话。
但“简单”会将每个用户重定向到同一服务器，只要 IP 保持不变。
例如，如果您预期 AOL 代理服务器，那么“C 类”可能是一个安全的选择（尽管可能会稍微减少负载平衡），因为相同的 C 类网络连接到同一服务器。
我想这很容易由 MS 实现，两台主机都知道哪个 ip 是偶数或奇数，或者 C 类网络的哪个三元组是偶数或奇数，并且根据 IP 地址始终以相同的方式分配负载
You can do that easily as long as none of your customers use a distributed proxy system:
In the protieries of the NLB cluster, tab "port rules" you can choose the "filtering mode" and the affinity:
You cannot choose "none" because you don't have central sessions.
But "simple" would redirect every user to the same server as long as the ip stays the same.
If you e.g. anticiapte AOL proxy servers then "class C" might be a secure choice (albeit maybe reducing the load balancing a little bit), because the same class C net goes to the same server.
I guess that is easily implemented by MS in a way that both hosts know which ip is even or odd or which triplet of the class C net is even or odd and distribute the load always in the same way depending on the IP-address
你为什么想做这个？ 如果是因为会话状态，那么您应该在公共位置设置数据库或进程外服务器，并让所有节点引用它。
Why would you want to do this? If it's because of session state then you should have a database or out-of-process server set up in a common place and have all nodes reference that.
我会考虑在任一服务器前面设置一个反向代理，并记住哪些外部用户正在使用哪些服务器。
我知道（通过这种方式使用它） Cherokee 支持 IPHash 代理，但我确信有很多更多的。
I would consider a reverse proxy that sits in front of either server and remembers which external users are using which servers.
I know (from using it this way) Cherokee supports IPHash proxying but I'm sure there are lots more.
只是为了补充劳埃德的答案，无论如何，您都应该避免在负载平衡环境中使用会话。 使用会话的全部目的是避免数据库调用； 如果您最终将会话数据存储回数据库，您通常什么也得不到。
原因是 1. 您现在必须为每个页面加载（检索和存储）进行 2 次数据库调用，2. 该数据现在必须经过序列化/反序列化边界。 大多数时候，这最终会成为比仅仅检索您想要开始的数据更昂贵的操作。
现在，回答你的实际问题。 您可以选择将会话数据存储在视图状态中。 您也可以选择放弃会话并使用 cookie。 如果您走这条路，请务必在发出时对其进行加密，并在接收时对其进行解密。
Just to add to Lloyd's answer, you should avoid using session in a load balanced environment anyway. The whole purpose behind using session is to avoid database calls; if you end up storing the session data back into the database you usually gain nothing.
The reason being that 1. you now have to make 2 database calls for each page load (retrieve and store) and 2. that data now has to go through serialization / deserialization boundaries. Most of the time this ends up being a more expensive operation than just retrieving the data you wanted to begin with.
Now, to your actual question. You do have the option to store the session data in the view state. Optionally, you could forgo session and instead use cookies. If you go this route, be sure to encrypt them on the way out and decrypt when receiving them.