负载均衡: DNS轮询领先于硬件负载均衡器。如何分享粘性？

Question

DNS循环调度(DRR)允许进行廉价的负载平衡(分发是一个更好的术语)。它具有允许无限水平缩放的优点。缺点是，如果其中一台web服务器宕机，一些客户端将继续使用损坏的IP数分钟(最小TTL 300s)或更长时间，即使DNS实施故障切换也是如此。

硬件负载均衡器(HLB)可以透明地处理此类web服务器故障，但它不能无限扩展其带宽。还需要一个热备盘。

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

问题: DRR在HLB对之间随机移动客户端，因此(AFAIK)会话粘性无法工作。

我可以避免使用会话粘性，但它更好地利用了缓存，因此我想保留它。

问:是否有可能/存在一个HLB实现，其中一个实例可以与其他实例共享它的(sessionid，webserver)映射？

如果这是可能的，那么客户端将被路由请求的HLB独立地路由到相同的web服务器。

提前谢谢。

Answer 1

现代负载均衡器具有非常高的吞吐能力(千兆)。因此，除非你运行的是一个huuuuuuuuuuge网站(例如google)，否则增加带宽并不是你需要一对新的负载均衡器的原因，特别是因为大多数大型网站都将大部分带宽卸载到像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和其他供应商也会提供实现相同目的的单数据中心解决方案。在您的数据中心内。但是路由器和交换机供应商有可能更适合解决该问题的高可用性解决方案。

如果我是你，我不会担心多对负载均衡器。买一双，除非你有很多钱和工程时间，否则就和一个擅长保持数据中心网络正常运行的托管商合作。

也就是说，如果缓存亲和性对你的应用程序来说是一个大问题，以至于你正在考虑为多对负载均衡器支付大的$$$，那么可能值得考虑一些应用程序架构的改变(比如使用外部缓存集群)。像memcached (用于linux)这样的解决方案就是为这个场景而设计的。微软也推出了一款名为"Velocity“的游戏。

无论如何，希望这是有用的信息--不可否认，我已经有一段时间没有深入参与这个领域了(我是为一家大型软件供应商设计应用程序负载平衡产品的团队的一员)，所以你可能想要用你可以从F5和其他LB供应商那里获得的事实来再次验证我上面的假设。

Answer 2

好的，这是一个古老的问题，，我刚刚通过谷歌搜索找到的。但对于任何未来的访问者，这里有一些额外的澄清：

问题: DNS轮询在HLB对之间随机移动客户端，因此(AFAIK)会话粘性无法工作。

这个前提我可以说是不准确的。似乎没有人真正知道old browsers might do是什么，但是大概每个浏览器窗口只要是打开的就会保持在相同的IP地址上。较新的操作系统可能是obey the "match longest prefix" rule。因此，不应该有太多的“摆动”，随机地从一个负载均衡器IP切换到另一个。

但是，如果您仍然担心用户会被随机重新分配到新的负载均衡器对，那么对经典的L3/4 & L7负载平衡设置进行一点小的修改可以有所帮助：

• 发布转到虚拟高可用性IP的DNS循环调度记录，这些记录由L4 load balancers.
• Have根据原始IP地址转发到成对的L4负载均衡器。例如，使用基于最终用户IP的一致散列始终将最终用户路由到相同的L7 load balancer.
• Have您的L7负载均衡器根据您的需要使用“粘滞会话”。

本质上，这只是对Willy Tarreau (the creator of HAProxy) wrote years ago的一个小修改。

Answer 3

感谢你把事情放在正确的角度。赞成。

我做了一些阅读，发现：

• Flickr：http://highscalability.com/flickr-architecture

每天40亿次查询-->大约50000 queries/s

• Youtube：http://highscalability.com/youtube-architecture

视频点击量1亿次/天-->大约1200个视频views/second

• PlentyOfFish：http://highscalability.com/plentyoffish-architecture

600页/秒

使用200 Mbps

CDN使用

• 推特：http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster

每秒300条推文

600 req/s

像this这样非常高端的LB可以向上扩展：

• 每秒200,000次SSL握手
• 每秒100万个TCP连接
• 每秒320万个HTTP请求
• 每秒36 Gbps的TCP或HTTP吞吐量

<代码>F224

因此，你是对的，LB几乎不会成为瓶颈。

无论如何，我找到了这篇(旧的) http://www.tenereillo.com/GSLBPageOfShame.htm文章，其中解释了地理感知的DNS可能会造成可用性问题。

有人能对那篇文章发表评论吗？

谢谢,

华伦天诺