陷阱：从单一服务器升级到网络场
我们公司目前运行两台 Windows 2003 服务器（一台 Web 服务器和一台 MSSQL 8 数据库服务器）。 我们计划在网络场设置中添加另外几台服务器以实现冗余/可用性目的。 我们的网站主要是 ASP.NET，也有一些 PHP 网站，但这些网站主要是静态的，没有数据库。
经历过这个过程的人是否有任何问题或我应该注意的其他要点？ 对于这种情况，使用 Windows Server 2008 是否会提供任何额外的优势（这样我就可以说服我的老板进行升级:)？
谢谢。
Our company currently runs two Windows 2003 servers (a web server & a MSSQL 8 database server). We're planning to add another couple of servers for redundancy / availability purposes in a web farm setup. Our web sites are predominately ASP.NET, we do have a few PHP sites, but these are mainly static with no DB.
Does anyone who has been through this process have any gotchas or other points I should be aware of? And would using Windows Server 2008 offer any additional advantages for this situation (so I can convince my boss to upgrade :) ?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您有动态负载平衡（即我的第一个请求发送到服务器 X，但我的下一个请求可能发送到服务器 Y 或 Z），您会发现进程内会话不起作用。 因此，您要么需要粘性会话（您的负载均衡器总是将我（=我的会话）发送到服务器 X），要么需要进程外会话（即存储在 SQL Server 中）。
If you have dynamic load balancing (i.e. My first request goes to server X, but my next Request may go to server Y or Z), you will find out that In-Proc Sessions do not work. So you will either need sticky Sessions (your load balancer will ALWAYS send me (=my session) to server X) or out-of-process sessions (i.e. stored in an SQL Server).
就像迈克尔说的，你需要照顾好你的会议。 理想情况下，应使其精简并在流程外存储。 根据您使用缓存的方式，您将面临类似的缓存挑战，并且如果您只使用 asp 缓存，您可能有兴趣寻找更强大的缓存技术。
不要忘记 web.config 中的机器密钥和验证等内容。 机器密钥需要在您的服务器之间保持一致。
阅读 IIS7，您应该能够挑选出几个好的示例向您的老板炫耀。
网络场可以为您带来不容忽视的部署机遇和挑战。
对上述设置没有具体经验，但对此类一般动作没有经验。 我建议分阶段实施该方法。 也就是说，先迁移到 Windows 2008，然后再进行场处理。
Like Michael says, you'll need to take care of your session. Ideally make it lean and store out of process. You'll have similar challenge with cache depending on how you use it and might be interested in looking towards a more robust caching technology if you only use asp caching.
Don't forget things like machine keys and validation in your web.config. The machineKeys need to be consistant across your servers.
Read up on IIS7 and you should be able to pick out several good examples to show off to your boss.
A web farm can give you opportunities and challenges with deployment that should not be overlooked.
Without specifc experience to the setup above but to general moves of this kind. I would recommend phasing the approach. That is, move to Windows 2008 first and then farm.
另一件需要注意的事情是您的部署计划。 可悲的是，部署计划似乎被忽视和/或低估。 请记住，您正在部署到多个节点，并且您需要考虑如何以逻辑方式进行部署和测试。
例如，假设您的场中有四个节点。 您是否从集群中拉出两个并更新和测试，然后交换另外两个以重复？ 确定您当前的部署过程是否符合您提供的答案。 仅仅因为您拥有 X 倍的服务器数量并不意味着您想要或需要执行 X 倍的工作量。
只是暂时回顾一下对话的缓存部分。 您绝对应该考虑一下分布式缓存解决方案。 如果您预先缓存数据并使用带有缓存删除的回调，那么如果您不小心，您真的可能会对数据库造成冲击。 此外，许多分布式缓存解决方案还提供某种程度的会话状态管理。 我非常喜欢 Microsoft 的 Velocity 项目，尽管它只是第二个 CTP 版本，尚未准备好投入生产。
One additional thing to look at is your deployment plan. Deployment plans seem to be sadly overlooked and/or undervalued. Remember that you are deploying to multiple nodes and you want to take into account how you want to deploy and test in a logical fashion.
For example, assume you have four nodes in your farm. Do you pull two out of the cluster and update and test, then swapping out the other two to repeat? Determine if your current deployment process fits in with the answer you provide. Just because you have X times the amount of servers does not mean that you want or need to do X times the amount of work.
Just revisiting the caching part of the conversation for a moment. You should definitely take a look at a distributed caching solution. If you are pre-caching data and using callbacks with cache removals, you can really put a pounding on the database if you are not careful. Also, a lot of the distributed caching solutions offer some level of session state management, as well. I have been very much enjoying Microsoft's Velocity project, although it is just a second CTP release and not ready for production.
除了其他人所说的之外，您可能还需要考虑研究 Richard Campbell（.NET Rocks！）的产品：
http ://www.strangeloopnetworks.com/
In addition to what others have said, you might want to consider looking into Richard Campbell's (of .NET Rocks!) product:
http://www.strangeloopnetworks.com/
我们使用 ASP.NET 状态服务器来处理会话。 Windows Server 2003/2008 中免费提供此功能。
然后，我们必须确保机器密钥相同（web.config 文件中的设置）。
然后，我手动使每个站点脱机（使用 app.offline 或任何调用的魔术文件）。 或者，您可以使用 IIS，然后关闭该站点并“打开”脱机站点。
就是这样。 您可能会担心分布式缓存，但这是非常核心的事情。 您可以从 ASP.NET 的默认输出缓存中获得很多好处。 如果您打算进行分布式缓存，那么在您深入研究复杂性（以及某些产品的成本）之前，我将从这里开始。
哦，我们使用的 F5 负载均衡器不执行粘性会话，因此我们需要维护会话......这就是我们使用 ASP.NET 状态服务器的原因。
We use the ASP.NET State Server for handling out sessions. This comes free with windows server 2003/2008.
We then have to make sure the machine key's are the same (a setting in your web.config files).
I then manually take each site offline (using app.offline or whatever the magic file is called). Alternatively, u can use IIS and just turn the site off and the offline site 'on'.
That's about it. You could worry about distributed caching, but that's pretty hard-core stuff. You can get a lot of good millage out of the default Output Caching with ASP.NET. I'd start there, before you delve into the complexity (and cost, for some products) if you're going to do distributed caching.
Oh, we're using an F5 load balancer that does NOT do sticky sessions, so we need to maintain our sessions .. which is why we're using the ASP.NET state server.
除了其他发帖者描述的会话问题之外，另一个问题是应用程序是否正在写入本地文件系统。 如果应用程序假设文件位于本地 PC 上，则扩展到网络场会破坏应用程序。 例如，上传的文件可能可用或不可用，具体取决于哪个服务器被命中。 更改路径以指向共享驱动器应该可以解决此问题。
One other gotcha aside from the Session issues described by the other posters is if the apps are writing to the local file system. Scaling out to a web farm would break the apps if they assume the files are on the local PC. For example, uploaded files might be available or not depending on which server is hit. Changing the paths to point to a shared drive should fix this.