常见LVS集群的解决方案及负载不均排查

一、常见LVS集群方案简单总结

  1)通过开发的脚本来解决,如果负载均衡器硬件坏了,几分钟或者秒级别内可以在其他备机上完成新的部署,如果做的细的,还可以写脚本来做调度器之间的切换和接管功能。
  2)heartbeat+lvs+ldirectord脚本配置方案,这个方案中heartbeat 仅负责VIP的切换以及资源(LVS启动脚本)的启动停止,ldirectord(受heartbeat控制)负责RS节点的健康检查,由于比较复杂,不易控制,属于早起的解决方案,现在很少使用了。(作为了解)
heartbeat and ldirectord方案资料:

http://www.linuxvirtualserver.org/docs/ha/heartbeat_ldirectord.html
http://www.linuxvirtualserver.org/docs/ha/ultramonkey.html

ha里加载的LVS启动脚本(ipvsadm操作写成了一个启动脚本)ldirectord负责健康检查
  3)通过Redhat提供的工具piranha来配置LVS
Piranha是Redhat提供的一个基于web的LVS配置软件,可以省去手工配置LVS的繁琐工作,同时也可单独提供cluster功能,例如:可以通过Piranha激活Director Server的后备主机,也就是Director Server的双机热备功能。(不推荐)
  4)keepalived+LVS方案,这也是推荐的方案,因为简单,易用,高效。
http://www.linuxvirtualserver.org/docs/ha/keepalived.html
  5)其他
http://bbs.linuxtone.org/thread-1402-1-1.html
LVS Documentation

http://www.linuxvirtualserver.org/zh/index.html
http://www.linuxvirtualserver.org/Documents.html#performance

二、LVS集群排错经验

1)负载不均排查
1.生产环境中ipvsadm -L -n 发现两台RS的负载均衡,一台有很多请求,一台没有并且没有请求的那台RS测试服务正常, lo:VIP也有,但是就是没有请求。

TCP 172.168.1.50:3307 wrr persistent 10
  172.168.1.51:3307  		route	1	0		0
  172.168.1.52:3307  		route	1	8		12758

问题原因:
  persistent 10的原因,persistent会话保持,当clientA 访问网络的时候,LVS把请求分发给了52,那么以后clientA 在点击的其他操作请求,也会发送给52这台机器。
解决办法:
  到keepalived中注释掉 persistent 10 然后把/etc/init.d/keepalived reload 然后就可看到以后负载两边都均衡了。
导致负载均衡不均的原因可能有:

 1. LVS自身的会话保持参数设置(-p 300,persistent 300)
  优化:大公司尽量用cookies 替代session
 2.LVS调度算法设置 例如: rr  wrr  wlc  lc算法
 3.后端RS节点的会话保持参数,例如:apache 的keepalive参数
 4.访问较少的情况,不均衡的现象更加明显、
 5.用户发送的请求的时间长短,和请求资源的大小。

2)LVS故障拍错思路
  1.调度器上LVS调度规则及IP的正确性
  2.RS节点上VIP绑定和arp抑制的检查
 生产环境中:
  1.对RS绑定的VIP 做实时监控,出问题报警或者自动处理后报警
  2.把RS绑定的vip 做成配置文件,例如: vi/etc/sysconfig/network-script/lo:0
3)ARP抑制的配置思路:
  1.如果是单个VIP那么可以用stop传参设置0
  2.如果rs端有多个vip绑定,此时,即使停止VIP绑定,也不一定不要配置0

if [ ${#VIP[@]} -lt 1 ];then
  echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignore
  echo "0" >/proc/sys/net/ipv4/conf/lo/arp_announce
  echo "0" >/proc/sys/net/ipv4/conf/all/arp_ignore
  echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce
fi

  3.RS节点上自身提供服务的检查(DR不能端口转换)
  4.辅助排除工具有tcpdump ping 等
  5.负载均衡和反向代理集群的三角形排查理论:

   haproxy 代理
   -     -
  -       -
 -         -
用户--------------web server 
   Squid 代理
   -     -
  -       -
 -         -
用户--------------web server 

tcpdump命令:
#抓取访问游览器访问的数据包
tcpdump -i eth0 tcp port 80 -x -vv -X -s 1500

三、集群LVS高并发拓展方案

1.LVS Cluster部署(OSPF + LVS)
http://my.oschina.net/lxcong/blog/143904
2.DNS轮询(数据库–全国IP分配的运营商以及省市)

  1)智能DNS
    根据用户线路的位置
    选项和用户最近的服务器线路相同的机房的地址

四、LVS集群下的代码发布方案详解

首先我们来看下代码上线的基本流程:
发布代码:

开发人员本地测试---》办公室内部测试(开发人员,测试人员)---》(配置管理员)---》IDC机房环境测试(测试人员)---》正式服务器

1)例如:后台代码是PHP环境
一般上线方式分为:
测试好代码后,正式上线是把测试好的代码先推送到正式环境的目录(新建一个目录)下面

  1.等待推送完成后,确认ok然后使用mv命令替换
  2.等待推送完成后,使用ln 命令做软连接

最大程度的保证用户体验
2)例如:后台代码是JAVA环境(上线服务需要重启)
一般上线方式分为:

  1.利用lvs服务平滑上线
  大概过程是:LVS下有6台web server (分为两组)使用ipvsadm -d 剔除另外一组,然后挂到另外一组VIP上测试,测试好后利用ipvsadm -a在添加进来。然后在对另外一组同样的操作。

总结:
代码上线是一个多方协作配合的一个项目流程环节,除了技术方案本身其科学完整的上线方案也非常重要。在过程中按照完备的流程,与开发、测试的前期的沟通也是保证完成整个上线流程的必要前提保障。

1 条评论

发表评论

*