使用软件负载平衡与硬件负载平衡器的经验？答案

【问题标题】：Experiences using software load balancing vs. a hardware load balancer?使用软件负载平衡与硬件负载平衡器的经验？
【发布时间】：2010-09-15 01:06:28
【问题描述】：

我目前在日常工作中负责的 ASP.NET 应用程序在单个服务器内的扩展能力方面已经达到了极限。显然，我们正在努力将会话移出进程和测试并希望部署日期临近。我想借鉴人们在 Windows 中使用内置负载平衡与设备解决方案（例如 Baracudda、Coyote Point、F5 等）的经验。您是否从一个开始并转向另一个，为什么？

提前感谢您的想法和建议......

【问题讨论】：

我已经阅读了有关在 windows 中设置 webfarm 的文章以及有关硬件设备的销售资料。但是，在实际情况下，就某项工作的效果如何获得建议却有些欠缺。

标签： asp.net scalability web-farm

【解决方案1】：

我在负载平衡解决方案方面有一些经验，但这确实取决于您的网络和软件是如何设计的，哪个是最适合您的解决方案。

就我遇到的解决方案而言：

Windows 中内置的负载平衡在大多数情况下都能很好地工作，但您需要确保您的应用程序能够正确处理会话（如果它们不具有粘性）。等等

我使用过 F5 产品，主要用作缓存解决方案，但它们对我们来说过于复杂。我们目前正在取消它们，因为开发人员没有正确使用它们，因为它们太复杂了。（请注意，这些是相当老的 F5 产品。）

我们目前正在试用 Foundry 的硬件负载平衡器，我们可能会采用它们，因为它们非常适合我们的网络架构。（这很复杂。）。

所以我想说，如果您想要一个简单的解决方案，请在 Windows 中使用负载平衡（如果您的应用程序可以正常工作。）。

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

无论您使用哪种负载平衡器，您的架构都会变得更加复杂。因此，请仔细计划和测试。

【讨论】：

感谢您抽出宝贵时间回答我的问题。它给了我很多思考。我们正在努力对代码进行更改并使用 Windows NLBS 运行 - 但在生产中这样做是一回事，而对其进行操作则是另一回事。

【解决方案2】：

一些想法

WLBS 通常“足够好”，可以让您开始使用 NLB。然而，就像任何伟大的工程师一样 - 你需要“衡量才能知道”
它不仅与扩展有关，还与软冗余或硬冗余有关。我们经常在虚拟机之间进行 NLB，只是为了给我们提供软冗余。
NLB 同样适用于后端网络和前端网络
升级到硬件加速会给您带来新的运营成本。新的培训专业支持、升级等。
寻找比 NLB 更多的硬件加速功能，例如DDoS 保护、SSL、压缩、缓存、内容切换、连接聚合、缓冲。
教育 Devs 和 Ops SE 的硬件加速优势，一个伟大的设计可以融合网络操作和应用程序开发之间的界限。
硬件缓冲仅通过减少我们的 GC 时间就使我们的 ASP.NET 速度提高了大约 30%。
内容切换可以让您透明地合并或迁移不同的系统。我们使用这种技术将 MSDN 和 MSDN2 平台合并到一个 url 空间中。
会话粘性是一把双刃剑 - 谨慎使用 - 再次无法替代良好的工程 - 测量和测试一切

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

【讨论】：

感谢您抽出宝贵时间回答我的问题。它给了我很多思考。

【解决方案3】：

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

比你想象的更简单，而且价格只是其中的一小部分

【讨论】：

【解决方案4】：

F5 自带 SSL 加速芯片。使用应用程序服务器的 SSL 加密和解密（它非常占用 CPU）会使它们减慢实际请求的处理速度。一般来说，SSL 流量在 F5 处终止，正常的 http 流量被发送到应用程序服务器。这在负载平衡器上称为 SSL 卸载。由于 F5 使用芯片（硬件）进行 SSL 加密和解密，因此比普通加密和解密时间快 30 到 40 倍。

【讨论】：