lvs、nginx、haproxy这三者，只有LVS真正的支持四层负载均衡，而且也只能在四层工作，haproxy和nginx支持七层负载，也可以模拟实现四层负载。nginx通过stream模块，haproxy通过tcp模块。
nat模式
lvs-nat本质是多目标IP的DNAT，通过将请求报文中的目标IP地址和目标端口修改为某挑出的RS的RIP和PORT实现转发。
- RIP和DIP应该在同一个IP网段，且应使用私网地址；RS的网关要指向DIP。
- 请求报文和响应报文都必须经由director转发，director易于成为系统瓶颈
- 支持端口映射，可修改请求报文的目标PORT
- VS必须是linux，RS可以是任何OS系统
步骤：
- CIP XXXXX------------------------->VIP 80/tcp
- CIP XXXXX------------------------->RIP 80/tcp #去的时候把目标地址VIP替换成了RIP，去的时候替换的是目标地址
- RIP1 80/tcp----------------------->CIP XXXXX #回来的时要把源地址RIP再替换成VIP，回来的时候替换的是源地址
- VIP 80/tcp------------------------>CIP XXXXX
NOTE：
数据来回都要走LVS，压力比较大，很有可能会成为瓶颈
LVS与服务器之间通常是有交换机相连，当然用路由器也是可以的。
DNAT也可以改端口的，根据自己的需要
DR模式（默认）
LVS-DR，DR（direct routing直连路由），LVS的默认模式，应用最为广泛，通过为请求报文重新封装一个MAC首部进行转发，源MAC是DIP所在接口的MAC，目标MAC是某挑选出的RS的RIP所在接口的MAC地址；源IP/PORT，以及目标IP/PORT均保持不变。
NOTE：
- director和各RS都配置有VIP，VIP的IP地址都是一样的。
- 确保前端路由器将目标VIP的请求报文发往director
步骤：
- 客户端的请求报文源IP是CIP，目标IP是LVS的-VIP，但是LVS-SERVER和两台R-SERVER都配置有相同的VIP，交换机怎么确定给认证呢？只要不让两台R-SERVER发送和接收ARP即可。
- 报文到达LVS-SERVER时，流经INPUT链上发觉这是给集群的，于是强行改变数据流向到POSTROUTING
- LVS-SERVER不会改变报文内部的IP地址，也就说这时报文中的源和目标IP都和客户端发送出来时一模一样，LVS-SERVER仅仅是把目标MAC地址给改了。
- 报文交给交换机 ，交换机再交给R-SERVER，R-SERVER处理完成之后，就用VIP源IP，客户端的IP做目标IP，最后扔给网关-路由器，路由器再转发给客户端。
既然RS和VS的VIP是一样的，如何确保路由器将客户端的请求报文发送给真正的VS呢？三种方法，如下：
-
在前端网关做静态绑定VIP和director的MAC地址，这不靠谱，因为我们可能会在LVS上做高可用。
-
在RS上使用arptables工具
-
通过修改内核参数阻塞RS上发送和响应arp报文,默默的占用这个IP地址.
DR模式最大的特点就是来回路径不一致，用户的请求一定会通过LVS的转发，而RS的回应报文不用经过LVS（包括三次握手），这么做有啥子好处吗？来回路径不一致会减轻LVS的压力，这样的可以接待更多的用户请求。
物理上是一个网段，逻辑是两个网段，路由器的内网接口需要两个地址，为什么需要两个地址呢？一个地址不行吗？假如说用一个地址的话，arp广播的时候访问谁是VIP的时候就好玩了！因为好几台主机都有VIP，所以路由器的内网接口一定要有两个地址，当路由器把用户请求扔给LVS需要一个单独的网段，当LVS再将请求给RS的时候又需要另一个网段，所以不仅路由器需要两个地址，LVS也需要两个地址，那么RS需要几个地址？RS只需要一个地址就够了。
-
RS的RIP可以使用私网地址，也可以是公网地址；RIP与DIP在同一网络；RIP的网关不能指向DIP，以确保响应报文不会经由LVS。
-
RS和LVS要在同一个物理网段
-
请求报文要经由LVS，但响应报文不经由lvs，而由RS直接发往client
-
不支持端口映射（端口不能修改），为什么不能修改呢？因为DR模式只能更改MAC地址，而不能更改IP和端口。
LVS-tun模式
既然已经有了前两种模式，为什么还要有tun模式呢？
很多老师都讲说NAT模式和DR模式不可以跨机房，DR模式不可以跨机房我理解，因为要用到MAC地址，但是NAT模式为什么不能踌机房呢？仅仅是修改目标IP，我认为没什么问题。
不管是怎么说，反正tun模式适合长距离传输这一点毋庸置疑，我们平时的“FQ”操作不就是使用的隧道（tun）嘛！他的原理和VPN的原理是一样的，就是在原来的包外面再封装一层，这一层的源IP和目标IP都必须是可以在公网上上进行传播的。
访问步骤：
第一步：客户端向LVS服务器发起请求报文，经由路由器再转发到LVS服务器
第二步：报文通过LVS服务器的INPUT链时，发现客户端访问的是集群，于是强行改变数据流向，从INPUT链上强行扭转至POSTROUTING上。
第三步：报文从LVS服务器发出时，不对客户端的请求报文做任何的改动，仅在外面再附加一层网络层首部，外面这一层的源IP是DIP，而目标IP是RIP当中的其中一个。
第四步：数据包经由路由器然后再到互联网上，最后到达某一个R-SERVER，R-SERVER拆开最外层的网络层首部发现目标IP是自己的RIP，没错，是给自己的，再向再向下拆封装又遇到一个网络层首部，发现目标IP是自己的VIP，没错，还是给自己的，通常拆封装这一步，我们知道，R-server服务器要有两个IP，RIP其中一个必须是公网IP，通过RIP来接收LVS发送过来的报文，此外还要有另一个IP，即VIP，并且这一个VIP还必须和LVS的DIP的地址是一样的，为什么，因为R-servere要必须通过这个VIP回复客户端，为什么，因为客户端的目标就是VIP，用别的IP地址回应，客户端不会接收的。
第五步：R-SERVER回复报文，源IP是自己的VIP，而目标IP就客户端的IP地址，回复不经过LVS服务器。
总结：
转发方式：不修改请求报文的IP首部（源IP为CIP，目标IP为VIP），而在源IP报文之外再封装一个IP首部（源IP是DIP，目标IP是RIP），将报文发往挑选出的目标RS；RS直接响应给客户端（源IP是VIP，目标IP是CIP）
（1）DIP、VIP、RIP都应该是公网地址
（2）RS的网关一般不能指向DIP
（3）请求报文要经由LVS，但响应不经过LVS
（4）不支持端口映射
（5）RS的OS需要支持隧道功能。
tun模式有一个缺点，缺点就是由于再次封装了一个数据包，导致数据包过大。
LVS-fullnat模式
此类型内核默认不支持，应用场景非常少。
lvs-fullnat：通过同时修改请求报文的源IP地址和目标IP地址进行转发
CIP-----DIP
VIP-----RIP
- VIP是公网地址，RIP和DIP的私网地址，且通常不在同一个网络；因此，RIP的网关一般不会指向DIP。
- RS收到的请求报文源地址是DIP，因此，只需要响应给DIP；但director还要将其发往client。
- 请求和响应报文都经由derctor
- 支持端口映射
NOTE：DNAT只替换目标地址，源不动；full-nat的模式下全部替换
- DNAT和FULL-NAT都只可以隔路由器。
- 小项目用LVS，有钱的企业用F5。
- DR模型有一个局限性，DR模型只能在一个机房里面。
总结：
nat和fullnat请求和响应报文都必须经过LVS服务器，NAT的网关要指向DIP，FULLNAT的RIP和DIP不一定要在一个IP地址，但是要能通信。
dr和tun请求和响应的路径不一样，请求会经过LVS服务器，而响应不用经过；DR通过封装新的MAC首部实现转发，TUN通过在原来的报文外面再封装新的报文，支持远距离通信。
ipvsadm使用LVS在正式使用之前要打开核心转发功能
VIP一侧的操作
VIP一侧的操作就是明确使用哪个网卡做VIP，使用什么算法，还有一些增删改查
//安装
ipvsadm：yum -y install ipvsadm
//确认内核是否编译了LVS的功能
[root@n9 boot]# grep -i "ipvs" -C 10 config-3.10.0-957.el7.x86_64
LVS-VIP-端的操作，明确使用哪个网卡做VIP，使用什么算法
//A是增加，-E是更改，t是tcp，u是udp，services-adress指的VIP的地址，-s后面指定的是算法。
ipvsadmin -A|E -t|u VIP:PORT -s scheduler
ipvsadm -A -t 192.168.80.59:80 -s rr
//查看
[root@n9 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.80.59:80 rr
//更改，-E就会更改，并不用指序号
ipvsadm -E -t 192.168.80.59:80 -s wrr
//删除
[root@n9 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.80.59:80 wrr
[root@n9 ~]# ipvsadm -D -t 192.168.80.59:80
RIP一侧操作
增
ipvsadm -a|-e -t|u vip:port -r rip:port -g|i|m -w weigh
-a是增加
-e是改
-t是tcp
-u是udp
-r是指定VIP和VIP的端口
-g是要指定模式：-g dr模式；-i tun模式，-m nat模式
[root@n9 ~]# ipvsadm -a -t 192.168.80.59:80 -r 192.168.90.99:22 -m
[root@n9 ~]# ipvsadm -d -t 192.168.80.59:80 -r 192.168.90.99:22
改：
ipvsadm -e -t 192.168.80.59:80 -r 192.168.90.99:22 -m -w 3
查：
[root@n9 ~]# ipvsadm -Ln
TCP 192.168.80.59:80 rr
-> 192.168.90.8:80 Route 1 0 0
-> 192.168.90.9:80 Route 1 0 0
删除：
ipvsadmin -d -t|u vip:port -r rip:port
-> 192.168.90.8:80 Route 1 0 0
[root@n9 ~]# ipvsadm -d -t 192.168.80.59:80 -r 192.168.90.8:80
保存和导入
-n 不逆向解析，类似于ss -tnlp当中的n，平时用都加着
ipvsadm -S = ipvsadm-save
ipvsadm -R = ipvsadm-restore
-Z 清空计数器
-C 类似于iptables -F，全部干掉
[root@lvs ~]# ipvsadm -S -n
-A -t 192.168.80.10:80 -s sh
-a -t 192.168.80.10:80 -r 127.0.0.1:80 -g -w 1
[root@lvs ~]# ipvsadm -S -n > /tmp/lvs_config_file
[root@lvs ~]# cat /tmp/lvs_config_file
-A -t 192.168.80.10:80 -s sh
-a -t 192.168.80.10:80 -r 127.0.0.1:80 -g -w 1
[root@lvs ~]# ipvsadm -C
[root@lvs ~]# ipvsadm -Ln #全都没有了
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
[root@lvs ~]# ipvsadm -R < /tmp/lvs_config_file #恢复
[root@lvs ~]# ipvsadm -Ln
TCP 192.168.80.10:80 sh
-> 127.0.0.1:80 Route 1 0 0
状态查询
//最简单的查询
[root@lvs ~]# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.80.10:80 sh
-> 127.0.0.1:80 Route 1 0 0
forward：当前是什么模式，route代表是DR模式，如果Masq表示是NAT模式
weight：权重
activeconne：活动的连接数量
inactiveconne：非活动的连接数量
//查看当前建立的连接，-C就会清空
[root@lvs ~]# ipvsadm -Ln --connection
IPVS connection entries
pro expire state source virtual destination
TCP 01:58 FIN_WAIT 192.168.80.9:40400 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40406 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40408 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40418 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40416 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40402 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40414 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40412 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40404 192.168.80.10:80 127.0.0.1:80
TCP 01:58 FIN_WAIT 192.168.80.9:40410 192.168.80.10:80 127.0.0.1:80
//查看入站和出站包的数量
[root@lvs ~]# ipvsadm -Ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.80.10:80 10 70 0 4490 0
-> 127.0.0.1:80 10 70 0 4490 0
//查看包每秒的速率，CPS每秒建立的连接数
[root@lvs ~]# ipvsadm -Ln --rate
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress:Port
TCP 192.168.80.10:80 0 0 0 0 0
-> 127.0.0.1:80 0 0 0 0 0
//打开核心转发功能
sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
//nat模型，rr算法
[root@lvs ~]# ipvsadm -A -t 192.168.80.10:22 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.80.10:22 -r 192.168.90.11:22 -m
[root@lvs ~]# ipvsadm -a -t 192.168.80.10:22 -r 192.168.90.12:22 -m
[root@lvs ~]# ipvsadm -Ln
TCP 192.168.80.10:22 rr
-> 192.168.90.11:22 Masq 1 0 0
-> 192.168.90.12:22 Masq 1 0 0
//效果
[root@client ~]# for i in {1..10};do curl http://192.168.80.10 ;done
this is 90.12
this is 90.11
this is 90.12
this is 90.11
this is 90.12
this is 90.11
this is 90.12
this is 90.11
this is 90.12
this is 90.11
再尝试一下另外两种算法，WRR（加权轮询）和SH（源地址HASH）
//SH算法
[root@lvs ~]# ipvsadm -E -t 192.168.80.10:80 -s sh
[root@lvs ~]# ipvsadm -e -t 192.168.80.10:80 -r 192.168.90.11:80 -m
[root@lvs ~]# ipvsadm -e -t 192.168.80.10:80 -r 192.168.90.12:80 -m
[root@lvs ~]# ipvsadm -Ln
TCP 192.168.80.10:80 sh
-> 192.168.90.11:80 Masq 1 0 0
-> 192.168.90.12:80 Masq 1 0 0
[root@client ~]# for i in {1..10};do curl http://192.168.80.10 ;done
this is 90.11
this is 90.11
this is 90.11
this is 90.11
this is 90.11
this is 90.11
this is 90.11
this is 90.11
this is 90.11
this is 90.11
//如果90.11坏了，LVS依然还是正常转发，无法自动感知。
//wrr算法
[root@lvs ~]# ipvsadm -E -t 192.168.80.10:80 -s wrr
[root@lvs ~]# ipvsadm -e -t 192.168.80.10:80 -r 192.168.90.11:80 -m -w 1
[root@lvs ~]# ipvsadm -e -t 192.168.80.10:80 -r 192.168.90.12:80 -m -w 3
[root@lvs ~]# ipvsadm -Ln
TCP 192.168.80.10:80 wrr
-> 192.168.90.11:80 Masq 1 0 0
-> 192.168.90.12:80 Masq 3 0 0
[root@client ~]# for i in {1..10};do curl http://192.168.80.10 ;done
this is 90.12
this is 90.11
this is 90.12
this is 90.12
this is 90.12
this is 90.11
this is 90.12
this is 90.12
this is 90.12
this is 90.11
如果R-SERVER1挂了会有什么情况发生？
如果R-SERVER1挂了之后，LVS并不会自动感知，需要手工干预，将将的那台踢出去
R-SERVER坏了一台，还有另一台顶着，但如果两台R-SERVER都坏了呢？
我们可以让LVS服务器代替R-SERVER向客户端说sorrty，怎么做呢？就在LVS上也安装nginx或apche服务，然后将自己加入到ipvs规则里面，如下所示：
//当前ipvs里面只有一个vip端的配置，rip端的配置都删除 ，因为我们要模拟两台主机都坏的情况
ipvsadm -e -t 192.168.80.10:80 -r 127.0.0.1:80 -g
上面-g是使用DR模型，但这里我们是NAT模型，为什么要用DR模型呢？因为-m用NAT模型不好使！
//效果
[root@lvs ~]# ipvsadm -Ln
TCP 192.168.80.10:80 sh
-> 127.0.0.1:80 Route 1 0 0
[root@client ~]# for i in {1..10};do curl http://192.168.80.10 ;done
sorry!!!
sorry!!!
sorry!!!
sorry!!!
sorry!!!
sorry!!!
sorry!!!
sorry!!!
sorry!!!
sorry!!!
NOTE：
-
都是同一个网段。
-
哪个接口处理的，就从哪里出去。
R-SERVER1和R-SERVER2都需要两个IP地址，而且都得关闭arp的响应和通告，如果收的arp广播如果不是本网卡上就直接丢弃。
限制响应级别：arp_ignore
0：默认值，表示可使用本地任意接口上配置的任意地址进行响应；
1: 仅在请求的目标IP配置在本地主机的接收到请求报文接口上时，才给予响应；
限制通告级别：arp_announce
0：默认值，把本机上的所有接口的所有信息向每个接口上的网络进行通告；
1：尽量避免向非直接连接网络进行通告；
2：必须避免向非本网络通告；
//R-server1和R-SERVER2的配置脚本
#!/bin/bash
#
vip=192.168.80.99
mask='255.255.255.255'
case $1 in
start)
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
ifconfig lo:0 $vip netmask $mask broadcast $vip up
route add -host $vip dev lo:0
;;
stop)
ifconfig lo:0 down
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce
;;
*)
echo "Usage $(basename $0) start|stop"
exit 1
;;
esac
IP地址属于内核，而不属于网卡，举个例子：一台LINUX的两个网卡，A网卡（192.168.0.1）对应内网，B网卡对应外网（192.168.10.1），内网有一台主机：192.168.0.8，这台主机ping 192.168.0.1是通的，那么ping 192.168.10.1呢？还通吗？只要内网这台主机将网关设置为192.168.0.1，然后再ping 192.168.10.1就是通的，为什么？我们刚刚说过了呀！LINUX的地址都是属于内核的，只要数据包到达了网卡，就相当于到达了内核，只要是内核上有的地址就会进行回复。
在DR模型上我们要保证路由器arp广播VIP的MAC地址时，只能由LVS回复，R-SERVER不能回复，怎样才能捂住R-SERVER不让他们回复呢？可以通过设置内核参数，通过R-SERVER的物理网卡不要“多管闲事”，默认是“多管闲事”的，在没修改内核参数之前，它们收到不属于本网卡但属于内核的IP时默认就会回复，我们给设置了参数了之后，就会禁止这种多管闲事的机制，除了找 本网卡的数据包之外，其它的都不予回复，即使内核上有也不予回复，就是“各扫门前雪”，这样R-SERVER上的VIP就不会响应路由器发送的ARP询问报文了。
LVS不会动客户端报文的IP地址，仅仅改变了其源MAC和目标MAC，源MAC是自己DIP物理网卡的MAC，目标MAC是某一个R-SERVER，某一个R-SERVER收到LVS发送来的报文，先拆封装链路层发现就是给自己的，接着拆封装IP层，内核发现目标IP是192.168.80.99（VIP），而R-SERVER上就有这个IP地址，于是就会将这个报文交给l0:0（我们设置的环回网卡处理），在上述脚本当中的route add -host $vip dev lo:0的意思加一条路由，让内核收到目标IP是VIP的报文的时候，直接交给l0:0网卡来处理，因为一定要这个网卡进行处理，因为客户报文的目标IP就是VIP，我们回复的时候也要通过VIP做为源地址进行回复，当然R-SERVER要求都要有网关，这个网关不能指向LVS，而是指向直接的路由器，DR模式的回复报文不会流经LVS服务器。
//lvs网卡的配置
[root@lvs ~]# ifconfig eth0:0 192.168.80.99 netmask 255.255.255.255 broadcast 192.168.80.99 up
[root@lvs ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.80.10 netmask 255.255.255.0 broadcast 192.168.80.255
inet6 fe80::55e4:d33e:e51:7197 prefixlen 64 scopeid 0x20<link>
inet6 fe80::6ce6:89a4:63e2:73b5 prefixlen 64 scopeid 0x20<link>
inet6 fe80::2dec:48b:ef96:6371 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:6a:fe:ec txqueuelen 1000 (Ethernet)
RX packets 18973 bytes 9582304 (9.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10061 bytes 1130627 (1.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.80.99 netmask 255.255.255.255 broadcast 192.168.80.99
ether 00:0c:29:6a:fe:ec txqueuelen 1000 (Ethernet)
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 84 bytes 9093 (8.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 84 bytes 9093 (8.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
//LVS的IPVSADM配置
[root@lvs ~]# ipvsadm -A -t 192.168.80.99:80 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.80.99:80 -r 192.168.80.11 -g
[root@lvs ~]# ipvsadm -a -t 192.168.80.99:80 -r 192.168.80.12 -g
[root@lvs ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.80.99:80 rr
-> 192.168.80.11:80 Route 1 0 0
-> 192.168.80.12:80 Route 1 0 0
//客户端访问效果
[root@client ~]# for i in {1..10};do curl http://192.168.80.99 ;done
this is 90.12
this is 90.11
this is 90.12
this is 90.11
this is 90.12
this is 90.11
this is 90.12
this is 90.11
this is 90.12
this is 90.11
