我与lvs的2015年

2015年shou55使用lvs的集群比以前的大了不少, 频率也高了, 以前是偶尔弄一下, 15年是大部分时间都有它为伴.简单说一下我使用lvs的感悟吧.(以下内容主要是针对我所使用的lvs dr模式, 对其它模式可能也适用, 但不作特别说明)

(1)关于lc或wlc调度算法
shou55使用这种调度算法的时候, 遇到过几次问题, 总结的说就是: 使用lc或wlc调度算法存在因某一个节点异常而导致整个lvs集群失效的可能性.所以我后来把lvs的调度算法从wlc改成了wrr这种.  这样即使某个节点出现这种异常, 损失的也就是n/m的请求(其中n是故障的这台rs的权重, m是整个集群的所有rs的权重之和). 且失败的请求用户再重新访问一次就可以了, 至少整个集群还是可用的.
为什么wlc会导致这种问题了?
举例一个:假设lvs后端的某台real server因某种原因lo网卡上的vip掉了, 或者有人在启动服务时不是使用的0.0.0.0这种监听地址, 那么调度器发给这一台rs服务器的请求是无法正常响应的, 从lvs上看到的结果就是这台服务器的活动连接数一直为0, 也就是这台故障的rs的连接数总是最少的.  因此lvs的调度器按策略就总是不断的把新的请求发到这台服务器上, 从而导致整个lvs集群失效.


(2)重启网卡
lvs的dr模式下, 在lo回环网卡上需要绑定一个vip才能正常提供服务, 但是重启lvs的网卡的时候lo上的vip会被清理掉, 需要重新绑定一下.当使用lc或wlc算法的时候尤其要注意这一点. 或者也可以考虑把绑定lo上的vip的脚本加入重启网卡的系统脚本中, 虽然linux重启网卡的方法很多, 但是最为常用的还是/etc/init.d/network restart 或 service network restart( 这2者实质是一样的) 加入其中以后就可以在大多数情况下避免因为某些原因重启网卡后忘记绑定vip而影响lvs集群的问题.


(3)lvs的timeout 
查看方法ipvsadm -l --timeout  ; 修改方法 ipvsadm --set value1 value2 value3
主要是第一个值, 默认为900
当这个值过大时, 从lvs调度器上查看到的活动连接数与real server上查看到的活动连接数一般来说会相差甚远,  tcp为900(默认值)时会导致我司应用在使用wlc算法时严重不均衡, 因为timeout较长, 从lvs上看到的活动连接数与rs上真实的活动连接数可能相差甚远, 从而导致lvs认为的最少连接实质上并不是真正的最少连接.

当这个值过小时,从lvs上查看到的活动连接数与真实服务器上的连接数相接近, 但是在某些情况需要长时间连接的应用中会出现异常导致无法获取到结果. shou55线下测试看到的原因是lvs上由于这个连接并不是一直都在进行传输, 所以到了指定的timeout时间,比如20s以后这个连接就从lvs中被移除了, 但是有些tcp连接会在几十秒后需要再次连接, 但由于这第记录已过期被移除, 从而导致连接故障的情况.  

具体这个值设置为多大比较合适, 还需要具体应用场景来看, 不清楚的话就先保持默认值观察.


(4)监听端口
这个是我同事遇到的问题, 我解决的, 问题到是非常的简单, 说明如下:
假设real server服务器的ip地址为1.1.1.1, 那么做负载均衡的这个应用在rs上启动时就应该监听0.0.0.0 而不能只监听1.1.1.1 . 如果只监听1.1.1.1的话,  从lvs调度器上看到的结果也是这台rs的活动连接数会一直为0. 原因也比较简单, 因为监听1.1.1.1的话, lvs调度器发过来的请求是到vip的相应端口的, 但是rs上虽然有vip, 但是vip的这个端口没有监听, 自然无法提供响应.


最后想说一下, 使用lvs越多, 同时使用ng做负载均衡也越来越多, 当然2种的范围不同, 我使用ng主要是针对http的一些url做路由非常方便.