Windows 2008 和 SQL Server 2008 的最佳负载平衡配置
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/573466/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Best load balance configuration with Windows 2008 and SQL Server 2008
提问by holiveira
I have two servers running Windows 2008 Web Edition and SQL 2008 Standard Edition, how would be the best approach to load balance them?
我有两台运行 Windows 2008 Web 版和 SQL 2008 标准版的服务器，负载平衡它们的最佳方法是什么？
Should I use database mirroring or log shipping? Is Win2008 NLB easy to configure by a developer, since I'm not a sys admin?
我应该使用数据库镜像还是日志传送？由于我不是系统管理员，开发人员是否可以轻松配置 Win2008 NLB？
What I'm looking for is to be able to have my sites running in case of a single server malfunction, and also to be able to easily add more servers if the demand grows. My sites runs in ASP.Net 3.5 and all of them already store the session in SQL Server.
我正在寻找的是能够在单个服务器出现故障的情况下运行我的站点，并且在需求增长时能够轻松添加更多服务器。我的站点在 ASP.Net 3.5 中运行，并且所有站点都已将会话存储在 SQL Server 中。
回答by Brent Ozar
SQL Server by itself doesn't support load balancing. You can have active/passive failovers with the mechanisms you described (database mirroring and log shipping) and there's a lot of other options as well, like clustering or replication.
SQL Server 本身不支持负载平衡。您可以使用您描述的机制（数据库镜像和日志传送）进行主动/被动故障转移，还有很多其他选项，例如集群或复制。
The two questions to start with are:
首先要回答的两个问题是：
- How long can you afford to be down? (aka your Recovery Time Objective, or RTO)
- How much data can you afford to lose? (aka your Recovery Point Objective, or RPO)
- 你能承受多久的痛苦？（又名您的恢复时间目标，或 RTO）
- 您可以承受丢失多少数据？（又名您的恢复点目标，或 RPO）
The more time you can afford to be down and the more data you can afford to lose, then the easier and cheaper solutions become to implement. The less downtime and less data, the tougher it is to implement.
您可以承受的停机时间越长，损失的数据就越多，那么实施的解决方案就越容易、成本更低。停机时间和数据越少，实施起来就越困难。
For example, synchronous database mirroring will guarantee that you never lose a transaction. Transactions are committed on both database servers before the result is returned to the client. Unfortunately, you suffer a pretty big performance impact under heavy loads, and there's minimal management utilities built in - you want to have a full time DBA to manage this kind of thing.
例如，同步数据库镜像将保证您永远不会丢失事务。在将结果返回给客户端之前，事务会在两个数据库服务器上提交。不幸的是，您在重负载下会遭受相当大的性能影响，并且内置了最少的管理实用程序 - 您希望有一名全职 DBA 来管理此类事情。
At the other extreme, log shipping every 15 minutes would mean that you could lose 15 minutes of data (or more) and it might take 15-60 minutes to get back online after a failure. However, it's cheap, has a very low performance impact and it's fairly easy to set up.
在另一个极端情况下，每 15 分钟传送一次日志意味着您可能会丢失 15 分钟（或更多）的数据，并且在发生故障后可能需要 15-60 分钟才能重新联机。然而，它很便宜，对性能的影响非常低，而且很容易设置。
I've got a RPO and RTO introductionover on BrentOzar.com, and an introduction to SQL Server's HA and DR features. If you go through those, you'll be better armed to come back and ask more specific questions. Hope that helps!
我在 BrentOzar.com 上有RPO 和 RTO 介绍，以及SQL Server 的 HA 和 DR 功能介绍。如果你经历了这些，你会更好地回来问更具体的问题。希望有帮助！
回答by Mladen Prajdic
depending on your application type the first thing you should do is start caching things that don't change much on the web server. this way your database will get hit less. and web servers are way easier to scale that databases.
根据您的应用程序类型，您应该做的第一件事是开始缓存在 Web 服务器上没有太大变化的内容。这样你的数据库就会受到更少的打击。和 Web 服务器更容易扩展该数据库。
