负载平衡.NET 3.5 Web服务器的要求

如果你真的从一个单一的服务器环境转到一个10的负载平衡的集群，立即为我设置一系列警告。 我有一堆你已经想到的问题，但我会指出，然后提供一些通用的考虑。

你是怎么到达10号的？ 为什么你不缩放到2或3，并根据需要添加更多？

为什么要首先进行负载平衡？ 例如，你要高负荷，高可用性还是两者？ 有没有急需，还是这是一个预测需求？

如果你现在处于负载状态，并试图扩大规模来解决这个问题，那么我会问的一个大问题是，如果你确实已经确定了瓶颈。 你提到你使用的是.NET，而SQL是用于会话状态的，所以我猜你也在使用SQL支持的应用程序。 你是否也在平衡SQL服务器？ SQL服务器可以处理10倍你现在拥有的连接吗？

如果您要提供可用性，是否考虑过所有其他故障点？ 你的负载均衡器有冗余吗？ 你的数据库服务器有冗余吗？ 你的互联网上行链路是否有冗余（考虑所有的点：单线，单开关等）？ 对于可用性，您只能像最薄弱的环节一样安全。 如果您只有一台数据库服务器，并且该服务器停机，那么是否有10甚至100台前端Web服务器并不重要。

很多时候你的瓶颈将是你的数据库服务器。 如果是这样的话，你有多less前端并不重要。

• 如果您使用的是SSL，则有两种典型的负载均衡器通常在其中运行，这会影响SSL的工作方式：

  • 第4层：这是TCP级别。 SSL由每台服务器处理，因此必须在每台服务器上安装SSL证书。
  • 第7层：这是应用程序级别，也称为反向代理。 负载平衡器处理HTTP会话，并与应用程序服务器build立第二个连接。 在这种模式下，SSL证书只安装在平衡器上，与应用服务器的连接通常是HTTP。 这有时称为“SSL卸载”，如果您的负载均衡器function强大，并且您不希望应用程序服务器处理SSL的encryption开销（例如，您的应用程序是CPU密集型的），则通常很有用。

• 确保您的平衡器设置为在服务器closures时使服务器停止旋转，并testing此function。 您应该能够停止服务器，而不会影响其余的服务器。 注意PING vs HTTP与响应时间检查。 （Pinging并不意味着HTTP正在响应）

• 加载testing你的环境。 你可能无法全力以赴，但你至less应该装载几台服务器（平衡器中只有这两台服务器）。

• 运行临时环境。 这可能不是10台服务器，但应该足以复制生产系统进行部署testing。

• 有一个自动化的部署脚本，并对源代码pipe理和configurationpipe理非常严格。 理想情况下，这意味着一切（包括configuration文件）都在一个源代码控制系统中，并且你有自动化的构build来创build一切，直到你的安装程序/脚本。

• 获取一个工具来监视外部站点和所有内部服务器。 如果一个服务器死亡，从外部的angular度来看，没有什么真正的变化，但是你想知道和修复服务器。 如果你开始遇到性能或可用性方面的问题，你不想find的是3台服务器已经closures了一个月，其余的都在额外的负载下挣扎。