持久性负载平衡最佳做法

我们运行一个Web应用程序，为越来越多的客户端提供Web API。首先，客户通常是家庭，办公室或其他无线网络，这些用户将分块的http上传文件提交到我们的API。现在，我们开始涉足更多的移动客户端。文件的大小从几千到几千个不等，分解成较小的块，然后在我们的API上重新组合。

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

最近，我们看到了两个新的错误情况。

第一个错误是客户端从一个LVS振荡或迁移到另一个中载。这进而导致我们的负载平衡器失去对持久连接的跟踪，并将流量发送到新的API服务器，从而破坏了两个或更多服务器之间的分块上传。我们的意图是使api.company.com（我们将其设置为1小时）的Round Robin DNS TTL值由下游缓存名称服务器，OS缓存层和客户端应用程序层使用。我们上载的大约15％会发生此错误。

我们看到的第二个错误要少得多。客户端将启动到LVS盒的流量，并路由到它后面的realserverA。此后，客户端将通过LVS框无法识别的新源IP地址进入，从而将正在进行的流量也路由到该LVS后面的realserverB。

鉴于上文所述的架构，我想知道人们在使用更好的方法后会遇到什么经验，该方法可以使我们更优雅地处理上述每种错误情况？

编辑5/3/2010：

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

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

对此的典型解决方案是不依赖最终用户IP地址，而是通过Cookie将第7层（HTTP / HTTPS）负载均衡器与“ Sticky Sessions”一起使用。

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

粘性会话的主要缺点是，分散的服务器负载可能会变得有些不均匀。负载平衡器仅在建立新连接时才可以公平地分配负载，但是鉴于现有连接在您的方案中可能会长期存在，因此在某些时间段内负载不会完全公平地分配。

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

HAProxy的作者Willy Tarreau在这里对负载均衡技术进行了很好的概述。

关于DNS Round Robin：

我们的意图是使api.company.com（我们将其设置为1小时）的Round Robin DNS TTL值由下游缓存名称服务器，OS缓存层和客户端应用程序层实现。

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

基本上，将DNS循环作为粗粒度负载分配是可以的，方法是将2条或更多RR记录指向高可用IP地址，并由主动/被动或主动/主动HA中的实际负载平衡器处理。而且，如果您正在这样做，则最好为这些DNS RR记录提供“生存时间”值，因为相关的IP地址已经高度可用。

要回答有关替代方案的问题：您可以通过HAProxy获得可靠的第7层负载平衡。

至于解决LVS亲和力问题，我对扎实的想法有些不满。它可能像超时或溢出一样简单。一些移动客户端在连接到网络时会切换IP地址。也许这可能是您遇到麻烦的根源？我至少建议将亲和度粒度扩展到至少C类。