有很多不同的系统可以在生产服务器(不仅仅是 Web 服务器)中平衡负载和实现冗余
- 循环 DNS
- Linux 虚拟服务器
- 思科本地总监
- F5 大IP
- 视窗 NLB
- ETC?
如果您在生产中使用其中一种(或另一种),是哪一种?它对你有多好?你评价过别人吗?
有很多不同的系统可以在生产服务器(不仅仅是 Web 服务器)中平衡负载和实现冗余
如果您在生产中使用其中一种(或另一种),是哪一种?它对你有多好?你评价过别人吗?
HAProxy是一个优秀的软件负载均衡器;易于配置、高度可定制且性能极佳(它可以使 10Gb NIC 饱和)。
使 HAProxy 非常适合我们的主要功能:
HAProxy 唯一令人讨厌的是配置文件。没有方便的方式以编程方式更改服务器的配置,并且有一个学习曲线来理解各种选项。
对于我们使用的 apache 进程(d):http ://www.f5.com/products/big-ip/ 这似乎是行业标准。我想这一切都取决于你付出了多少,以及你的负载平衡。
例如 Websphere 可以这样做:
大 IP -> Apache 1 -> WebSphere 1
大 IP -> Apache 2 -> WebSphere 2
或者你可以穿过它:
大 ip -> Apache 1 -> WebSphere 1 & 2(循环)
大 ip -> Apache 2 -> WebSphere 2 & 1(循环)
我们使用了后者,并且效果很好。注意一台主机失败的情况:在大多数情况下,如果它只是超时,您将丢失该请求。
37signals 的 Mark Imbriaco 创建了一个简短的截屏视频,展示了他的公司如何使用 HAproxy 进行 Rails 负载平衡:
将Ultramonkey添加到列表中。
我们只倾向于使用 DB 来实现冗余,Oracle Dataguard 运行良好,但设置起来很复杂。
我们正在使用coyotepoint的E250si。
我们选择这个特定负载均衡器的原因
要添加的一件事是,即使负载均衡器只有四个物理端口,您也可以通过将交换机连接到您的一个物理端口来启用更多端口 - 并由此扩展
这个负载均衡器没什么好说的。这对我们来说很好,并且已经运行了 10 个月左右而没有重新启动和任何问题。每当服务器出现故障时,它就会立即停止轮换。没有那么多我可以抱怨的。
最初有一些东西需要使用,如果我不得不考虑弱点,只会想到两个:
总而言之,E250si 为我们节省了所有配置和维护另一台服务器等。但是因为我听说了很多关于 HAproxy 和 磅的好东西,我们可能迟早会朝这个方向迁移。如果我走软件路线,我会非常挑剔我放入服务器的组件 - 例如主板,网卡等。
我在一个小型网站上使用了一个低端Coyote Point负载均衡器。我发现设置直观,产品稳定且易于使用。
我相信他们的产品是 BSD 的relayd的一个不错的 Web GUI 界面,以前是 hoststated。
回想起来,我希望我已经购买了中高端产品,这样我就可以将负载均衡器用作 SSL 端点并节省证书费用。
我们在LVS之上使用keepalived。添加服务器很简单,并且支持故障转移负载平衡服务器。
我在几个工作中使用过 F5 bigips,除了通常的硬件负载平衡好东西,我特别喜欢 irules,它确实提供了很大的重写灵活性
它基本上是一种事件驱动的脚本语言
http://devcentral.f5.com/Default.aspx?tabid=75
有一个 wiki 但您需要创建一个帐户才能访问
HAProxy(loadbalancing) + Pound (SSL termnation) + keepalived (VRRP 有一个实时备份负载均衡器)
循环 DNS 将为您提供负载平衡,但不会提供冗余。如果您的其中一台服务器发生故障,它仍然会受到其请求份额的影响。
我们使用 Apache mod_jk 来处理成对的 Java 应用服务器之间的负载平衡和冗余。这非常有效,而且很简单。
我们还有一个冷故障转移 Apache 服务器,以防主服务器出现故障。理想情况下,我们会使用 Linux-HA 来实现 apache 的热故障转移,但我们不确定是否可以证明复杂性是合理的。
我们目前使用 Zeuz ZXTM 负载均衡器,到目前为止对它很满意。但是,我们的托管服务提供商最初将其配置在运行防火墙服务的机器之上的虚拟机上。事实证明,这是一个非常愚蠢的错误,因为连接早在流量应该成为问题之前就已经饱和了。一旦移动到它自己的专用盒子,我们就能够处理 100Mb/s 的传出流量而不会出现故障或问题(在 4Gb/s 的可突发互联网管道上)。
我们使用 HAProxy 取得了巨大成功。即使在高负载平均期间,我也从未见过它超过 2% 的 CPU 使用率。
我相信我们使用的是带有粘性会话的循环法。我们必须进行设置,以便保留 ASP/ASP.Net 会话信息,以便用户坚持使用具有会话的一台服务器。
一旦涉及从 http 切换到 SSL,我们确实遇到了一个小问题,我们的网站会将经过身份验证的用户发送到非安全页面,而未经身份验证的用户将被发送到安全登录页面,这看起来有点奇怪,但确实有一些意义除了返回到作为直接解决方案的单个服务器之外,通过 SSL 终止解决的目的是最好的解决方案。
有时可能需要使用更复杂的东西来确定哪个服务器“最不忙”并将下一个请求发送到该机器,但我不确定基础设施人员将如何获得该负载功能平衡器。