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
service
ipvsadm save
ipvsadm
-R < /etc/sysconfig/ipvsadm
ipvsadm-restore
< /etc/sysconfig/ipvsadm
service
ipvsadm restart
LVS的实验演示
有了以上的基础，下面我们以lvs-nat和lvs-dr两种类型为演示，进一步加深对LVS的理解
lvs-nat类型的web服务器集群构建演示
1、安装ipvsadm，并查看ipvs在当前系统是否启用
# yum
install -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