持久性负载平衡最佳做法
我们运行一个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