domain-name-system – 持久性负载平衡最佳实践

概述我们运行一个Web应用程序,为越来越多的客户提供Web API.首先,客户通常是家庭,办公室或其他无线网络向我们的API提交分块的http上传.我们现在已经扩展到处理更多移动客户端.文件范围从几k到几个演出,分解成更小的块并在我们的API上重新组装. 我们当前的负载平衡分两层执行,首先我们使用循环DNS为我们的api.company.com地址发布多个A记录.在每个IP上,我们托管一个Linux 我们运行一个Web应用程序,为越来越多的客户提供Web API.首先,客户通常是家庭,办公室或其他无线网络向我们的API提交分块的http上传.我们现在已经扩展到处理更多移动客户端.文件范围从几k到几个演出,分解成更小的块并在我们的API上重新组装.

我们当前的负载平衡分两层执行,首先我们使用循环DNS为我们的API.company.com地址发布多个A记录.在每个IP上,我们托管一个Linux LVS：http://www.linuxvirtualserver.org/,负载均衡器,用于查看请求的源IP地址,以确定将连接传递给哪个API服务器.此LVS盒配置有heartbeatd以接管外部VIP和内部网关IP.

最近,我们看到了两个新的错误条件.

第一个错误是客户端从一个LVS振荡或迁移到中间上传.这反过来导致我们的负载平衡器失去对持久连接的跟踪并将流量发送到新的API服务器,从而打破了跨两个或更多服务器的分块上传.我们的目的是为我们的API.company.com(我们设置为1小时)的Round Robin DNS TTL值提供下游缓存名称服务器, *** 作系统缓存层和客户端应用程序层.大约15％的上传内容会发生此错误.

我们看到的第二个错误不太常见.客户端将启动到LVS盒的流量并被路由到它后面的realserver A.此后,客户端将通过LVS盒无法识别的新源IP地址进入,从而将正在进行的流量路由到该LVS后面的realserver B.

鉴于我们在上面部分描述的架构,我想知道人们使用更好的方法的经验是什么,这将使我们能够更优雅地处理上面的每个错误案例？

编辑2010年5月3日：

这看起来像我们需要的.源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(负载均衡器自动创建和管理)以记住给定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有一个nice overview of load balancing techniques here.

关于DNS Round Robin：

Our intent was for the Round Robin DNS TTL value for our API.company.com (which we’ve set at 1 hour) to be honored by the downstream caching nameservers,OS caching layers,and clIEnt application layers.

It will not be.和DNS Round Robin isn’t a good fit for load balancing.如果没有别的说服你,请记住modern clients may prefer one host over all others due to longest prefix match固定,所以如果移动客户端更改IP地址,它可能会选择切换到另一个RR主机.

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

总结

以上是内存溢出为你收集整理的domain-name-system – 持久性负载平衡最佳实践全部内容，希望文章能够帮你解决domain-name-system – 持久性负载平衡最佳实践所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。