我们为越来越多的客户端运行一个为Web API提供服务的Web应用程序。 首先，客户端通常是家庭，办公室或其他无线networking，将分块的http上传到我们的API。 我们现在已经开始处理更多的移动客户端。 文件从几个k到几个演出，分解成更小的块，并重新组装在我们的API。
我们目前的负载平衡是在两层进行的，首先我们使用循环DNS为我们的api.company.com地址宣传多个Alogging。 在每个IP上，我们托pipe一个Linux LVS： http ： //www.linuxvirtualserver.org/，load-balancer查看请求的源IP地址，以确定将哪个API服务器连接到该连接。 这个LVS框configuration有心跳接pipe外部VIP和内部网关IP。
最近，我们看到了两个新的错误条件。
第一个错误是客户端在振荡或者从一个LVS迁移到另一个LVS的时候，中间上传。 这反过来导致我们的负载均衡器失去了持续连接的跟踪，并将stream量发送到新的API服务器，从而打破了跨两个或更多服务器的分块上载。 我们的目标是为我们的api.company.com（我们已经设定为1小时）的Round Robin DNS TTL值提供下游caching名称服务器，操作系统caching层和客户端应用程序层的荣誉。 这个错误发生在我们上传的大约15％。
我们看到的第二个错误很less见。 客户端将启动stream量到一个LVS箱并被路由到它后面的realserver A. 此后，客户端将通过新的源IP地址（LVS箱不能识别）进入，从而将正在进行的通信量路由到也位于该LVS之后的真实服务器B.
鉴于我们的架构如上所述，我想知道什么是人们的更好的方法的经验，这将使我们能够更好地处理上面的每个错误情况？
编辑5/3/2010：
这看起来像我们所需要的。 对源IP地址加权GSLB哈希。
http://www.brocade.com/support/Product_Manuals/ServerIron_ADXGlobalServer_LoadBalancingGuide/gslb.2.11.html#271674
对此的规范解决scheme是不依赖最终用户的IP地址，而是通过cookie使用第7层（HTTP / HTTPS）负载均衡器和“粘滞会话”。
粘滞会话意味着负载均衡器将始终将给定的客户端指向同一个后端服务器。 通过cookie意味着负载平衡器（本身是一个完全能力的HTTP设备）插入一个cookie（负载均衡器自动创build和pipe理）来记住给定的HTTP连接应该使用哪个后端服务器。
粘性会话的主要缺点是，服务器的负载可能会变得不均匀。 负载平衡器只能在build立新的连接时公平地分配负载，但考虑到现有的连接可能在你的场景中长期存在，那么在某些时间段内负载将不会完全公平地分配。
几乎每个第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（我们已经设定为1小时）的Round Robin DNS TTL值提供下游caching名称服务器，操作系统caching层和客户端应用程序层的荣誉。
不会的 而DNS Round Robin不太适合负载均衡 。 如果没有其他说服力的话，请记住， 由于前缀匹配最长 ，所以现代客户端可能更倾向于一个主机 ，所以如果移动客户端改变了IP地址，则可以select切换到另一个RR主机。
基本上，通过将2个或更多个RRlogging指向高可用IP地址（由主动/被动或主动/主动HA中的实际负载均衡器处理），可以使用DNS循环作为粗粒度负载分配。 如果这就是你正在做的事情，那么你也可以为那些具有很长Time To Live值的DNS RRlogging提供服务，因为关联的IP地址已经可用了。
要回答关于替代scheme的问题：您可以通过HAProxy获得可靠的第7层负载平衡。
至于解决LVS的亲和力问题，我坚实的想法有点干。 它可以像超时或溢出一样简单。 某些移动客户端在连接到networking时会切换IP地址; 也许这可能是你悲惨的根源？ 至less我会build议你把亲和粒度分布到至less一个C类。