负载平衡:硬件负载平衡器前面的DNS循环.如何分享粘性？

Question

DNS循环(DRR)允许进行廉价的负载平衡(分配是一个更好的术语).它具有允许无限水平缩放的优点.问题是,如果其中一个Web服务器出现故障,即使DNS实现了故障转移,一些客户端仍会继续使用损坏的IP几分钟(最小TTL 300秒)或更长时间.

硬件负载平衡器(HLB)透明地处理此类Web服务器故障,但无法无限扩展其带宽.还需要热备件.

一个好的解决方案似乎是在一组HLB对前面使用DRR.每个HLB对永远不会停机,因此DRR永远不会让客户端失灵.另外,当带宽不足时,您可以向该组添加新的HLB对.

问题:DRR在HLB对之间随机移动客户端,因此(AFAIK)会话粘性不起作用.

我可以避免使用会话粘性,但它更好地使用缓存,因此我想保留.

问题:是否可能/存在HLB实现,其中实例可以与其他实例共享其(sessionid,webserver)映射？

如果可以,则客户端将由路由请求的HLB独立路由到同一Web服务器.

提前致谢.

Answer 1

现代负载平衡器具有非常高的吞吐量能力(千兆位).因此,除非您运行huuuuuuuuuuge网站(例如谷歌),否则添加带宽并不是您需要一对新的负载平衡器的原因,特别是因为大多数大型网站将大部分带宽卸载到像Akamai这样的CDN(内容交付网络).如果您通过您的站点抽取千兆位的无CDN数据并且还没有全局负载平衡策略,那么您遇到的问题比缓存关联性更大.:-)

站点往往会增加额外的LB对,而不是带宽限制,以便在不同的数据中心对服务器进行地理分布,以确保遍布全球的用户可以与距离他们最近的服务器进行通信.

对于后一种情况,负载均衡器公司提供地理位置解决方案,(至少在几年前,当我关注这些东西时)是基于自定义DNS实现,它查看客户端IP并解析为负载均衡器对与客户端"最接近"(在网络拓扑或性能方面)的虚拟IP地址.目前,像Akamai这样的CDN还提供全球负载平衡服务(例如http://www.akamai.com/html/technology/products/gtm.html).亚马逊的EC2托管还支持托管在那里的网站的此类功能(请参阅http://aws.amazon.com/elasticloadbalancing/).

由于用户在单个会话过程中不会跨越各大洲,因此您可以自动获得与地理负载平衡的亲和力(即"粘性"),假设您的对位于不同的数据中心.

请记住,地理位置非常困难,因为您还必须对数据进行地理定位,以确保您的后端跨数据中心网络不会被淹没.

我怀疑F5和其他供应商也提供单数据中心解决方案,如果你真的担心数据中心内网络基础设施(路由器等)的单点故障,那么它们会达到同样的目的.但路由器和交换机供应商提供的高可用性解决方案可能更适合解决该问题.

Net-net,如果我是你,我不会担心多对负载均衡器.获得一对,除非你有大量的资金和工程时间来燃烧,否则请与一位擅长保持数据中心网络正常运行的托管服务商合作.

也就是说,如果缓存亲和力对于您的应用来说是如此重要,以至于您正考虑为多对负载均衡器淘汰大量$$$,那么可能值得考虑一些应用程序架构更改(例如使用外部缓存集群) .memcached(用于linux)等解决方案专为此方案而设计.微软也有一款名为" Velocity "的产品.

无论如何,希望这是有用的信息 - 因为我已经深入参与这个领域(我是为大型软件供应商设计应用程序负载平衡产品的团队的一员),所以你可能想要加倍 - 检查我上面的假设,你可以从F5和其他LB供应商处上网.