我目前在日常工作中负责的ASP.NET应用程序在单个服务器中进行扩展的能力已达到极限。显然，我们正在努力使会话脱离流程，测试和部署日期有望临近。我想借鉴人们在Windows中使用内置负载平衡与设备解决方案(例如Baracudda，Coyote Point，F5等公司提供的解决方案)的经验。我们是从一个开始又转向另一个的，为什么？

事先想过的想法和建议...

解决方案

一些想法

• WLBS通常"足够好"，可以开始使用NLB。但是，就像任何伟大的工程师一样，我们需要"了解措施"
• 它不仅与扩大规模有关，还与软冗余或者硬冗余有关。我们经常在虚拟机之间使用NLB只是为了给我们提供软冗余。
• NLB同样适用于后端网络和前端网络
• 加速硬件加速将为我们带来新的运营成本。新的培训专业支持，升级等
• 寻找硬件加速功能，让我们获得比NLB还要多的东西。 DDoS保护，SSL，压缩，缓存，内容交换，连接聚合，缓冲。
• 对Devs＆Ops SE都进行硬件加速收益方面的教育，出色的设计可以融合网络运营与应用程序开发之间的界线。
• 仅仅通过减少GC时间，硬件本身就使我们的ASP.NET速度提高了30％左右。
• 内容切换可以使我们透明地合并或者迁移不同的系统。我们使用这种技术将MSDN和MSDN2平台合并到单个URL空间中。
• 会话粘性是一把双刃剑-谨慎使用-不能替代良好的工程-测量和测试所有内容

在我们的网络内，我们同时使用WLBS和NLB来推动对话。将两者视为工具箱中的工具，了解它们的细微差别，成本模型等。

我在负载均衡解决方案方面有一些经验，但是，这实际上取决于网络和软件的设计方式，即哪种才是我们寻求的最佳解决方案。

在解决方案方面，我遇到了：

Windows中的内置负载平衡在大多数情况下都可以很好地工作，尽管我们需要确保应用程序在不粘滞的情况下可以正确处理会话。等等。

我曾经使用过F5产品，主要是作为缓存解决方案，但是对于我们来说它们过于复杂。
我们目前正在淘汰它们，因为开发人员由于过于复杂而无法正确使用它们。 (请注意，这些都是相当古老的F5产品。)

我们目前正在试用Foundry的硬件负载平衡器，我们可能会选择它们，因为它们很适合我们的网络体系结构。 (这很复杂。)。

因此，我想说的是，如果我们想要一个简单的解决方案，请在Windows中使用负载平衡(如果应用程序可以正常运行)。

如果不使用更复杂的东西。

无论我们使用哪种负载均衡器，都使体系结构变得更加复杂。因此，请仔细计划和测试。

设置一个Apache mod_proxy集群。
http://www.howtoforge.com/high_availability_loadbalanced_apache_cluster

比我们想的要容易的多，而且价格低廉