6

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

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

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

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

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

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

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

提前致谢。

4

4 回答 4

7

现代负载均衡器具有非常高的吞吐量能力（千兆位）。因此，除非您正在运行一个 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 (for linux) 这样的解决方案就是为这种情况设计的。微软也有一款叫做“ Velocity ”的来了。

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

于 2009-09-25T17:43:43.667 回答
3

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

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

据我所知，这个前提是不准确的。似乎没有人真正知道旧浏览器可能会做什么，但大概每个浏览器窗口只要打开就会保持在相同的 IP 地址上。较新的操作系统可能遵循“匹配最长前缀”规则。因此，不应该有太多的“抖动”，从一个负载均衡器 IP 随机切换到另一个。

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

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

本质上，这只是对Willy Tarreau（HAProxy 的创建者）多年前所写内容的一个小修改。

于 2011-02-06T18:38:43.483 回答
2

谢谢你把事情放在正确的角度。我同意你的看法。

我做了一些阅读并发现：

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

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

  • PlentyOfFish: http://highscalability.com/plentyoffish-architecture
    600 pages/second
    200 Mbps used
    CDN used

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

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

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

因此，您是对的，LB 几乎不可能成为瓶颈。

无论如何，我发现这篇（旧）文章http://www.tenereillo.com/GSLBPageOfShame.htm 解释了地理感知 DNS 可能会产生可用性问题。

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

谢谢，

华伦天奴

于 2009-09-29T10:17:12.643 回答
0

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

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

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

于 2014-04-29T08:44:45.430 回答