Amazon EC2中的负载均衡？

我们已经在亚马逊EC2上与HAProxy争夺了几天; 到目前为止,这种体验一直很好,但我们仍然在努力从软件负载均衡器中挤出更多性能.我们并不完全是Linux网络高手(我们通常是.NET商店),但我们到目前为止仍然拥有自己的,试图设置适当的ulimits,检查内核消息和tcpdumps是否存在任何异常情况.到目前为止,我们达到了大约1,700个请求/秒的平台,此时客户端超时比比皆是(我们一直在使用和调整httperf以此目的).一位同事和我正在收听最新的Stack Overflow播客,其中Reddit创始人注意到他们的整个站点都运行在一个HAProxy节点上,并且到目前为止它还没有成为瓶颈.确认!要么以某种方式没有看到许多并发请求,我们正在做一些可怕的错误,或者EC2的共享性质限制了Ec2实例的网络堆栈(我们使用的是大型实例类型).考虑到Joel和Reddit创始人都认为网络可能是限制因素这一事实,我们看到的限制是否可能？

任何想法都非常感谢!

编辑事实上,实际问题看起来并不是负载均衡器节点!罪魁祸首实际上是运行httperf的节点,在这个例子中.由于httperf为每个请求构建并断开套接字,因此它在内核中花费了大量的CPU时间.当我们提高请求率时,TCP FIN TTL(默认为60秒)会使套接字保持太长时间,并且ip_local_port_range的默认值对于此使用方案来说太低了.基本上,在客户端(httperf)节点持续创建和销毁新套接字几分钟后,未使用的端口数量用尽,后续"请求"在此阶段出错,产生的请求数/秒数较少且数量较多错误.

我们也看过nginx,但我们一直在使用RighScale,他们已经有了HAProxy的插件脚本.哦,当然,除非证明是绝对必要的,否则我们的截止日期太紧了[当然].幸运的是,在AWS上允许我们并行测试使用nginx的另一个设置(如果有保证),并在稍后进行切换.

此页面相当好地描述了每个sysctl变量(在这种情况下调整了ip_local_port_range和tcp_fin_timeout).

不直接回答问题,但EC2现在通过Elastic Load Balancing支持负载平衡,而不是在EC2实例中运行您自己的负载均衡器.

编辑:亚马逊的Route 53 DNS服务现在提供了一种方法,可以在ELB上指定一个具有"别名"记录的顶级域名.由于亚马逊知道ELB的当前IP地址,因此它可以返回当前IP的A记录,而不必使用CNAME记录,同时仍然可以随时更改IP.

不是你问题的答案,但是nginx和pound都有良好的声誉作为负载均衡器.Wordpress刚刚切换到nginx,结果很好.

但更具体地说,调试你的问题.如果你没有看到100%的CPU使用率(包括I/O等待),那么你是网络绑定的,是的.EC2内部使用千兆网络,尝试使用XL实例,因此您拥有自己的底层硬件,而不必共享该千兆网络端口.