本文详细介绍LVS-DR模式的原理与配置步骤，包括负载均衡的实现方式、健康检查及高可用方案，并探讨常见问题及其解决方案。
一、什么是lvs
1、lvs的定义
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。是由章文嵩博士开发的一款开源软件，1998年5月发布，是中国国内最早出现的自由软件项目之一。
LVS工作在一台server上提供Directory(负载均衡器)的功能，本身并不提供服务，只是把特定的请求转发给对应的realserver(真正提供服务的主机)，从而实现集群环境中的负载均衡。LVS的核心组件ipvs工作在kernel中，是真正的用于实现根据定义的集群转发规则把客户端的请求转发到特定的realserver。而另一个组件ipvsadm是工作在用户空间的一个让用户定义ipvs规则的工具。故我们只要在server上装了ipvsadm软件包就可以定义ipvs规则，而在linux kernel的2.6版本之后kernel是直接支持ipvs的。
2、LVS的模型中的主要角色：
调度器:Director，又称为Dispatcher，Balancer，调度器主要用于接受用户请求。
真实主机:Real Server，简称为RS，用于真正处理用户的请求。
Director Virtual IP:调度器用于与客户端通信的IP地址，简称为VIP
Real Server : 后端主机的用于与调度器通信的IP地址，简称为RIP。
3、lvs的三种模式：
在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation），大多数商品化的IP负载均衡调度器产品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和Alteon的ACEDirector。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。所以，IPVS软件实现了这三种IP负载均衡技术，它们的大致原理如下：
1.Virtual Server via Network Address Translation（VS/NAT）
通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
2.Virtual Server via IP Tunneling（VS/TUN）
采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报 文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。
3.Virtual Server via Direct Routing（VS/DR）
VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。
4、LVS 的负载调度算法：
在内核中的连接调度算法上,IPVS 已实现了以下八种调度算法:
1.轮叫调度(Round-Robin Scheduling )
轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行 i = (i + 1) mod n,并选出第 i 台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。
2.加权轮叫调度(Weighted Round-Robin Scheduling )
加权轮叫调度 (Weighted Round-Robin Scheduling)算法可以解决服务器间性能不一的情况,它用相应的权值表示服务器的处理性能,服务器的缺省权值为 1。假设服务器 A 的权值为 1,B 的 权值为 2,则表示服务器 B 的处理性能是 A 的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服务器比权值低的服务器处理更多的连接,相同权值的服务器处理相同数目的连接数。
3.最小连接调度(Least-Connection Scheduling )
最小连接调度(Least- Connection Scheduling)算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加 1;当连接中止或超时,其连接数减一。
4.加权最小连接调度(Weighted Least-Connection Scheduling)
加权最小连接调 度(Weighted Least-Connection Scheduling)算法是最小连接调度的超集,各个服务器用相应的权值表示其处理性能。服务器的缺省权值为 1,系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。
5.基于局部性的最少链接(Locality-Based Least Connections Scheduling)
基于局部性的最少链接调度(Locality-Based Least Connections Scheduling,以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率,从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址 找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于其一半的工作负载,则用 “最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。
6.带复制的基于局部性最少链接(Locality-Based Least Connections with Replication Scheduling)
带复制的基于局部性最少链接调度(Locality-Based Least Connections with Replication Scheduling,以下简称为 LBLCR)算法也是针对目标IP地址的负载均衡,目前主要用于Cache 集群系统。它与LBLC算法的不同之处是它要 维护从一个目标IP地址到一组服务器的映射,而 LBLC 算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求,一台Cache服务器可能会忙不过来处理这些请求。这时,LBLC调度算法会从所有的Cache 服务器中按“最小连接”原则选出一台Cache服务器,映射该“热门”站点到这台Cache服务器,很快这台Cache服务器也会超载,就会重复上述过程选出新的Cache服务器。这样,可能会导致该“热门”站点的映像会出现在所有的Cache服务器上,降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合),当该“热门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache服务器数目。这样,该“热门”站点的映像不太可能出现在所有的Cache服务器上,从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按“最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服 务器从服务器组中删除,以降低复制的程度。
7.目标地址散列调度(Destination Hashing Scheduling )
目标地址散列调度(Destination Hashing Scheduling)算法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否
则返回空。
8.源地址散列调度(Source Hashing Scheduling)
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求的目标IP地址换成请求的源IP地址,所以这里不一一叙述。在实际应用中,源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。
二、LVS-DR模式简介
DR模式（直接路由模式）是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样，DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销，对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上，必须在同一个局域网环境中。
DR模式原理过程简述：
VS/DR模式的工作流程图如上图所示，它的连接调度和管理与NAT和TUN中的一样，它的报文转发方法和前两种不同。DR模式将报文直接路由给目标真实 服务器。在DR模式中，调度器根据各个真实服务器的负载情况，连接数多少等，动态地选择一台服务器，不修改目标IP地址和目标端口，也不封装IP报文，而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实服务器的MAC地址，并且又在同一个局域网。那么根据局域网的通讯原理，真实复位是一定能够收到由LB发出的数据包。真实服务器接收到请求数据包的时候，解开IP包头查看到的目标IP是VIP。（此时只有自己的IP符合目标IP才会接收进来，所以我们需要在本地的回环借口上面配置VIP。另：由于网络接口都会进行ARP广播响应，但集群的其他机器都有这个VIP的lo接口，都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉。）然后真实服务器做成请求响应，之后根据自己的路由信息将这个响应数据包发送回给客户，并且源IP地址还是VIP。
三、lvs-dr模式下的负责均衡
实验环境：
物理机：172.25.9.250
vip：172.25.9.100
server1（VS）：172.25.9.1
server2（VS）：172.25.9.2
server3（RS）：172.25.9.3
server4（RS）：172.25.9.4
1、在server1中：
1.更改yum仓库设置
vim /etc/yum.repos.d/rhel-source.repo
添加
[LoadBalancer]
name=LoadBalancer
baseurl=http://172.25.9.250/rhel6.5/LoadBalancer
gpgcheck=0
[HighAvailability]
name=HighAvailability
baseurl=http://172.25.9.250/rhel6.5/HighAvailability
gpgcheck=0
[ResilientStorage]
name=ResilientStorage
baseurl=http://172.25.9.250/rhel6.5/ResilientStorage
gpgcheck=0
[ScalableFileSystem]
name=ScalableFileSystem
baseurl=http://172.25.9.250/rhel6.5/ScalableFileSystem
gpgcheck=0
2.安装ipvsadm工具
yum install -y ipvsadm #管理集群服务的命令行工具
3.添加vip
ipvsadm -A -t 172.25.9.100:80 -s rr #临时添加vip，rr轮询模式
ipvsadm -a -t 172.25.9.100:80 -r 172.25.9.3:80 -g #给vip添加rip，使用DR模式 -g为DR模式
ipvsadm -a -t 172.25.9.100:80 -r 172.25.9.4:80 -g
ipvsadm -l #显示内核虚拟服务器表
ipvsadm -ln #ip方式显示内核虚拟服务器表
#拓展
-g #--gatewaying 指定LVS 的工作模式为直接路由模式（DR模式）
-i #--ipip 指定LVS 的工作模式为隧道模式（TUN模式）
-m #--masquerading 指定LVS 的工作模式为NAT 模式
2、在server3中
配置好apache
yum install -y httpd
vim /var/www/html/index.html
<h1>server3</h1>
/etc/init.d/httpd start
3、在server4中
配置好apache
yum install -y httpd
vim /var/www/html/index.html
<h1>server4</h1>
/etc/init.d/httpd start
4、测试
物理机中curl 172.25.9.100 访问失败
在server1中：
ip addr add 172.25.9.100/24 dev eth0
在物理机中curl 172.25.9.100 访问失败
但是此时在server1中 ipvsadm -ln 可以发现随着物理机访问172.25.9.100失败次数增多
ipvsadm -ln中InActConn数值增加，此时说明调度器配置成功，再去配置server3与server4
在server3中：
ip addr add 172.25.9.100/32 dev lo
在server4中：
ip addr add 172.25.9.100/32 dev lo
在物理机中for i in {1..10};do curl 172.25.9.100;done查看轮询结果
发现循环得到server3与server4中相应的index.html文件内容
在物理机中：
arp -an | grep 100 得到vip的vmac地址，此时vmac地址为server1中eth0网卡的mac地址
arp -d 172.25.9.100 清除vmac
ping 172.25.9.100 得到新vmac
arp -an | grep 100 查看新得到的vmac为server3或server4的eth0网卡mac
for i in {1..10};do curl 172.25.9.100;done 查看结果均为之前的server3或server4中相应的index.html文件内容
在server1中：
ipvsadm -ln 发现server3与server4两个后端仍然存在，但是物理机中访问172.25.9.100次数
增加后InActConn数值不变，此时说明没有使用vm调度器,直接去后端server3或server4上读取相应的index.html文件内容
5、隐藏RS上的VIP
DR模式工作在链路层，采用了arp协议，rs表示realserver，vs表示vitrualserver，假设client的ip为cip，mac地址为m1，调度器vs的ip为vip，mac地址为m2，后端服务器的ip为rip，mac地址为m3，由于DR模式工作在数据链路层，没有经过路由器，所以vs和rs必须在同一个网段，当client访问vip时，在DR模式下，vs通过它本身的一些算法m2改为m3，这样就可以实现直接将数据包丢给rs（这里rs上必须有vip，因为客户端访问的是vip），rs通过解封，得到了vip，通过与自己vip匹配判断数据包确实是给自己的，rs在通过封装，直接将数据发给client，数据包不用原路返回）。由于vs和rs上都有vip，会有冲突，因此这里我们应用arptables协议，在rs上添加策略，控制数据传输
此时有两种方法可以解决，本次实验采用第二种方法
方法一：更改RealServer设置
在server3中
vi /etc/sysctl.conf
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
sysctl -p
在server4中
vi /etc/sysctl.conf
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
sysctl -p
方法二：通过arptables_jf工具更改网络
在server3中：
1.安装arptables_jf工具
yum install -y arptables_jf
2.配置网络
arptables -A IN -d 172.25.9.100 -j DROP #由于在同一个Vlan中，不同机器中相同ip会冲突，此时使用arp火墙将vip拦截
arptables -A OUT -s 172.25.9.100 -j mangle --mangle-ip-s 172.25.9.3 #将rip伪装成vip
arptables -L
#拓展：
mangle #伪装，由于tcp三次握手，出去时仍要以vip地址形式才会握手，而真正将数据传给客户端的是RS，所以这里需要mangle伪装。
3.保存配置
/etc/init.d/arptables_jf save #保存arp火墙配置信息
在server4中：
1.安装arptables_jf工具
yum install -y arptables_jf
2.配置网络
arptables -A IN -d 172.25.9.100 -j DROP
arptables -A OUT -s 172.25.9.100 -j mangle --mangle-ip-s 172.25.9.4
arptables -L
3.保存配置
/etc/init.d/arptables_jf save
6、测试：
在物理机中：
arp -an |grep 100 #查看vip的vmac
arp -d 172.25.9.100 #清除vip的vmac
for i in {1..10};do curl 172.25.9.100;done
发现循环得到server3与server4中相应的index.html文件内容
二、健康检查
ldirectord是专门为LVS监控而编写的，用来监控lvs架构中服务器池（server pool） 的服务器状态。
ldirectord 运行在 IPVS 节点上， ldirectord作为一个守护进程启动后会对服务器池中的每个真实服务器发送请求进行监控,如果服务器没有响应 ldirectord 的请求，那么ldirectord 认为该服务器不可用， ldirectord 会运行 ipvsadm 对 IPVS表中该服务器进行删除，如果等下次再次检测有相应则通过ipvsadm 进行添加。
1、在server1中：
1.下载ldirectord安装包，使用yum安装
yum install -y ldirectord-3.9.5-3.1.x86_64.rpm
2.更改ldirectord配置文件
rpm -ql ldirectord
cp /usr/share/doc/ldirectord-3.9.5/ldirectord.cf /etc/ha.d/
cd /etc/ha.d
ls
vim ldirectord.cf
更改其中virtual内容如下：
virtual=172.25.9.100:80
real=172.25.9.3:80 gate
real=172.25.9.4: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
3.安装并开启apache
注意：当ipvsadm的后端全部down掉后可以使用自身的lo充当后端设备
yum install httpd -y
/etc/init.d/httpd start
4.配置apache共享网页
vim /var/www/html/index.html
网站正在维护中，请稍后访问
5.清除ipvsadm缓存
ipvsadm -C
6.启动ldirectord工具
/etc/init.d/ldirectord start
ipvsadm -l
2、测试
物理机中 for i in {1..10};do curl 172.25.9.100;done 查看轮询结果
server3中 /etc/init.d/httpd stop ,down掉server3后
在server1中 ipvsadm -l 发现没有了server3的后端
在物理机中 for i in {1..10};do curl 172.25.9.100;done 查看轮询结果
仅有server4相应的index.html文件内容
server4中 /etc/init.d/httpd stop ,down掉server4后
在server1中 ipvsadm -l 发现也没有了server4的后端，仅存在server1的lo
在物理机中 for i in {1..10};do curl 172.25.9.100;done 查看轮询结果
仅有server1相应的index.html文件内容
server3中 /etc/init.d/httpd start
在server1中 ipvsadm -l 发现有了server3的后端,没了sever1的lo
在物理机中 for i in {1..10};do curl 172.25.9.100;done 查看轮询结果
仅有server3相应的index.html文件内容
server4中 /etc/init.d/httpd start
在server1中 ipvsadm -l 发现增加了server4的后端
在物理机中 for i in {1..10};do curl 172.25.9.100;done 查看轮询结果
发现循环得到server3与server4中相应的index.html文件内容
三、lvs+keepalived实现服务高可用
Keepalived在这里主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP主机之间failover的实现。IPVS通常与keepalived配合使用，后者也是LVS项目的子项目之一，用于检测服务器的状态。
在lvs体系中，Keepalived主要有如下3个功能：
1 管理LVS负载均衡软件
2 实现对LVS集群节点的健康检查功能
3 作为系统网络服务的高可用功能
主机环境:RHEL6 系列 selinux and iptables disabled
实验主机:
LVS ‐ ACTIVE: 172.25.9.1
LVS ‐ BACKUP: 172.25.9.2
LVS ‐ VIP: 172.25.9.100
Realsever: 172.25.9.3 172.25.9.4
1、在server1中关闭ldirectord
/etc/init.d/ldirectord stop
chkconfig ldirectord off
chkconfig --list ldirectord
2、主备机上的软件包安装与配置
1.在server1中：
yum install openssl-devel mailx -y
tar zxf keepalived-2.0.6.tar.gz
cd keepalived-2.0.6
./configure --prefix=/usr/local/keepalived --with-init=SYSV #转换成二进制可执行文件
make #编译
make install #安装
chmod +x /usr/local/keepalived/etc/rc.d/init.d/keepalived
ln -s /usr/local/keepalived/sbin/keepalived /sbin/
ln -s /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/keepalived/etc/keepalived /etc/
vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs { #全局配置标识
notification_email {
root@localhost #接收警报的 email 地址,可以添加多个，每行一个
}
notification_email_from keepalived@localhost #设置邮件的发送地址
smtp_server 127.0.0.1 #设置 smtp server 地址
smtp_connect_timeout 30 #设置连接 smtp 服务器超时时间
router_id LVS_DEVEL #load balancer 的标识 ID,用于 email 警报
vrrp_skip_check_adv_addr
#vrrp_strict #严格执行VRRP协议规范，此模式不支持节点单播，必须注释，否则它会自动给server1上防火墙加一条策略，导致实验不能进行
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER #此状态是由 priority 的值来决定的,当前priority 的值小于备机的值,那么将会失去 MASTER 状态
interface eth0 #HA 监测网络接口
virtual_router_id 51 #主、备机的 virtual_router_id 必须相同,取值 0-255
priority 100 #主机的优先级,主机优先级一定要大于备机
advert_int 1 #主备之间的通告间隔秒数
authentication { #主备切换时的验证
auth_type PASS #设置验证类型,主要有 PASS 和 AH 两种
auth_pass 1111 #设置验证密码,在一个 vrrp_instance 下,MASTER 与 BACKUP 必须使用相同的密码才能正常通信
}
virtual_ipaddress { #设置虚拟 IP 地址,可以设置多个虚拟 IP 地址,每行一个
172.25.9.100
}
}
virtual_server 172.25.9.100 80 { #定义虚拟服务器
delay_loop 6 #每隔 6 秒查询 realserver 状态
lb_algo rr #lvs 调度算法,这里使用轮叫
lb_kind DR #LVS 是用 DR 模式
#persistence_timeout 50 #会话保持时间,单位是秒
#这个选项对于动态网页是非常有用的,为集群系统中 session 共享提供了一个很好的解决方案。
有了这个会话保持功能,用户的请求会被一直分发到某个服务节点,直到超过这个会话保持时间。
需要注意的是,这个会话保持时间,是最大无响应超时时间,也就是说用户在操作动态页面时,如果在 50 秒内没有执行任
何操作,那么接下来的操作会被分发到另外节点,但是如果一直在操作动态页面,则不受 50 秒的时间限制。
此时方便测试我们需要注销它
protocol TCP #指定转发协议类型,有 tcp 和 udp 两种
real_server 172.25.9.3 80 { #配置服务节点
weight 1 #配置服务节点的权值
#权值大小用数字表示,数字越大,权值越高,设置权值的大小可以为不同性能的服务器分配不同的负载,可以对性能高的服务器设
置较高的权值,而对性能较低的服务器设置相对较低的权值,这样就合理的利用和分配了系统资源
TCP_CHECK { #realserve 的状态检测设置部分,单位是秒
connect_timeout 3 #3秒无响应超时
retry 3 #重试次数
delay_before_retry 3 #重试间隔
}
}
real_server 172.25.9.4 80 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 3
}
}
}
/etc/init.d/keepalived start
cat /var/log/messages
scp -r /usr/local/keepalived/ server2:/usr/local
scp /etc/yum.repos.d/rhel-source.repo server2:/etc/yum.repos.d/
2.在server2中：
yum install ipvsadm mailx -y
chmod +x /usr/local/keepalived/etc/rc.d/init.d/keepalived
ln -s /usr/local/keepalived/sbin/keepalived /sbin/
ln -s /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/keepalived/etc/keepalived /etc/
vim /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51 #主、备机的 virtual_router_id 必须相同,取值 0-255
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass 1111 #设置验证密码,在一个 vrrp_instance 下,MASTER 与 BACKUP 必须使用相同的密码才能正常通信
}
virtual_ipaddress {
172.25.9.100
}
}
/etc/init.d/keepalived start
cat /var/log/messages
3、测试:
1. 高可用测试:停止 master 上的 keepalived 服务,看 backup 是否接管。
2. 负载均衡测试:物理机连续curl vip，查看是否达到负载均衡
可以通过 ipvsadm -Lnc 查看详细连接情况
3. 故障切换测试:任意关闭 realserver 上的 httpd 服务,Keepalived 监控模块是否能及时发现,
然后屏蔽故障节点,同时将服务转移到正常节点来执行。
四、lvs+keepalived应用情况
1、一个vip拥有两个端口在两台主机上负载均衡
1.在server3中：
yum install vsftpd -y
/etc/init.d/vsftpd start
2.在server4中：
yum install vsftpd -y
/etc/init.d/vsftpd star
3.在server1中：
vim /etc/keepalived/keepalived.conf
最后面添加：
virtual_server 172.25.9.100 21 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP
real_server 172.25.9.3 21 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 3
}
}
real_server 172.25.9.4 21 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 3
}
}
}
/etc/init.d/keepalived restart
4.在server2中：
vim /etc/keepalived/keepalived.conf
添加与server1中/etc/keepalived/keepalived.conf同样的内容
/etc/init.d/keepalived restart
5.测试：
物理机连续curl vip，查看是否达到负载均衡
物理机lftp vip，查看是否能够查看共享目录
高可用测试:停止 master 上的 keepalived 服务,看 backup 是否接管
2、二个vip拥有两个端口在两台主机上互为主备实现负载均衡
1.在server1中：
vim /etc/keepalived/keepalived.conf
添加
vrrp_instance VI_2 {
state BACKUP
interface eth0
virtual_router_id 52
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.25.9.200
}
}
更改ip
virtual_server 172.25.9.200 21 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP
/etc/init.d/keepalived restart
2.在server2中：
vim /etc/keepalived/keepalived.conf
添加
vrrp_instance VI_2 {
state MASTER
interface eth0
virtual_router_id 52
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.25.9.200
}
}
更改ip
virtual_server 172.25.9.200 21 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP
/etc/init.d/keepalived restart
3.在server3中：
ip addr add 172.25.9.200/32 dev lo
arptables -A IN -d 172.25.9.200 -j DROP
arptables -A OUT -s 172.25.9.200 -j mangle --mangle-ip-s 172.25.9.3
/etc/init.d/arptables_jf save
4.在server4中
ip addr add 172.25.9.200/32 dev lo
arptables -A IN -d 172.25.9.200 -j DROP
arptables -A OUT -s 172.25.9.200 -j mangle --mangle-ip-s 172.25.9.4
/etc/init.d/arptables_jf save
5.测试：
物理机连续curl 对应vip，查看是否达到负载均衡
物理机lftp 对应vip，查看是否能够查看共享目录
高可用测试:停止 master 上的 keepalived 服务,看 backup 是否接管
五、lvs常见问题
1. LVS/DR 如何处理请求报文的,会修改 IP 包内容吗?
1.1 vs/dr 本身不会关心 IP 层以上的信息,即使是端口号也是 tcp/ip 协议栈去判断是否正确,vs/dr 本
身主要做这么几个事:
1)接收 client 的请求,根据你设定的负载均衡算法选取一台 realserver 的 ip;
2)以选取的这个 ip 对应的 mac 地址作为目标 mac,然后重新将 IP 包封装成帧转发给这台 RS;
3)在 hashtable 中记录连接信息。
vs/dr 做的事情很少,也很简单,所以它的效率很高,不比硬件负载均衡设备差多少。
数据包、数据帧的大致流向是这样的:client --> VS --> RS --> client
1.2 前面已作了回答,vs/dr 不会修改 IP 包的内容.
2. RealServer 为什么要在 lo 接口上配置 VIP,在出口网卡上配置 VIP 可以吗?
2.1 既然要让 RS 能够处理目标地址为 vip 的 IP 包,首先必须要让 RS 能接收到这个包。
在 lo 上配置 vip 能够完成接收包并将结果返回 client。
2.2 答案是不可以将 VIP 设置在出口网卡上,否则会响应客户端的 arp request,造成 client/gateway
arp table 紊乱,以至于整个 loadbalance 都不能正常工作。
3. RealServer 为什么要抑制 arp 帧?这个问题在上一问题中已经作了说明,这里结合实施命令进一步阐述。我们在具体实施部署的时候都会
作如下调整:
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1">/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/all/arp_announce
我相信很多人都不会弄懂它们的作用是什么,只知道一定得有。我这里也不打算拿出来详细讨论,只是
作几点说明,就当是补充吧。
3.1
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
这两条是可以不用的,因为 arp 对逻辑接口没有意义。
3.2 如果你的 RS 的外部网络接口是 eth0,那么
echo "1">/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/all/arp_announce
其实真正要执行的是:
echo "1">/proc/sys/net/ipv4/conf/eth0/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/eth0/arp_announce
所以我个人建议把上面两条也加到你的脚本里去,因为万一系统里上面两条默认的值不是 0,那有可能
是会出问题滴。
4. LVS/DR loadbalancer(director)与 RS 为什么要在同一网段中?
从第一个问题中大家应该明白 vs/dr 是如何将请求转发给 RS 的了吧?它是在数据链路层来实现的,所
以 director 必须和 RS 在同一网段里面。
5. 为什么 director 上 eth0 接口除了 VIP 另外还要配一个 ip(即 DIP)?
5.1 如果是用了 keepalived 等工具做 HA 或者 LoadBalance,则在健康检查时需要用到 DIP
5.2 没有健康检查机制的 HA 或者 Load Balance 则没有存在的实际意义.
6. LVS/DRip_forward 需要开启吗?
不需要。因为 director 跟 realserver 是同一个网段,无需开启转发。
7. lvs/dr 里,director 的 vip 的 netmask 没必要设置为 255.255.255.255,也不需要再去
route add -host $VIP dev eth0:0
director 的 vip 本来就是要像正常的 ip 地址一样对外通告的,不要搞得这么特殊.
扫一扫
483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
