LVS（虚拟服务器）实现负载均衡——DR模式
LVS简介
LVS，是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目。LVS由用户空间的ipvsadm和内核空间的IPVS组成，ipvsadm用来定义规则，IPVS利用ipvsadm定义的规则工作。现在LVS已经是 Linux标准内核的一部分，在Linux2.4内核以前，使用LVS时必须要重新编译内核以支持LVS功能模块，但是从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。
LVS特点：
通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。LVS的主要特点有以下几个方面：
高并发连接：LVS基于内核网络层面工作，有超强的承载能力和并发处理能力。单台LVS负载均衡器，可支持上万并发连接。 稳定性强：是工作在网络4层之上仅作分发之用，这个特点也决定了它在负载均衡软件里的性能最强，稳定性最好，对内存和cpu资源消耗极低。
成本低廉：硬件负载均衡器少则十几万，多则几十万上百万，LVS只需一台服务器和就能免费部署使用，性价比极高。
配置简单：LVS配置非常简单，仅需几行命令即可完成配置，也可写成脚本进行管理。
支持多种算法：支持多种论调算法，可根据业务场景灵活调配进行使用
支持多种工作模型：可根据业务场景，使用不同的工作模式来解决生产环境请求处理问题。
应用范围广：因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、DNS、ftp服务等等
缺点：工作在4层，不支持7层规则修改，机制过于庞大，不适合小规模应用。
LVS工作原理
-
当用户向负载均衡调度器（Director Server）发起请求，调度器将请求发往至内核空间
-
PREROUTING链首先会接收到用户请求，判断目标IP确定是本机IP，将数据包发往INPUT链
-
IPVS是工作在INPUT链上的，当用户请求到达INPUT时，IPVS会将用户请求和自己已定义好的集群服务进行比对，如果用户请求的就是定义的集群服务，那么此时IPVS会强行修改数据包里的目标IP地址及端口，并将新的数据包发往POSTROUTING链
-
POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器，那么此时通过选路，将数据包最终发送给后端的服务器
LVS组成
LVS 由两部分程序组成，包括ipvs 和ipvsadm。
1.ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。
- ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)。就像iptables和netfilter的关系一样。
ipvs是集成在内核中的框架，可以通过用户空间的程序 ipvsadm 工具来管理，该工具可以定义一些规则来管理内核中的ipvs。就像iptables和netfilter的关系一样
LVS的相关术语
- DS：Director Server。指的是前端负载均衡器节点。调度器
- RS：Real Server。后端真实的工作服务器。
- VIP：virtual IP，向外部直接面向用户请求，作为用户请求的目标的IP地址。LVS服务器上接收外网数据报文的网卡IP地址。位于DS上
- DIP：Director Server IP，主要用于和内部主机通讯的IP地址。LVS服务器上发送数据报文到RS的网卡IP地址。位于DS上
- RIP：Real Server IP，后端服务器的IP地址。
- CIP：Client IP，客户端的IP地址
LVS——DR模式的工作原理
(1) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP
(2) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
(3) IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址
(4) 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。
(5) RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP
(6) 响应报文最终送达至客户端
LVS——DR模式的特性
1、保证前端路由将目标地址为VIP报文统统发给Director Server，而不是RS
2、RS可以使用私有地址；也可以是公网地址，如果使用公网地址，此时可以通过互联网对RIP进行直接访问
3、RS跟Director Server必须在同一个物理网络中
4、所有的请求报文经由Director Server，但响应报文必须不能进过Director Server
5、不支持地址转换，也不支持端口映射
6、RS可以是大多数常见的操作系统
7、RS的网关绝不允许指向DIP
8、RS上的lo接口配置VIP的IP地址
9、RS和DS必须在统一局域网
实验步骤：
在负载均衡器（172.25.69.1）
需要ipvsadm编写策略
yum install ipvsadm
vim /etc/sysconfig/ipvsadm-config
IPVS_SAVE_ON_RESTART=“yes”
这时重启服务回报错：/bin/bash: /etc/sysconfig/ipvsadm: No such file or directory
建立文件：touch /etc/sysconfig/ipvsadm
再次重启服务：systemctl restart ipvsadm.service
编写策略
ipvsadm -A -t 172.25.69.100:80 -s rr 当访问172.25.69.100时进行轮询
ipvsadm -a -t 172.25.69.100:80 -r 172.25.69.2:80 -g -w 1 设置访问权重
ipvsadm -a -t 172.25.69.100:80 -r 172.25.69.3:80 -g -w 1 每个服务器一次轮询
ipvsadm -ln #显示内核虚拟服务器表和输出IP地址和端口的数字形式
##ipvsadm -C## #删除策略
添加虚拟ip
ip addr add 172.25.69.100/32 dev eth0
在后端服务器（172.25.69.2和172.25.69.3）
下载http服务并添加默认页面
yum install httpd
添加虚拟ip
ip addr add 172.25.69.100/32 dev eth0
客户端测试
测试时会发现获取的信息并不是从负载均衡服务器获得的，这是因为三台服务器都有虚拟172.25.69.100/32的ip，发送请求时会随机发给三个服务器中的随意一个，所以每次获取的地址都是不同的，因为三台机器都能接收访问，所以访问时三台服务都可以回复信息
解决方案：给后端服务器添加策略
yum install arptables
arptables -A INPUT -d 172.25.69.100 -j DROP 将访问172.25.27.100的访问丢弃
arptables -A OUTPUT -s 172.25.69.100 -j mangle --mangle-ip-s 172.25.69.2
将172.25.69.100回复的信息伪装为172.25.69.2
再次测试
这次回复的信息都是从sfj1（负载均衡服务器）发来的
自动检测后端服务器是否可用
负载均衡器
添加yum源
/var/www/html/westos/addons/HighAvailability
获取安装包
安装 ldirectord-3.9.5-3.1.x86_64.rpm
添加配置文件，修改
cp /usr/share/doc/ldirectord-3.9.5/ldirectord.cf /etc/ha.d/
vim /etc/ha.d/ldirectord.cf
virtual=172.25.69.100:80 #访问的IP
real=172.25.69.2:80 gate #第一个后端服务器
real=172.25.69.3:80 gate #第二个后端服务器
fallback=127.0.0.1:80 gate #如果两个后端服务器都无法访问，则访问本机
service=http
scheduler=rr
#persistent=600
#netmask=255.255.255.255
protocol=tcp
checktype=negotiate
checkport=80
request="index.html"
#receive="Test Page"
#virtualhost=www.x.y.z
删除原有规则，重启服务后自动添加配置文件中的规则
客户端测试
直接访问进行轮询
关掉sfj2的httpd服务,策略自动删除sfj2，只访问sfj3
再关掉sfj3的httpd服务，访问sfj1
重新开启sfj2的httpd服务，只访问sfj2
重新开启sfj3的httpd服务，又开始sfj2与sfj3轮询
（Keepalived 高可用集群管理）添加备用负载均衡器
在负载均衡器（sfj1）上
获取压缩包
tar zxf keepalived-2.0.6.tar.gz
cd keepalived-2.0.6
yum install gcc openssl-devel -y #解决依赖性
./configure --prefix=/usr/local/keepalived --with-init=systemd #源码编译
make && make install #安装
ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/keepalived/sbin/keepalived /sbin/
ln -s /usr/local/keepalived/etc/keepalived /etc/
#keepalived自带健康检查,所以不需要ldirectord来健康检查
修改配置文件
vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id LVS_DEVEL
vrrp_skip_check_adv_addr
#vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 78
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.25.69.100
}
}
virtual_server 172.25.69.100 80 {
delay_loop 3
lb_algo rr
lb_kind DR
# persistence_timeout 50
protocol TCP
real_server 172.25.69.2 80 {
TCP_CHECK {
weight 1
connect_port 80
connect_timeout 3
}
}
real_server 172.25.69.3 80 {
TCP_CHECK {
weight 1
connect_port 80
connect_timeout 3
}
}
}
启动服务
systemctl start keepalived
服务器启动后自动添加虚拟ip172.25.69.100/32
在备用负载均衡服务器（sfj4）进行同样的配置
配置文件中修改
18 state BACKUP ##备用节点
21 priority 50 ##优先级，比sfj1低即可
启动服务后没有虚拟ip，因为sfj4为备用节点
后端服务器
sfj2，sfj3
下再httpd服务并配置相关页面
客户端测试
服务器都正常运行时，信息都来自sfj1
关掉sfj2的httpd服务，只访问到sjf3，信息来自sfj1
重新打开sfj2的httpd服务，又恢复正常
当主负载均衡服务器（sfj1）down掉
sfj1 中的虚拟ip（172.25.69.100/32）自动删除
备用服务器sfj4自动添加虚拟ip（172.25.69.100/32）
客户端继续访问，信息来源变为sfj4
重新打开sfj1负载均衡服务器，sfj4的虚拟ip消失，sfj1重新获得虚拟ip
客户端再次访问，信息来源又变成sfj1
因为sfj1 的优先级高于sfj4 所以只要sfj1 恢复正常，便会顶替sfj4作为服务器