在没有停机的情况下在负载平衡的网站上进行部署时避免无效的视图状态 [英] Avoiding invalid viewstate when deploying on a load balanced website without downtime

问题描述

场景如下:

1. 我们有 3 个网络服务器 A、B、C.
2. 我们希望在不关闭应用程序的情况下发布应用程序的新版本
   (例如，不使用停机维护页面").
3. 服务器 A 使用最新代码上线.
4. 服务器 B 脱机.服务器 B 上的用户被路由到 A 和 C.
5. Page1.aspx 已更新为新控件.从服务器 B 到服务器 A 的任何人
   当他们在此页面上执行操作时，此页面上将出现视图状态错误.这是我们想要防止的.

你们中的一些人如何解决这个问题?

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 并进行更新.C 保留了旧代码.所有流量都将被定向到 C，这没关系，因为它是旧代码.当 A 和 B 与更新一起上线时，如果可能，告诉负载均衡器只保留在 C 上有活动会话的人，并且所有新会话都在 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.

如果这个假设是正确的，那么问题很可能是整个服务器场的机器密钥不一致.

If that assumption is correct then it is likely the issue is a inconsistent machinekey across the server farm.

ViewState 根据服务器的机器密钥进行散列，以防止客户端的用户篡改.机器密钥由 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.

为了确保您在用户在服务器之间移动时不会遇到视图状态验证问题，有两种可能的做法.

In order to ensure that you don't hit viewstate validation issues when users move between servers there are two possible courses of action.

1. 使用带有 false 值的 enableViewStateMac 属性在单个页面上或在 web.config 文件的 pages 元素中全局禁用防篡改保护.我提到这一点纯粹是为了完整性 - 您应该永远在生产网站上这样做.

手动生成一个机器密钥并在每个应用程序中共享相同的值(您可以对所有应用程序使用相同的密钥，但为每个应用程序使用一个密钥以最大限度地提高安全性是明智的)，在您的每个应用程序上服务器.为此，您需要生成密钥(不要使用您在 Internet 上的演示中可能看到的任何密钥，这违背了唯一机器密钥的目的)，这可以通过编程方式或在 IIS 管理器中完成(参见 http://www.codeproject.com/文章/221889/How-to-Generate-Machine-Key-in-IIS7).将网站部署到所有服务器时使用相同的机器密钥.

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.

这篇关于在没有停机的情况下在负载平衡的网站上进行部署时避免无效的视图状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！