使用软件负载平衡与其他负载平衡的经验硬件负载平衡器?
-
03-07-2019 - |
题
我目前在日常工作中负责的 ASP.NET 应用程序在单个服务器内扩展的能力方面已达到极限。显然,我们正在努力将会话移出进程,并且测试和希望部署日期即将到来。我想借鉴人们在 Windows 和 Windows 中使用内置负载平衡的经验。一种设备解决方案,例如 Baracudda、Coyote Point、F5 等。您是否从一个开始,然后转向另一个?为什么?
提前感谢您的想法和建议...
解决方案
我在负载平衡解决方案方面有一些经验,但这实际上取决于您的网络和软件是如何设计的,这是最适合您的解决方案。
就我遇到的解决方案而言:
Windows中的内置负载平衡适用于大多数情况,但您需要确保应用程序可以正确处理会话(如果它们没有粘性)。等
我使用F5产品,主要是作为缓存解决方案,但它们对我们来说过于复杂。 我们目前正在离开它们,因为开发人员没有正确使用它们,因为它们太复杂了。 (请注意这些是相当古老的F5产品。)
我们目前正在试用Foundry的硬件负载平衡器,我们可能会选择它们,因为它们适合我们的网络架构。 (这很复杂。)。
所以我想说,如果你想要一个简单的解决方案,请在Windows中使用负载均衡(如果你的应用程序能够正常运行。)。
如果不使用更复杂的东西。
无论您使用哪种负载均衡器,您的架构都会变得更加复杂。所以要仔细计划和测试。
其他提示
一些想法
- WLBS 通常“足够好”,可以帮助您开始使用 NLB。然而,就像任何伟大的工程师一样 - 您需要“通过测量来了解”
- 这不仅仅是扩大规模,还涉及软或硬冗余。我们经常在虚拟机之间进行 NLB,只是为了提供软冗余。
- NLB 同样适用于后端网络和前端网络
- 加强硬件加速会给您带来新的运营成本。新培训专业支持、升级等。
- 寻找硬件加速来为您提供比 NLB 更多的功能,例如DDoS 保护、SSL、压缩、缓存、内容交换、连接聚合、缓冲。
- 让开发人员和运营工程师了解硬件加速的优势,出色的设计可以融合网络运营和应用程序开发之间的界限。
- 仅通过减少 GC 时间,硬件缓冲本身就使我们的 ASP.NET 速度提高了 30% 左右。
- 内容切换可以让您透明地合并或迁移不同的系统。我们使用此技术将 MSDN 和 MSDN2 平台合并到单个 url 空间中。
- 会话粘性是一把双刃剑 - 谨慎使用 - 同样不能替代良好的工程 - 测量和测试 一切
我们在网络中同时使用 WLBS 和 NLB - 成本通常会推动对话。将两者视为工具箱中的工具,了解它们的细微差别、成本模型等。
设置apache mod_proxy集群。 http://www.howtoforge.com/high_availability_loadbalanced_apache_cluster
比你想象的更容易,价格的一小部分
F5附带SSL加速芯片。 SSL加密&使用应用程序服务器进行解密(使用CPU非常密集)会降低实际请求的处理速度。 通常,SSL流量在F5处终止,并且正常的http流量将发送到应用程序服务器。这在负载均衡器处称为SSL卸载。 自从F5做这个SSL加密&使用芯片(硬件)解密它比普通加密快30到40倍。解密时间。