lvs基础介绍及实验演示

vivion34

　　LVS基础介绍
　　LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个开源的软件，可以基于软件的方法实现LINUX平台下的负载均衡，由章文嵩博士于1998年5月研发，是中国国内最早出现的自由软件项目之一。
　　LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。
　　LVS由两部分组成，分别是
　　ipvs：工作于内核空间的input或prerouting链
　　ipvsadm：在ipvs上写规则的工具,用于在ipvs上定义集群服务及该集群服务对应的后端可用主机；
　　二者结合使LVS可以根据指定的调度方法（算法）作出调度决策
　　在正式介绍lvs前，我们要先对其使用的术语有一个基本的了解。
Host
　　Director：调度器
　　Real Server：RS，后端提供服务的主机
IP
　　Client：CIP
　　Director Virtual IP：VIP
　　Director IP：DIP
　　Real IP：RIP
　　session会话保持
　　Session Sticky：会话绑定
　　实现方法：会话绑定，假设后端有3台RS，某客户端第一次访问时被调度到RS1，则以        后所有该客户端的访问全都调度到RS1，由此保持了该客户端的会话；
　　两种实现方法:基于IP绑定(粗糙),基于cookie绑定;
　　缺陷：一旦RS1宕机，客户端将无法得到响应，或被重新调度到其他RS时，会话丢失；
　　Session ReplicationCluster：会话复制集群
　　实现方法：将后端的RS构建成多播集群，某客户端第一次访问时被调度到RS1，其保        存在RS1上的会话会通过多播的方式在集群中的所有RS上各复制一份，从而达到客户        端下次访问时无论被调度到哪个RS，其会话均被保持；
　　缺陷：当集群中的RS数量过多时，每个RS均需保存大量的session，且整个服务器中        充斥着大量的会话复制广播，无意义的消耗资源，所以此种方式仅适用于集群中有较        小规模的RS；
　　Session Server：会话服务器
　　实现方法：会话不再存储于RS，而是在RS后端单独建立一个共享存储服务器专门用于        存储session；
　　缺陷：共享存储服务器成为整个系统的瓶颈和SPOF（单点故障），所以需要构建分布        式和高可用
　　LVS有四种类型，分别是lvs-nat、lvs-dr、lvs-tun和lvs-fullnat，下面我们将对其一一进行介绍。
　　lvs-nat
　　类似iptables的DNAT，但支持多目标转发
　　通过将请求报文的目标地址修改为根据调度算法所挑选出的某RS的RIP来转发
　　架构特性
　　(1)RS应该使用私有地址，即RIP应该为私有地址；各RS网关必须指向DIP；
　　(2)请求和响应报文都经由Director转发，所以高负载场景中，Director容易成为系统瓶颈；
　　(3)支持端口映射；
　　(4)RS支持使用任意类型的OS；
　　(5)RS的RIP必须与Director的DIP处于同一网段；
　　拓扑图

　　lvs-dr
　　直接路由
　　Director在实现转发时不修改请求报文的IP首部，而是通过直接封装帧首部（MAC首部）完成转发（源MAC为Director的MAC，目标MAC为算法选定的RS的MAC）；
　　架构特性
　　(1)各RS要直接响应Client，因此各RS均需配置VIP；但仅允许Director上的VIP能够与本地末梢路由直接通信;
　　解决方案
　　静态绑定：在前端路由直接将VIP对应的目标MAC静态配置为Director的MAC地址；
　　arptables：在各RS上，通过arptables规则拒绝响应对VIP的ARP广播请求；
　　内核参数：在RS上修改内核参数，并结合地址的配置方式实现拒绝响应；
　　(2)RS的RIP可以使用私有地址和公网地址，使用公网地址时可通过互联网上的主机直接对此RS进行管理操作；
　　(3)请求报文必须经由Director调度，而响应报文必须不能经由Director；
　　(4)各RIP必须与DIP在同一物理网络中；
　　(5)不支持端口映射；
　　(6)RS支持使用大多数的OS；
　　(7)RS的网关一定不能指向Director；
　　拓扑图

　　(1)客户端的请求报文到达本地路由-->ARP地址解析（本地间通信基于MAC而非IP）-->？
　　此时出现问题：请求报文的目标IP是VIP，而Director和RS1、RS2均配有VIP，当路由器做ARP地址广播请求拥有VIP地址的主机将其MAC发送过来时，三台主机均可响应，则无法保证报文是经由Director调度后发送至选定的RS，所以需要设置RS使其拒绝响应路由器的ARP广播或响应报文不予放行；
　　(2)此时请求报文只能由源MAC（路由器）发送至目标MAC（Director）；请求报文到达Director后，通过调度算法选定某RS，由Director再做ARP地址广播获得RS的MAC，将请求报文的源MAC改为Director，目标MAC改为选定的RS，调度至此完成；
　　(3)请求报文到达RS后，通过解封，RS发现源IP是CIP，目标IP是VIP且本机具备，所以当RIP的网关指向本地路由器时，就可直接将响应报文发送给客户端而无需经过Director；
　　(4)此时出现另一个问题：因为VIP配置在lo上，而lo无法与外部通信，所以响应报文只能经由物理网卡RIP流出，则响应报文的源IP变为了RIP，目标IP为CIP；但是客户端请求的是VIP而非RIP，所以必须让第(2)步的请求报文到达RS后经由lo接口进入（由此保证了响应报文的源IP是VIP），然后经由forward链转发至物理网卡响应给客户端；
　　上文提到的第三种解决方案需要修改内核参数，此参数是Linux2.4.26和2.6.4版本后
　　入的，位于/proc/sys/net/ipv4/conf/INTERFACE
　　以下图为例加以说明

　　arp_announce：
　　定义arp通告级别；有0~2三个级别，默认0级，当ARP广播到达后，会把自己拥有的3个IP地址都做响应；1级，尽量避免将与ARP广播来源不在同一网络的网卡上配置的IP地址作出响应；2级只允许和广播来源处于同一网络的IP作出响应；
　　以上图为例，0级1.1、2.1、3.1均会响应1.2的广播；1级尽量只让1.1响应1.2的广播，但是并不禁止2.1和3.1响应；而2级则只允许1.1响应1.2的广播；
　　arp_ignore：
　　定义arp忽略arp请求或arp通告的级别；有0~8九个级别
　　以上图为例，当2.6请求与2.1通信的广播到达1.1时：默认0级，虽然1.1本身和2.6不在同一网络，但2.1和2.6却在同一网络，依据Linux特性，内核认为自己拥有2.1地址，所以会通过1.1接口对该广播作出响应；1级，只有广播请求流入的接口本身就是广播请求的地址时才予以响应，否则不予响应（即当2.6请求与2.1通信的广播从1.1网卡流入时，主机将不予响应；只有当广播从2.1接口流入时才会响应）
　　lvs-tun
　　不修改请求报文的IP首部，而是通过IP隧道机制在原有IP报文之外再封装IP首部，经由互联网把请求报文转交给选定的RS

　　架构特性
　　(1)RIP，DIP，VIP都是公网地址；
　　(2)RS的网关无法指向DIP；
　　(3)请求报文经由Director分发，但响应报文直接由RS响应给Client；
　　(4)不支持端口映射；
　　(5)RS的OS必须支持IP隧道；
　　lvs-fullnat
　　通过修改请求报文的源地址为DIP，目标地址为RIP来实现转发；对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发
　　架构特性
　　(1)RIP，DIP可以使用私有地址；
　　(2)RIP和DIP可以不在同一网络中，且RS的网关无须指向DIP；
　　(3)支持端口映射；
　　(4)RS的OS可以使用任意类型；
　　(5)请求报文和响应报文都必须经由Director；
　　LVS的调度算法分为静态方法和动态方法，共有10种，详细介绍如下：
　　静态调度
　　仅根据算法实现调度
　　RR：
　　round-robin，轮询、轮调、轮流、轮叫；
　　WRR：
　　weighted round-robin，加权轮询；算法公式：Overhead=conn/weight；
　　DH：
　　Destination ip Hashing，目标地址哈希；把访问同一目标地址的访问定向至此前选定的RS；

　　应用场景：当某网络的出口网关有多个时，例如本公司有两个出口网关，而公司内有众多客户端，(1)当第一次访问某网站时，请求报文从FW1出去，返回时有可能从FW2返回，而FW2上的iptables设置了状态链接追踪规则，只允许ESTABLISHED状态的响应报文放行，此时会导致客户端无法得到响应；(2)客户端A通过FW1访问了某网站，有了缓存，而客户端B却通过FW2访问了同一网站，此时A访问是产生的缓存未生效；此时DH算法可将所有访问该网站的请求全都调度到FW1上以提升缓存命中率；但是当公司的所有客户都访问该网站时，所有的请求都被调度到FW1，而FW2却无需响应请求，反均衡；此时LBLC算法可解决此问题，但是却降低了缓存命中率，此时LBLCR可进一步解决此问题。
　　SH：
　　Source ip Hashing，源地址哈希；把来自同一地址的请求定向至此前选定的RS；
　　基于IP的哈希是反均衡的（例如通过SNAT的IP，一个IP可能有来自众多私网IP的请求，而SH却把众多的请求视作一个IP请求直接调度给了同一个RS），可通过应用层基于cookie的哈希解决此问题，但是lvs无法工作于应用层
　　动态调度
　　根据算法及后端RS当前负载状况实现调度
　　LC
　　least connection，最小连接
　　算法公式：Overhead=Active*256+Inactive
　　WLC
　　weighted least connection，加权最小连接；lvs默认调度方法
　　算法公式：Overhead=（Active*256+Inactive）/weight
　　lvs的默认调度算法
　　SED
　　Shorted Expectation Delay，最短期望延迟
　　算法公式：Overhead=（Active+1）*256/weight
　　NQ
　　Never Queue，永不排队
　　按照SED算法按顺序先保证每个RS至少处理一个请求，然后再按照SED算法进行调度
　　LBLC
　　Local-Based Least Connection，基于本地的最少连接，动态方式的DH算法
　　LBLCR
　　Replicated LBLC，可复制的LBLC
　　名词解释：
　　overhead：
　　衡量当前RS负载情况的指标，值越小，越被优先调度
　　在对LVS有了基本的了解后，现在我们来介绍下ipvsadm构建集群服务的具体使用方法。
　　(1)管理集群服务
　　创建或修改
　　ipvsadm-A|E -t|u|f service-address [-s scheduler]
　　-A：创建
　　-E：修改
　　-t：
　　承载的应用层协议基于tcp协议，其service-address的格式为“VIP：PORT”，如“172.16.14.1：80”；
　　-u：
　　承载的应用层协议基于udp协议，其service-address的格式为“VIP：PORT”，如“172.16.14.1：53”；
　　-f：
　　承载的应用层协议基于TCP或UDP协议，但此类报文会经由iptables/netfilter打标记（即防火墙标记,0~99之间的整数）；其service-address的格式为“FWM”，例如“10”；
　　作用是将基于不同端口的服务归为同一类集群服务
　　-s scheduler：
　　指明调度方法，省略时默认使用WLC；
　　删除
　　ipvsadm-D -t|u|f service-address
　　(2)管理集群上的RS
　　添加或修改
　　ipvsadm-a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
　　-r server-address：
　　指明RS，server-address格式一般为“IP[:PORT]”；注意，只有支持端口映射的lvs类型中才应该显式定义此处端口
　　[-g|i|m]：指明lvs类型
　　-g：gateway，意为dr类型；
　　-i：ipip，意为tun类型；
　　-m：masquerade，意为nat类型；
　　省略时默认为dr类型
　　[-w weight]：
　　指明当前RS的权重，只对支持加权调度的scheduler才有意义；
　　删除
　　ipvsadm-d -t|u|f service-address -r server-address
　　(3)查看规则
　　pvsadm-L|l [options]
　　-c: 列出当前所有connection；
　　--stats:列出统计数据
　　--rate:列出速率
　　-n, --numeric: 数字格式显示IP及端口；
　　--exact:精确值；
　　(4)保存及回复规则
        ipvsadm -S > /etc/sysconfig/ipvsadm
　　ipvsadm-save> /etc/sysconfig/ipvsadm
　　serviceipvsadm save
　　ipvsadm-R < /etc/sysconfig/ipvsadm
　　ipvsadm-restore< /etc/sysconfig/ipvsadm
　　serviceipvsadm restart
　　LVS的实验演示
　　有了以上的基础，下面我们以lvs-nat和lvs-dr两种类型为演示，进一步加深对LVS的理解
　　lvs-nat类型的web服务器集群构建演示
　　1、安装ipvsadm，并查看ipvs在当前系统是否启用
　　# yuminstall -y ipvsadm
　　# grep -i -A 5"ipvs" /boot/config-2.6.32-504.el6.x86_64
　　显示下列结果可知，当前系统已启用了ipvs

　　2、构建实验拓扑机构

　　将两台RS的默认网关指向DIP
# route add default gw 192.168.14.3
　　编辑两台RS的测试页
　　# vim/var/www/html/index.html
　　测试RIP与VIP及DIP的连通性
# ping 192.168.14.3
# ping 172.16.14.2
　　在DIP上测试两台RS
# curl http://192.168.14.1
# curl http://192.168.14.2

　　3、使用ipvsadm构建集群服务
　　#ipvsadm -A -t 172.16.14.2:80 -s rr
　　#ipvsadm -a -t 172.16.14.2:80 -r 192.168.14.1 -m -w1
　　#ipvsadm -a -t 172.16.14.2:80 -r 192.168.14.2 -m -w5
　　#ipvsadm -ln

　　4、确保Director的网络间转发功能处于开启状态
　　# cat/proc/sys/net/ipv4/ip_forward
　　若结果为0，则
　　#echo 1 > /proc/sys/net/ipv4/ip_forward
　　或者
　　# vim/etc/sysctl.conf

　　#sysctl -p
　　5、在浏览器上访问172.16.14.2后查看结果
　　#ipvsadm -ln --stats

　　因为采用的scheduler是rr，所以权重无意义，因此调度结果是1：1的
　　6、修改调度方法后再做测试
　　#ipvsadm -E -t 172.16.14.2:80 -s wrr
　　# ab-n 10000 -c 100 http://172.16.14.2/index.html
　　#ipvsadm -ln --stats

　　此时调度结果接近1：5

　　7、再次修改调度方法做测试
　　#ipvsadm -E -t 172.16.14.2:80 -s sh
　　计数清零
　　#ipvsadm -Z

　　# ab-n 10000 -c 100 http://172.16.14.2/index.html
　　#ipvsadm -ln --stats

　　此时所有请求全都被调度到RS2上
　　8、抓包分析
　　tcpdump -i eth0 -nn host 172.16.250.65（本机物理IP）

　　lvs-dr类型的web服务器集群构建演示
　　1.设计实验拓扑结构

　　2、配置Director：
　　(1)VIP配置在物理接口的别名上
　　ifconfigINTERFACE:ALIAS $vip broadcast $vip netmask 255.255.255.255
　　# ifconfig eth0:0 172.16.14.2 broadcast172.16.14.2 netmask 255.255.255.255
　　(2) 配置路由信息
　　routeadd -host $vip dev INTEFACE:ALIAS
　　# route add -host 172.16.14.2 dev eth0:0
　　3、配置RS:
　　(1)先修改内核参数
　　echo 1> /proc/sys/net/ipv4/conf/all/arp_ignore
　　echo 1> /proc/sys/net/ipv4/conf/lo/arp_ignore
　　echo 2> /proc/sys/net/ipv4/conf/all/arp_announce
　　echo 2> /proc/sys/net/ipv4/conf/lo/arp_announce

　　(2) VIP配置在lo的别名上
　　ifconfiglo:0 $vip broadcast $vip netmask 255.255.255.255 up
　　(3)配置路由信息
　　routeadd -host $vip dev lo:0
　　# route add -host 172.16.14.2 dev lo:0
　　此步配置确保响应报文必须从lo:0流出，从而保证了RS直接响应给客户端的报文源IP是VIP
　　4、使用ipvsadm构建集群服务
　　#ipvsadm -A -t 172.16.14.2:80 -s rr
　　# ipvsadm -a -t 172.16.14.2:80 -r 192.168.0.1 -g -w1
　　# ipvsadm -a -t 172.16.14.2:80 -r 192.168.0.2 -g -w5

　　5、补充说明：
　　(1)因为lvs-dr模型的VIP仅用于目标地址标记而不用于通信，所以VIP掩码一般设置为32位（形如“netmask255.255.255.255”）；虽然这是子网掩码但是在这里已经不是用来分子网用的，而是用来作为受限广播地址的（表示广播时全匹配，这时候的子网掩码和ip地址完全相同，只能匹配到自己）。
　　四个特殊地址：
　　直接广播地址：X.X.X.255（ip最后一位为255）
　　受限广播地址：255.255.255.255（全四位为255）
　　这个网络上的特定主机：0.0.0.X（X表示在1—254之间随意取）
　　回送地址：127.0.0.0（属于A类ip地址）
　　(2)为确保VIP不会主动对外做广播，可设置“broadcast $vip”，表示广播域仅是自己本身；
　　(3)辅助命令
　　查看内核参数
　　#sysctl -a

　　显示ping命令发起主机和响应主机的对应网卡MAC地址
　　# arp-a

　　lvs定义集群服务的“-f”方式
　　定义格式
　　-f FWM，防火墙打标
　　在ipvs生效之前的netfilter的某hook function上定义iptables规则，实现给报文打上防火墙标记；
　　定义方法
　　(1) 打标：在Director上mangle表的PREROUTING链上实现
　　# iptables -t mangle -A PREROUTING -d $vip -p $protocol --dport$port -j MARK --set-mark FWM([1-99])
　　(2) 基于FWM定义集群服务
　　#ipvsadm -A -f FWM -s SCHEDULER
　　#ipvsadm -a -f FWM -r server-address -g|-i|-m -w #
　　lvs的persistence：lvs持久连接
　　无论使用哪一种调度方法，持久连接功能都能保证在指定时间和范围之内，来自于同一个IP的请求将始终被定向至同一个RS；
　　persistencetemplate：持久连接模板
　　PPC：
　　每端口持久，持久连接的生效范围仅为单个集群服务；如果有多个集群服务，每服务被单独持久调度；
　　PCC：
　　每客户端持久，持久连接的生效范围为所有集群服务；定义集群服务时，其tcp或udp协议的目标端口要使用0；
　　PFWM：
　　每防火墙标记持久，持久连接的生效范围为定义为同一个FWM下的所有服务；
　　ipvsadm-A -t|-u|-f service-address -s SCHEDULER [-p [#]]
　　无-p选项：不启用持久连接
　　-p #：指定持久时长，省略时长，默认为300seconds
　　RS宕机问题解决方案
　　lvs本身不支持对RS的健康状态作检测
　　(1)自写程序
　　(2)keepalived程序（可解决单点故障和健康状态检测）；
　　健康状态检测应该是一种周期性检查机制，并在状态发生变化时作出相应处理
　　当状态up-->down，建议至少检查3次再做相应处理；
　　当状态down-->up，建议至少检查1次再做相应处理；
　　下线处理机制：
　　(1)设置权重为0；
　　(2)将相应的RS 从ipvs的可用RS列表中移除；
　　上线处理机制：
　　(1)设置为正常权重；
　　(2)将相应的RS添加到ipvs的可用RS列表中；
　　健康状态检测方法
　　(1)IP层：ping等主机在线状态探查工具；
　　(2)传输层：端口扫描工具探查服务在线状态；
　　(3)应用层：请求专用于健康状态检查的资源或者某正常资源；
　　备用服务器
　　当后端所有RS都宕机时，启用此服务器
　　sorry server，backupserver
　　可以在Director上直接实现，即配置Director称为web服务器，仅提供有限资源，在所有RS都出现故障时才启用此server