问题描述
下面是该方案：
- 我们有3个Web服务器A，B，C。
- 我们要释放的应用程序的新版本没有采取申请下来结果
（例如，不使用停机维护页）。 - 服务器A与最新的code正式上线。
- 服务器B被带离线路。服务器B上用户路由到A和C。
- Page1.aspx的与新的控制更新。任何人都来自服务器B到服务器A，而结果
当他们执行此页面的动作此页面上会得到一个视图状态错误。这就是我们要prevent。
如何做一些你解决这个问题？
How do some of you resolve this issue?
这里有一些想法，我们有（无论是可能的，或者不使用我们的负载均衡器，我不知道......我不熟悉的负载平衡器配置[这是一个F5]）：
Here are some thoughts we had (whether it's possible or not using our load balancer, I don't know... I am not familiar with load balancer configuration [it's an F5]):
的更幼稚的做法：的
取下服务器A和B和更新。 Ç保留了旧code。所有车辆将被引导到C，这是很正常的，因为它是旧的code。当A和B更新去住，如果可能的话告诉负载平衡器只保留对下与活动会话人民和所有新的会话获得A和B发起这种方法的问题在于，在理论上会话可以坚持围绕如果用户保持使用应用了很长时间。
Take down servers A and B and update. C retains the old code. All traffic will be directed to C, and that's ok since it's the old code. When A and B go live with the update, if possible tell the load balancer to only keep people with active sessions on C and all new sessions get initiated on A and B. The problem with this approach is that in theory sessions can stick around for a long time if the user keeps using the application.
的越少幼稚的做法：的
类似于幼稚的做法，除了（如果可能的话）我们要谈的安全页面，这是没有改变的页面负载平衡器。当最终用户一个安全页面上结束了，他（或她）被发送到服务器A或B.从理论上讲，用户可能永远不会在这些网页上的一个土地，但这种做法是有点风险较小（但需要更多的工作）。
Similar to the naive approach, except (if possible) we tell the load balancer about "safe" pages, which are pages that were not changed. When the user eventually ends up on a "safe" page, he or she gets routed to server A or B. In theory the user may never land on one of these pages, but this approach is a little less risky (but requires more work).
推荐答案
我假设你的负载平衡器引导个人用户恢复正常操作期间Web场中的同一台服务器，这就是为什么你通常不会遇到此问题，但只有当你启动服务器之间将用户重定向。
I assume that your load balancer is directing individual users back to the same server in the web farm during normal operations, which is why you do not normally experience this issue, but only when you start redirecting users between servers.
如果这个假设是正确的，那么很可能这个问题是整个服务器农场的machineKey不一致
If that assumption is correct then it is likely the issue is a inconsistent machinekey across the server farm.
ViewState是散列针对服务器到prevent由在客户端上的用户篡改的机键。计算机密钥由IIS自动生成的，并且将改变每一服务器重启或复位时，以及作为唯一的每个服务器。时间
ViewState is hashed against the machine key of the server to prevent tampering by the user on the client side. The machine key is generated automatically by IIS, and will change every time the server restarts or is reset, as well as being unique to each server.
为了确保你不打的ViewState验证问题，当用户在服务器之间移动有作用的两种可能的课程。
In order to ensure that you don't hit viewstate validation issues when users move between servers there are two possible courses of action.
-
禁用单个页面或在全球范围内使用同一个假值的enableViewStateMac属性的web.config文件的页面元素的防篡改保护。我提到这纯粹是为了完整起见 - 你应该的从不这样做在生产网站
手动生成计算机密钥和共享在每个应用程序相同的值（你可以使用所有应用程序相同的密钥，但它是明智的使用每个应用程序一键最大化安全性），对您的每一个服务器。要做到这一点，你需要生成密钥（做的不可以使用任何你可以在互联网上的演示看，这违背了独特的机械按键的目的），这可以通过程序或在IIS管理器中进行（看到）。使用部署网站，所有服务器时，在同一台机器密钥。
Manually generate a machine key and share that same value across each application (you could use the same key for all your applications, but it is sensible to use one key per application to maximise security), on each of your servers. To do this you need to generate keys (do not use any you may see in demos on the internet, this defeats the purpose of the unique machine key), this can be done programatically or in IIS manager (see http://www.codeproject.com/Articles/221889/How-to-Generate-Machine-Key-in-IIS7). Use the same machine key when deploying the website to all of your servers.
我不能在最佳实践回答了升级要求用100％的正常运行时间的应用程序。
I can't answer on the best practice for upgrading applications that require 100% uptime.
这篇关于无需停机的负载均衡部署网页时避免无效的ViewState的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！