我们计划对 10 台 .NET 3.5 Web 服务器进行负载平衡。我们使用 SQL 2008 会话状态服务器进行会话管理。
我们需要什么来平衡 .NET Web 服务器的负载？
到目前为止我们已经确定的情况：
- 网络内容需要相同。
- 会话状态服务器将需要指向相同的 SQL 2008 以获取会话状态信息。
- web.config 文件中的机器密钥需要相同。
答案1
如果您实际上要从单服务器环境转向 10 个负载平衡集群，那么这对我来说立即敲响了警钟。我有很多问题，希望您已经弄清楚了，但无论如何我都会指出这些问题，然后提供一些一般性注意事项。
您是如何得出 10 这个数字的？为什么不扩展到 2 或 3，然后根据需要添加更多？
你为什么要首先进行负载平衡？例如，你是要实现高负载、高可用性，还是两者兼而有之？是否有迫切需求，还是有预测性需求？
如果您现在处于负载状态，并试图通过扩展来解决它，我想问的一个大问题是，您是否真的确定了瓶颈。您提到您正在使用 .NET 和 SQL 来实现会话状态，所以我猜您也在使用 SQL 支持的应用程序。您是否也在平衡 SQL 服务器？SQL 服务器可以处理您现在拥有的 10 倍连接吗？
如果您追求可用性，您是否考虑过所有其他故障点？您的负载均衡器是否有冗余？您的数据库服务器是否有冗余？您的互联网上行链路是否有冗余（考虑所有点：单根电缆、单台交换机等）？对于可用性，您的安全性取决于最薄弱的环节。如果您只有一台数据库服务器并且它发生故障，那么无论您有 10 台还是 100 台前端 Web 服务器都无济于事。
很多时候，瓶颈就是数据库服务器。如果是这样，那么有多少个前端就不重要了。
如果您使用 SSL，则负载均衡器通常以两种典型模式运行，这会影响 SSL 的工作方式：
- 第 4 层：这是 TCP 层。SSL 由每个服务器处理，因此必须在每台服务器上安装 SSL 证书。
- 第 7 层：这是应用程序级别，也称为反向代理。负载均衡器处理 HTTP 会话，并与应用程序服务器建立第二个连接。在此模式下，SSL 证书仅安装在均衡器上，与应用服务器的连接通常为 HTTP。这有时称为“SSL 卸载”，如果您的负载均衡器功能强大，并且您不希望应用服务器处理 SSL 的加密开销（例如，您的应用占用大量 CPU），则这通常很有用。
确保平衡器已设置为在服务器发生故障时将其从轮换中移除，并测试此功能。您应该能够关闭服务器而不会影响其余服务器。注意 PING 与 HTTP 与响应时间检查。（Ping 并不意味着 HTTP 正在响应）
对您的环境进行负载测试。您可能无法全力以赴，但您应该能够至少加载几台服务器（平衡器中只有这两台）。
运行暂存环境。这可能不是 10 台服务器，但应该足以复制生产系统以进行部署测试。
拥有一个自动部署脚本，并严格执行源代码管理和配置管理。理想情况下，这意味着所有内容（包括配置文件）都在源代码控制系统中，并且您拥有自动构建功能，可以创建安装程序/脚本等所有内容。
获取一个可以监控面向外部的网站和所有内部服务器的工具。如果一台服务器宕机，从外部世界的角度来看并没有什么变化，但无论如何你都想知道并修复服务器。如果你确实开始遇到性能或可用性问题，你肯定不想发现 3 台服务器已经宕机一个月，而其余服务器正在努力应对额外的负载。