持久性负载平衡最佳实践

Question

我们运行一个 Web 应用程序，为越来越多的客户端提供 Web API。首先，客户端通常是家庭、办公室或其他无线网络，向我们的 API 提交分块的 http 上传。我们现在已经扩展到处理更多的移动客户端。文件从几千到几场不等，分解成更小的块并在我们的 API 上重新组装。

我们当前的负载均衡是在两层执行的，首先我们使用轮询 DNS 为我们的 api.company.com 地址通告多个 A 记录。在每个 IP 处，我们托管一个 Linux LVS：http : //www.linuxvirtualserver.org/，负载均衡器查看请求的源 IP 地址以确定将连接交给哪个 API 服务器。这个 LVS 盒子配置了 heartbeatd 来相互接管外部 VIP 和内部网关 IP。

最近，我们看到了两个新的错误条件。

第一个错误是客户端在上传中摇摆或从一个 LVS 迁移到另一个。这反过来会导致我们的负载均衡器失去对持久连接的跟踪，并将流量发送到新的 API 服务器，从而破坏跨两个或更多服务器的分块上传。我们的目的是让下游缓存名称服务器、操作系统缓存层和客户端应用程序层遵守 api.company.com 的循环 DNS TTL 值（我们已将其设置为 1 小时）。大约 15% 的上传会出现此错误。

我们看到的第二个错误要少得多。客户端将向 LVS 盒发起流量并路由到它后面的 realserver A。此后，客户端将通过 LVS 框无法识别的新源 IP 地址进入，从而将正在进行的流量路由到也在该 LVS 后面的真实服务器 B。

鉴于我们上面部分描述的架构，我想知道人们对更好的方法有什么经验，这将使我们能够更优雅地处理上述每个错误情况？

2010 年 5 月 3 日编辑：

这看起来是我们需要的。源 IP 地址上的加权 GSLB 哈希。

http://www.brocade.com/support/Product_Manuals/ServerIron_ADXGlobalServer_LoadBalancingGuide/gslb.2.11.html#271674

Answer 1

对此的规范解决方案是不依赖最终用户 IP 地址，而是通过 cookie 使用带有“粘性会话”的第 7 层 (HTTP/HTTPS) 负载平衡器。

粘性会话意味着负载均衡器将始终将给定客户端定向到同一后端服务器。通过 cookie 意味着负载平衡器（它本身是一个功能齐全的 HTTP 设备）插入一个 cookie（负载平衡器自动创建和管理）来记住给定的 HTTP 连接应该使用哪个后端服务器。

粘性会话的主要缺点是后端服务器负载可能会变得有些不平衡。负载均衡器只能在建立新连接时公平地分配负载，但考虑到现有连接在您的场景中可能是长期存在的，那么在某些时间段内，负载将不会完全公平地分配。

几乎每个第 7 层负载均衡器都应该能够做到这一点。在 Unix/Linux 上，一些常见的例子是 nginx、HAProxy、Apsis Pound、带有 mod_proxy 的 Apache 2.2 等等。在 Windows 2008+ 上有 Microsoft 应用程序请求路由。作为家电，Coyote Point、loadbalancer.org、Kemp 和 Barracuda 在低端领域很常见；和 F5、Citrix NetScaler 等高端产品。

HAProxy 的作者 Willy Tarreau 在此处对负载平衡技术进行了很好的概述。

关于 DNS 轮询：

我们的目的是让下游缓存名称服务器、操作系统缓存层和客户端应用程序层遵守 api.company.com 的循环 DNS TTL 值（我们已将其设置为 1 小时）。

不会。而且DNS Round Robin 不适合负载平衡。如果没有其他说服您，请记住，由于最长前缀匹配固定，现代客户端可能更喜欢一台主机而不是所有其他主机，因此如果移动客户端更改 IP 地址，它可能会选择切换到另一台 RR 主机。

基本上，可以使用 DNS 循环作为粗粒度负载分配，通过将 2 个或更多 RR 记录指向高度可用的 IP 地址，由主动/被动或主动/主动 HA 中的真实负载平衡器处理。如果这就是您正在做的事情，那么您不妨为那些具有较长生存时间值的 DNS RR 记录提供服务，因为相关联的 IP 地址已经高度可用。