Linux Enterprise 之 LVS+KeepAlived
1. LVS
1.1 LVS简介
LVS：Linux Virtual Server ，即Linux虚拟服务器，是一个虚拟的服务器集群系统，可以实现负载均衡集群功能（UNIX/LINUX平台）
- LVS集群负载均衡器接受服务的所有客户端请求，并根据调度算法决定哪个集群节点应该处理回复请求。负载均衡器（简称LB）
- 一组服务器通过高速的局域网或广域网相互连接，在他们的前端有一个负载调度器（Load Balancer）。 负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户无感知，客户访问集群系统提供的网络服务就像访问一台高性能，高可用的服务器一样。客户程序不受服务器集群的影响不需要作任何修改。通过检测节点或服务进程故障和正确地重置系统达到高可用性。
命名约定表：
| 名称 | 简写 | 说明 |
|---|---|---|
| 虚拟IP | VIP | LB用于向客户端计算机提供服务的IP地址 |
| 真实IP | RIP | 在集群下面节点上使用的IP地址，真实提供服务的IP地址 |
| Dirctor的IP | DIP | 连接内外网络的IP地址。负载均衡器上的IP |
| 客户端IP | CIP | 客户端请求集群服务器的IP地址，源IP |
1.2 LVS集群的工作模式
- NAT（Network Address Translation）
- TUN（Tunneling）
- DR（Direct Routing）
- FULLNAT（Full Network Address Translation）
1.2.1 NAT 网络地址转换（简单了解）
- 在接受客户端请求而调度时，通过DNAT（目的地址转换）将目的IP改为RIP
- 在后段服务器处理请求返回数据包时，通过SNAT（源地址转换）将源IP改为VIP （因为与客户端TCP/IP握手时需要使用VIP才能成功）
1.2.2 TUN 隧道模式
- 在外面增加了一层IP头部，可以跨网段找到真实服务器节点，通过IP隧道通信
- 负载均衡器把请求的报文通过IP隧道的方式转发给RS，而RS将处理后的数据直接返回给客户端。
1.2.3 DR直接路由模式
DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器将响应后的处理结果直接返回给客户端用户。而且，DR模式没有IP隧道的开销，对集群RS节点也没有IP隧道协议的要求，但是要求调度器LB与正式服务器RS节点都有一块网卡连在同一物理网段上也就是说必须在同一个局域网环境。
注：只修改目标MAC地址，通过MAC找到RS节点（通过二层MAC传输，无法跨网段找到RS节点）
实验1： DR模式
| IP | 角色 | 备注 |
| 192.168.1.1 | 客户端 | |
| 192.168.1.11 | LB调度器 | 对外提供VIP 192.168.1.100 |
| 192.168.1.12 | RS1 | |
| 192.168.1.13 | RS2 |
在LB的主机上安装ipvsadm
yum install ipvsadm -y
vim /etc/sysconfig/ipvsadm-config ##修改配置文件，服务重启时保存IPVS规则
启动服务
systemctl start ipvsadm.service 
发现报错，查看日志
journalctl -xe
发现是找不到/etc/sysconfig/ipvsadm文件，新建该文件再启动
启动成功
添加IP(临时)，如果要永久配置需要更改网卡配置文件
ip addr add 192.168.1.100/24 dev eth0 ##注意这里eth0是设备名，需要根据实际情况修改
配置lvs，并添加两台RS节点
ipvsadm -A -t 192.168.1.100:80 -s rr
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12:80 -g
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.13:80 -g
# -A：添加一个虚拟路由主机（LB）
# -t：指定虚拟路由主机的VIP地址和监听端口
# -s：指定负载均衡算法
# -p：指定会话保持时间
# -a：添加RS节点
# -r：指定RS节点的RIP地址和监听端口
# -g：指定DR模式
# 这里使用rr轮询算法所以没有使用 -w参数，可以通过-w参数指定权值
# ipvsadm -C 清空LVS
这时候在客户端测试，发现还是无法正常获得返回数据
因为DR模式是RS直接返回数据给客户端，而客户端请求的是VIP，无法完成握手
手动在RS节点添加192.168.1.100 IP
ip addr add 192.168.1.100/24 dev eth0
再在客户端测试
发现一次成功，一次错误
这是因为我的server3主机为开启httpd服务
去开启后再测试
这时候是server2和server3轮询
在LB调度器可以查看，各访问了三次
注意：因为在DR模式下，RS节点和LVS同处一个局域网网段内，当网关通过ARP广播试图获取VIP的MAC地址的时候LVS和RS节点都会接收到ARP广播并且LVS和节点都绑定了VIP，所以都会去响应这个广播，导致冲突现象。
解决方法：
在RS节点安装arptables
yum install arptables.x86_64 -y
启动服务
systemctl start arptables.service 添加规则（类似iptables）
arptables -A INPUT -d 192.168.1.100 -j DROP
arptables -A OUTPUT -s 192.168.1.100 -j mangle --mangle-ip-s 192.168.1.12
# 接收时目的地址为192.168.1.100的全丢弃 响应时192.168.1.12源地址伪装成192.168.1.100
保存规则
arptables-save /etc/sysconfig/arptables
另一台RS做同样的设置
实验2：TUN 隧道模式
先清空ipvsadm
隧道模式需要使用一个模块
modprobe ipip #启用模块
配置LVS，添加RS节点
记得将VIP绑定到隧道上（RS节点也需要开启隧道并绑定VIP）
开启隧道（LB和RS都需要）
ifconfig tunl0 up
最后记得在（所有）RS节点一定要关闭反向校验
关闭
测试
在LB所在主机查看
2. LVS+KeepAlived实现高可用负载均衡
2.1 安装KeepAlived
在官网下载安装包，解压
编译安装(解决依赖，需要openssl)
安装好后修改配置文件
vim keepalived.conf
在server4也安装keepalived
配置如下
其余配置与server1保持一致
将上一个实验的隧道全部清除，启动服务
可以ipvsadm看到自动生成规则
这时启动server1的keepalived
可以看到server1自动生成VIP和ipvsadm规则
同时server4的VIP这时候会取消
因为server1的keepalived优先级为100高于server4的80
RS节点配置与单独配置LVS时相同
server4日志
测试
server2和server3都正常时
server2关闭httpd
可以看到，server2 down时，只会访问server3
开启server2
又恢复正常
这时候关闭server1的keepalived
server4接管，不影响客户感知
查看server4日志
查看邮件
邮件通知server2 down了一段时间 后来又up了