设为首页 收藏本站
查看: 1704|回复: 0

[经验分享] 负载均衡集群解决方案 (一)LVS-DR

[复制链接]

尚未签到

发表于 2019-1-6 12:06:31 | 显示全部楼层 |阅读模式
  LVS的工作机制以及其调度算法等一些初步了解在我之前的文章里面已有记录。请看这里
  LVS其工作机制类似iptabls,一部分工作在用户空间(ipvsadmin),一部分工作在内核空间;用户空间:用于定义一些负载均衡的对象与策略,例如对TCP协议的80端口进行持久连接的负载,又或者对TCP协议的3306端口的连接进行负载等一些符合个人需求的一些规则定义
  内核空间:用于针对用户空间中所定义的规则对符合要求的数据包进行转发
  在整个负载均衡的架构中,所有的角色都使用了一个额外的IP地址---VIP,当一个客户端向VIP发起请求时,此请求必须直接连接至Directory,而不能是后端的realserver。否则的话此负载均衡的架构就毫无任何意义了。
  因此,在客户端发出至VIP的连接请求后,只能由Directory将其MAC地址响应给客户端或网络中的路由设备。而Directory将会根据用户所定义的负载规则将该请求按照所定义的某种调度算法转发至后端的realserver了。
  如果客户端在请求建立至VIP的连接时由后端的realserver响应了其请求,那么客户端会在其MAC地址表中建立起一个VIP与响应其请求的realserver的MAC的对应关系,用以以后的通信,而此刻在客户端看来只有一个realserver而无法意识到其他服务器的存在,为了避免这种情况的发生,结合实际情况解决方案有四:
  1、禁止RealServer响应对VIP的ARP请求;
  2、在RealServer上隐藏VIP,以使得它们无法获知网络上的ARP请求;
  3、基于“透明代理(Transparent Proxy)”或者“fwmark (firewall mark)”;
  4、禁止ARP请求发往RealServers;
  在Linux内核2.4.26以后引入了两个新的调整ARP栈的标志:
  arp_announce:当向别人通告自己的MAC时所采取的限制级别
  arp_ignore:在响应别人的ARP广播请求时,所使用的不同的模型
  arp_announce类型:
  0--default,使用本地的任何地址,向外通告
  1--当本机具有多个IP地址时,试图向同一网段的通告
  2--一定使用同一网段的IP进行通告
  arp_ignore类型:
  0--default,无论是本机的IP地址,就会用任意接口进行响应
  1--只响应直接请求的网卡的地址是目标地址
  初步了解了以上,就可以动手LVS-DR模型的搭建了:
  环境介绍:
  系统:RHEL5
  DIP:172.23.136.139
  RS1:172.23.136.149
  RS2:172.23.136.148
  VIP:172.23.136.150
  (一)、Directory的配置
  1、使用ipvsadm进行负载均衡的实现,早期需要重新编译内核,不过现在版本的redhat默认已经直接做进内核。
  ##查看内核是否已经支持ipvs
  modprobe ip_vs
  cat /proc/net/ip_vs
  2、安装ipvsadm
  yum install ipvsadm -y
  并启动ipvsadm
  service ipvsadm start
  第一次启动会报一个No such file or directory的错误,因为lvs和iptables都是可以讲用户所配置的规则保存在一个文件中,当系统重启或者服务重启后都会重读这个规则文件,已达到规则永久有效的目的。由于是第一次启动并未定义规则,所以这个规则文件是不存在的,在服务启动时重读这个文件时就报错了。
  3、启动ipvs脚本:
  service ipvs start

  • #!/bin/bash
  • #
  • # LVS script for VS/DR
  • #
  • . /etc/rc.d/init.d/functions
  • #
  • VIP=172.23.136.150
  • RIP1=172.23.136.149
  • RIP2=172.23.136.148
  • PORT=80

  • #
  • case "$1" in
  • start)

  •   /sbin/ifconfig eth0:1 $VIP broadcast $VIP netmask 255.255.255.255 up
  •   /sbin/route add -host $VIP dev eth0:1

  • # Since this is the Director we must be able to forward packets
  •   echo 1 > /proc/sys/net/ipv4/ip_forward

  • # Clear all iptables rules.
  •   /sbin/iptables -F

  • # Reset iptables counters.
  •   /sbin/iptables -Z

  • # Clear all ipvsadm rules/services.
  •   /sbin/ipvsadm -C

  • # Add an IP virtual service for VIP 172.23.136.150 port 80
  • # In this recipe, we will use the round-robin scheduling method.
  • # In production, however, you should use a weighted, dynamic scheduling method.
  •   /sbin/ipvsadm -A -t $VIP:80 -s wlc

  • # Now direct packets for this VIP to
  • # the real server IP (RIP) inside the cluster
  •   /sbin/ipvsadm -a -t $VIP:80 -r $RIP1 -g -w 1
  •   /sbin/ipvsadm -a -t $VIP:80 -r $RIP2 -g -w 2

  •   /bin/touch /var/lock/subsys/ipvsadm &> /dev/null
  • ;;

  • stop)
  • # Stop forwarding packets
  •   echo 0 > /proc/sys/net/ipv4/ip_forward

  • # Reset ipvsadm
  •   /sbin/ipvsadm -C

  • # Bring down the VIP interface
  •   /sbin/ifconfig eth0:1 down
  •   /sbin/route del $VIP

  •   /bin/rm -f /var/lock/subsys/ipvsadm

  •   echo "ipvs is stopped..."
  • ;;

  • status)
  •   if [ ! -e /var/lock/subsys/ipvsadm ]; then
  •     echo "ipvsadm is stopped ..."
  •   else
  •     echo "ipvs is running ..."
  •     ipvsadm -L -n
  •   fi
  • ;;
  • *)
  •   echo "Usage: $0 {start|stop|status}"
  • ;;
  • esac
  

  

  (二)、RealServer端配置
  在各个realserver端分别运行ipvsclient脚本,脚本内容如下:
  

  


  • #!/bin/bash
  • #
  • # Script to start LVS DR real server.
  • # description: LVS DR real server
  • #
  • .  /etc/rc.d/init.d/functions

  • VIP=172.23.136.150
  • host=`/bin/hostname`

  • case "$1" in
  • start)
  •        # Start LVS-DR real server on this machine.
  •         /sbin/ifconfig lo down
  •         /sbin/ifconfig lo up
  •         echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
  •         echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
  •         echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
  •         echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

  •         /sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
  •         /sbin/route add -host $VIP dev lo:0

  • ;;
  • stop)

  •         # Stop LVS-DR real server loopback device(s).
  •         /sbin/ifconfig lo:0 down
  •         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

  • ;;
  • status)

  •         # Status of LVS-DR real server.
  •         islothere=`/sbin/ifconfig lo:0 | grep $VIP`
  •         isrothere=`netstat -rn | grep "lo:0" | grep $VIP`
  •         if [ ! "$islothere" -o ! "isrothere" ];then
  •             # Either the route or the lo:0 device
  •             # not found.
  •             echo "LVS-DR real server Stopped."
  •         else
  •             echo "LVS-DR real server Running."
  •         fi
  • ;;
  • *)
  •             # Invalid entry.
  •             echo "$0: Usage: $0 {start|status|stop}"
  •             exit 1
  • ;;
  • esac
  

  

  (三)、测试
  访问172.23.136.150,可以发现负载均衡已正常工作
  现在我在后端两台realserver上都配置了phpmyadmin,并且两数据库的账号密码均相同。现在访问172.23.136.150/phpmyadmin 你会发现一个很有意思的现象就是始终无法登陆上(在使用ipvsadm定义规则时没有定义权重)
  因此Directory还需要基于“连接追踪”实现将同一个客户端的请求始终发往其第一次被分配到的realserver,ipvs会在自己的内部维护一个hash表,表中保存着不同的客户端第一次请求时所分发的后端realserver,以及保存该条目的时间,当该段时间消耗完之后,连接还未断开,那么这段时间会自动延迟你所定义的持久连接时间。当下一个请求达到时,就会去这个表中对比,将请求分发给条目中所对应的realserver用来保证整个请求的完整性。
  lvs的持久连接类型分以下几种:
  1.pcc:持久客户端连接,在指定规则时,使用0端口代表所有的端口,即所有到达VIP的请求全部按照调度算法负载至后端的realserver
  2.ppc:持久端口连接,明确指定请求VIP的哪个端口的请求分发至后端的realserver
  3.Netfilter  marked packets:防火墙标记的持久连接,主要用于多端口协议间的关联,例如在电子商务网站上,在80端口挑选了商品后,当付款的时候就会跳转至443端口。
  4.FTP持久连接,用于主动连接和被动连接,很少用到。
  (一)、pcc
  任何类型的持久连接均只需要在Directory上配置,realserver则不需要进行额外配置,因为这些只涉及到Directory的请求分发方法。
  ipvsadm -C
  ipvsadm -A -t 172.23.136.150:0 -p 360
  ipvsadm -a -t 172.23.136.150:0 -r 172.23.136.148
  ipvsadm -a -t 172.23.136.150:0 -r 172.23.136.149
  在之前的配置基础上执行以上配置即可。
  (二)、ppc
  ipvsadm -C
  ipvsadm -A -t 172.23.136.150:80 -p 360
  ipvsadm -a -t 172.23.136.150:80 -r 172.23.136.148
  ipvsadm -a -t 172.23.136.150:80 -r 172.23.136.149
  (三)、持久防火墙标记
  持久防火墙标记需要结合iptables来使用
  iptables -t mangle -A PREROUTING -i eth0 -p tcp -d 172.23.136.150 -m multiport --dport 80,443 -j MARK --set-mark 1
  ###把来自eth0所有目的地址为172.23.136.150的80和443端口的请求绑定在一起,标签为1
  ipvsadm -C
  ipvsadm -A -f 1 -p 360
  ipvsadm -a -f 1 -r 172.23.136.148
  ipvsadm -a -f 1 -r 172.23.136.149
  (四)、FTP持久连接
  首先要了解FTP的工作模式:21控制端口   20数据端口
  被动连接 是随机从1024---65000内选出一个 作为回应端口号,所以我们要限制被动连接回应端口的范围。
  编辑你所用的FTP软件,vsftpd或者pure-ftpd,设置其端口范围结合iptables打标签
  iptables -t mangle -A PREROUTING -i eth0 -p tcp -d 192.168.2.100 --dport 21 -j MARK --set-mark 1
  iptables -t mangle -A PREROUTING -i eth0 -p tcp -d 192.168.2.100 --dport 10000:12000  -j MARK --set-mark 1
  ipvsadm -C
  ipvsadm -A -f 1 -p 360
  ipvsadm -a -f 1 -r 172.23.136.148
  ipvsadm -a -f 1 -r 172.23.136.149
  小结:
  访问172.23.136.150/phpmyadmin,现在已经可以正常登录进去,因为此次的连接被持久分发到后端的同一台realserver上。整个请求是完整的。
  查看其连接分配状态,可以发现同一个客户端的请求都被定向至后端的同一个realserver。
  ipvsadm -lcn
  IPVS connection entries
  pro expire state       source             virtual            destination
  TCP 01:55  FIN_WAIT    172.23.136.93:56944 172.23.136.150:80  172.23.136.149:80
  TCP 01:56  FIN_WAIT    172.23.136.93:56947 172.23.136.150:80  172.23.136.149:80
  TCP 01:39  FIN_WAIT    172.23.136.93:56928 172.23.136.150:80  172.23.136.149:80
  TCP 01:56  FIN_WAIT    172.23.136.93:56946 172.23.136.150:80  172.23.136.149:80
  TCP 01:39  FIN_WAIT    172.23.136.93:56930 172.23.136.150:80  172.23.136.149:80
  TCP 01:55  FIN_WAIT    172.23.136.93:56943 172.23.136.150:80  172.23.136.149:80
  TCP 01:55  FIN_WAIT    172.23.136.93:56945 172.23.136.150:80  172.23.136.149:80
  TCP 01:47  FIN_WAIT    172.23.136.93:56933 172.23.136.150:80  172.23.136.149:80
  TCP 01:39  FIN_WAIT    172.23.136.93:56931 172.23.136.150:80  172.23.136.149:80
  TCP 14:57  ESTABLISHED 172.23.136.93:56948 172.23.136.150:80  172.23.136.149:80
  TCP 05:50  NONE        172.23.136.93:0    172.23.136.150:80  172.23.136.149:80
  TCP 01:39  FIN_WAIT    172.23.136.93:56932 172.23.136.150:80  172.23.136.149:80
  本文出自 “My---Dream.*” 博客,请务必保留此出处http://grass51.blog.运维网.com/4356355/1109825



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-659943-1-1.html 上篇帖子: LVS-NAT模型实现web服务器的负载均衡实例分析 下篇帖子: LVS负载均衡的模式和算法总结
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表