负载平衡：硬件负载平衡器前的 DNS 循环。如何分享粘性？

Question

DNS Round Robin (DRR) 允许进行廉价的负载平衡（分布式是一个更好的术语）。它具有允许无限水平缩放的优点。缺点是，如果其中一台 Web 服务器出现故障，即使 DNS 实施故障转移，一些客户端仍会继续使用损坏的 IP 数分钟（最少 TTL 300 秒）或更长时间。

硬件负载平衡器 (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）。 Amazon 的 EC2 托管也支持托管在那里的网站的这种功能（请参阅http://aws.amazon.com/elasticloadbalancing/）。

由于用户往往不会在单个会话过程中跨洲移动，因此假设您的配对位于不同的数据中心，您会自动获得地理负载平衡的亲和力（也称为“粘性”）。

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

如果您真的担心数据中心内的网络基础设施（路由器等）的单点故障，我怀疑F5 和其他供应商也提供达到相同目的的单数据中心解决方案。但路由器和交换机供应商有可能更适合解决该问题的高可用性解决方案。

Net-net，如果我是你，我不会担心多对负载平衡器。买一对，除非您有大量的资金和工程时间可以消耗，否则请与擅长保持其数据中心网络正常运行的托管商合作。

也就是说，如果缓存亲和性对您的应用来说非常重要，以至于您正在考虑为多对负载平衡器花费大量资金，那么可能值得考虑一些应用架构更改（例如使用外部缓存集群）。像memcached（用于linux）这样的解决方案就是为这种情况设计的。微软还推出了一款名为“Velocity”的产品。

无论如何，希望这是有用的信息 - 诚然，自​​从我深入参与这个领域以来已经有一段时间了（我是为大型软件供应商设计应用程序负载平衡产品的团队的一员）所以你可能想用你可以从 F5 和其他 LB 供应商那里获取的事实来仔细检查我上面的假设。

Answer 2

感谢您正确看待事物。 我同意你的看法。

我做了一些阅读并发现：

• Flickr：http://highscalability.com/flickr-architecture
  每天 40 亿次查询 --> 大约 50000 次查询/秒

• Youtube：http://highscalability.com/youtube-architecture
  1 亿次视频观看/天 --> 大约 1200 次视频观看/秒

• PlentyOfFish：http://highscalability.com/plentyoffish-architecture
  600 页/秒
  已使用 200 Mbps
  使用 CDN

• 推特：http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
  300 条推文/秒
  600 个请求/秒

像this 这样的高端LB 可以扩大规模：

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

因此，你说得对，LB 几乎不可能成为瓶颈。

反正我找到了这篇（旧）文章http://www.tenereillo.com/GSLBPageOfShame.htm 其中解释了地理感知 DNS 可能会产生可用性问题。

有人可以评论那篇文章吗？

谢谢，

华伦天奴

Answer 3

好的，这是一个古老的问题，我刚刚通过 Google 搜索找到。但对于任何未来的访客，这里有一些额外的说明：

问题：[DNS Round Robin] 在 HLB 对之间随机移动客户端，因此 (AFAIK) 会话粘性不起作用。

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

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

• 发布到由 L4 负载平衡器处理的虚拟高可用性 IP 的 DNS 循环记录。
• 让 L4 负载均衡器根据源 IP 地址 转发到 L7 负载均衡器对，即使用基于最终用户 IP 的一致哈希始终将最终用户路由到同一个 L7 负载均衡器.
• 让您的 L7 负载平衡器按照您的意愿使用“粘性会话”。

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

Answer 4

那么为什么不保持简单，让 DNS 服务器根据源 IP 地址给出一个（或多个）特定 IP 地址（即使用基于最终用户 IP 的一致散列，以始终为最终用户提供相同的 IP 地址(es)) ?

我知道这只提供了一种简单而廉价的负载分配机制。

我一直在寻找这个，但还没有找到实现这个的 DNS 服务器（虽然 Bind 有一些视图的可能性）。