集群中是否可以有多个 ASP.NET 状态服务器服务？
我们有一个 4 服务器集群，运行 ASP.NET Web 应用程序，使用 ASP.NET 状态服务器服务进行会话。 在 4 台服务器之一上，ASP.NET 状态服务器服务正在运行，其他服务器配置为查看此服务。 很多时候我们必须给服务器打补丁，而在状态服务器上应用补丁需要几分钟的停机时间。
有没有一种方法可以在集群中配置两个以上的 ASP.NET 状态服务器服务，这样如果一个服务出现故障，另一个服务就会接管？
We have a 4 server cluster running ASP.NET web application using ASP.NET State Server Service for session. On one of the 4 servers ASP.NET State Server Service is running and other servers are configured to look at this. Very often we have to patch the servers, and applying patch on the State Server requires few minutes of downtime.
Is there a way to configure more than two ASP.NET State Server Services in a cluster, so if one goes down, the other takes over?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会研究会话状态分区。 好的信息在这里：
http: //blog.maartenballiauw.be/post/2008/01/ASPNET-Session-State-Partitioning-using-State-Server-Load-Balancing.aspx
I'd look into Session State Partitioning. Good info here:
http://blog.maartenballiauw.be/post/2008/01/ASPNET-Session-State-Partitioning-using-State-Server-Load-Balancing.aspx
ASP Stateserver 不会从第一个节点复制会话。
但至少在下次重试时保持您的网络正常运行。
在MSCS集群环境下实现ASP状态服务的思考
ASP Stateserver does not replicate session from the 1st node.
But at least keeping your Web up and running on the next retry.
Thought of implementing the ASP State Service on a MSCS Clustered Environment
如果第一个 ASP.NET 状态服务器服务失败且不丢失第一个服务器上存储的部分会话信息，则第二个 ASP.NET 状态服务器服务无法接管。 新会话将由第二台服务器很好地处理。 要获得此行为，您需要设置会话状态分区（请参阅Jon Galloway 的回答）。
此行为是设计使然； ASP.NET 状态服务不会在服务器之间复制会话数据。
如果您需要将进程外会话数据复制到多个服务器，则必须使用其中一种商业产品（例如 ScaleOut）或等待 Microsoft Project Velocity 投入生产。 就我个人而言，我热切地等待 Velocity 的发布，一旦我对该产品充满信心，我就会从 ASP.NET 状态服务器切换到它。
此链接详细介绍了 ASP.NET 会话状态的 Velocity。
A second ASP.NET State Server Service cannot take over if the first one fails without losing the part of session info stored on the first server. New sessions will be handled fine by the second server. To get this behaviour you need to set up session state partitioning (see Jon Galloway's answer).
This behaviour is by design; the ASP.NET state service does not do replication of the session data between servers.
If you need out of process session data replicated to several servers you must either use one of the commercial offerings (ScaleOut, for instance) or wait for Microsoft Project Velocity to become production-ready. Personally I am eagerly awaiting the release of Velocity and will switch to it from ASP.NET state server as soon as I feel confident in the product.
This link has more on Velocity for session state for ASP.NET.