IPVS(LVS)负载均衡简介及实验测试
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了IPVS(LVS)负载均衡简介及实验测试相关的知识,希望对你有一定的参考价值。
参考技术A LVS是Linux Virtual Server的简称,也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目,现在已经是 Linux标准内核的一部分。LVS是一种叫基于TCP/IP的负载均衡技术,转发效率极高,具有处理百万计并发连接请求的能力。LVS的IP负载均衡技术是通过IPVS模块实现的。IPVS模块是LVS集群的核心软件模块,它安装在LVS集群作为负载均衡的主节点上,虚拟出一个IP地址和端口对外提供服务。用户通过访问这个虚拟服务(VS),然后访问请求由负载均衡器(LB)调度到后端真实服务器(RS)中,由RS实际处理用户的请求给返回响应。
根据负载均衡器转发客户端请求以及RS返回响应机制的不同,将IPVS的转发模式分为三种:VS/NAT,VS/DR,VS/TUN
DR模式下,客户端的请求包到达负载均衡器的虚拟服务IP端口后,负载均衡器不会改写请求包的IP和端口,但是会改写请求包的MAC地址为后端RS的MAC地址,然后将数据包转发;真实服务器处理请求后,响应包直接回给客户端,不再经过负载均衡器。所以DR模式的转发效率是最高的,特别适合下行流量较大的业务场景,比如请求视频等大文件。
DR模式的特点:
LB只是将数据包的MAC地址改写为RS的MAC地址,然后转发给相应的RS。
因为LB转发时并不会改写数据包的目的IP,所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包,而不是丢弃,必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP,自己是能够处理这个数据包的。否则RS会直接丢弃该数据包!
因为LB不会改写数据包的目的端口,所以RS服务的监听端口必须和虚拟服务端口一致,否则RS会直接拒绝该数据包。
因为RS收到的请求数据包的源IP是客户端的IP,所以理所当然RS的响应会直接回给客户端,而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。
因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址,所以要能够查询到RS的MAC。而要获取到RS的MAC,则需要保证二者位于一个子网,否则LB只能获取到RS网关的MAC地址。
NAT模式下,请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后,LB会对请求包做目的地址转换(DNAT),将请求包的目的IP改写为RS的IP。当收到RS的响应后,LB会对响应包做源地址转换(SNAT),将响应包的源IP改写为LB的IP。
NAT模式的特点:
对于请求包,会进行DNAT;对于响应包,会进行SNAT。
虽然LB在转发过程中做了NAT转换,但是因为只是做了部分地址转发,所以RS收到的请求包里是能看到客户端IP的。
因为RS收到的请求包源IP是客户端的IP,为了保证响应包在返回时能走到LB上面,所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然,如果客户端的IP是固定的,也可以在RS上添加明细路由指向LB的虚拟服务IP,不用改默认网关。
因为需要将RS的默认网关配置为LB的虚拟服务IP地址,所以需要保证LB和RS位于同一子网。
又因为需要保证RS的响应包能走回到LB上,则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC,响应包就直接回给客户端了,不会走网关,也就走不到LB上面了。这时候由于没有LB做SNAT,客户端收到的响应包源IP是RS的IP,而客户端的请求包目的IP是LB的虚拟服务IP,这时候客户端无法识别响应包,会直接丢弃。
IP隧道(IP tunneling)是将一个IP报文封装在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技 术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个IP地址,另一端也有唯一的IP地址。
利用IP隧道技术将请求报文封装转发给后端服务器,响应报文能从后端服务器直接返回给客户。但在这里,后端服务器有一组而非一个,所以我们不可 能静态地建立一一对应的隧道,而是动态地选择一台服务器,将请求报文封装和转发给选出的服务器。这样,可以利用IP隧道的原理将一组服务器上的网络服 务组成在一个IP地址上的虚拟网络服务。各个服务器将VIP地址配置在自己的IP隧道设备上。
它的连接调度和管理与VS/NAT中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况, 动态地选择一台服务器,将请求报文封装在另一个IP报文中,再将封装后的IP报文转发给选出的服务器;服务器收到报文后,先将报文解封获得原来目标地址为 VIP的报文,服务器发现VIP地址被配置在本地的IP隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。
轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n,并选出第i台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。
LB会根据RS上配置的权重,将消息按权重比分发到不同的RS上。可以给性能更好的RS节点配置更高的权重,提升集群整体的性能。
最小连接调度(Least-Connection Scheduling)算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务 器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1;当连接中止或超时,其连接数减一。
加权最小连接调度(Weighted Least-Connection Scheduling)算法是最小连接调度的超集,各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1,系统管理员可以动态地设置服务器的权 值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。
基于局部性的最少链接调度(Locality-Based Least Connections Scheduling,以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群中 客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的 请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率,从而整个集群系统的处理能力。
带复制的基于局部性最少链接调度(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集群系统的使用效率。
目标地址散列调度(Destination Hashing Scheduling)算法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。
目标地址散列调度算法先根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求的目标IP地址换成请求的源IP地址。
客户端发送对VIP的请求,lvs负载到后端某一台server,后端server处理后,直接封包回送客户端,源IP地址一定是lvs上面配的那个公网服务地址,也就后端server要配置这个ip,后端server收到的数据包是lvs没有变动过的(IP:vip),多个server,接入互联网的server持有相同的IP,是不允许的,因此,必须将后端server中的vip隐藏起来(对外隐藏,对自己可见)
VIP: 虚拟服务器地址
DIP: 转发的网络地址
1,和RIP通信:ARP协议,获取Real Server的RIP:MAC地址;
2,转发Client的数据包到RIP上,RIP上要求有VIP(对外隐藏VIP);
RIP: 后端真实主机(后端服务器)
CIP: 客户端IP地址
对外隐藏,对内可见
kernel parameter:
目标mac地址为全F,交换机触发广播
arp_ignore: 定义接收到ARP请求时的响应级别;
0:只要本地配置的有相应地址,就给予响应;
1:仅在请求的目标(MAC)地址配置请求
到达的接口上的时候,才给予响应;
arp_announce:定义将自己地址向外通告时的通告级别;
0:将本地任何接口上的任何地址向外通告;
1:试图仅向目标网络通告与其网络匹配的地址;
2:仅向与本地接口上地址匹配的网络进行通告;
lvs 主机:192.168.56.118
RIP主机:也就是需要负载的服务器,192.168.56.101-103
LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统,后来将lvs嵌入到linux内核,叫做ipvs
ipvs参数
保存规则
-S
载入此前的规则:
-R
配置lvs的VIP
确保/proc/sys/net/ipv4/ip_forward 内容是1
调整RS的响应。通告级别(每一台RS都配):
配置RS的VIP(每一台RS都配)
启动RS上的httpd
编写测试文件
启动httpd
客户端验证:
RIP:80 能显示
VIP:80不能显示
负载服务器安装LVS管理工具—ipvsadm
浏览器刷新: 访问vip:80
在DR模式中是所有服务机共享一个VIP,但是在IP隧道模式中,就相当于主代理机将包经过自己打包之后,将IP转化成公网可传递的IP,并将消息经过自己又一次的打包,发送给真实服务器,真实服务器对这个请求作出响应,这样就达到一个可以跨地区的传输。并且也避免了DR模式中代理机与真实服务机必须在同一局域网的不便。
说明:
1、当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP,目标IP为VIP 。
2、PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
3、IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。此时源IP为DIP,目标IP为RIP
4、POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。此时源IP为DIP,目标IP为RIP
5、RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。此时的源IP地址为VIP,目标IP为CIP
RIP、VIP、DIP全是公网地址
RS的网关不会也不可能指向DIP
所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
不支持端口映射
RS的系统必须支持隧道
LVS服务器:192.168.56.100
RS服务器:192.168.56.101,192.168.56.102,192.168.56.103
4.4.5 ### 系统配置 vim /etc/sysctl.conf
4.5.5 ### 系统配置 vim /etc/sysctl.conf
Linux集群之高可用负载均衡lvs+keepalived
LVS简介
LVS介绍
LVS是Linux Virtual Server的缩写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统,属于4层负载均衡
ipvs和ipvsadm的关系
我们使用配置LVS的时候,不能直接配置内核中的ipvs,需要使用ipvs的管理工具ipvsadm进行管理
LVS术语
LVS转发原理
LVS负载均衡器接受所有入站请求,并根据调度算法决定哪个realserver处理该请求
LVS调度算法
- 轮询(rr):按照请求顺序轮流分发到后端RS
- 加权轮询(wrr):权值高的获得的任务更多
- 最小连接数(lc):动态的将请求建立到连接数较少的RS上
- 加权最小连接数(wlc):调度器自动询问RS的真实负载情况,并动态的调整权
LVS调度算法生产环境选型
一般的网络服务,如:http、mail、MySQL等,常用的调度算法为:
- 基本轮询调度rr算法
- 加权轮询调度wrr算法
- 加权最小连接调度wlc算法
LVS转发模式
- NAT(Network Address Translation)
- DR(Direct Routing)
- TUN
LVS-DR模式
转发流程
将所有入站请求转发给后端realserver,后端realserver处理完直接将结果发给客户端
原理
当用户请求到达Direct Server,此时报文的源IP为CIP、MAC为CIP-MAC,目标IP为VIP、MAC为VIP-MAC
Direct Server根据调度算法确定一台处理请求的realserver,将请求转发给对应的realserver,此时源IP和目标IP均未改变,仅修改了源MAC为DIP-MAC,目标MAC为RIP-MAC
对应的realserver处理完请求,直接将结果发给客户端,此时源IP为VIP、MAC为VIP-MAC,目标IP为CIP、MAC为CIP-MAC
特性
- 通过在调度器上修改数据包的目的MAC地址实现转发
- Real-Server和Direct-Server必须在同一网段
- Real-Server的lo接口必须绑定VIP
为什么要抑制ARP请求
- 由于后端Real-Server要将VIP绑定到lo网卡上,这就出现了一个问题,客户端请求到达LVS前端路由器的时候,前端路由器会发送一个{*目标地址为VIP*}的请求报文,所以需要抑制Real-Server的ARP,保证让Direct-Server收到这个报文,而不是realserver收到这个报文
- /proc/sys/net/ipv4/conf/all/arp_ignore 的值为1,/proc/sys/net/ipv4/conf/lo/arp_ignore 的值为1
- /proc/sys/net/ipv4/conf/all/arp_announce的值为2,/proc/sys/net/ipv4/conf/lo/arp_announce的值为2
- 一句话说明抑制Real-Server原因:保证前端路由将目标地址为VIP的报文发给Direct-Server,而不是Real-Server
优势
只有请求报文经过调度器,而Real-Server响应处理后无需经过调度器,因此并发量大的时候效率很高
LVS-NAT模式
转发流程
将所有入站请求转发给后端Real-Server,后端Real-Server处理完再发给Direct-Server,Direct-Server再发给客户端
特性
- 既有RIP也有VIP
- Real-Server必须得跟Direct-Server在同一网段
- Real-Server必须将网关指向Direct-Server
优势
只需要一个公网IP给Direct-Server,Direct-Server始终跟外接打交道
劣势
需要依赖Direct-Server把请求转发给Real-Server,Real-Server处理完把结果发给Direct-Server,Direct-Server再把结果转发出去,并发高的时候会成为瓶颈
LVS三种模式对比
ipvsadm介绍
ipvsadm参数
添加虚拟服务器
语法:ipvsadm -A [-t|u|f] [vip_addr:port] [-s:指定算法]
-A:添加
-t:TCP协议
-u:UDP协议
-f:防火墙标记
-D:删除虚拟服务器记录
-E:修改虚拟服务器记录
-C:清空所有记录
-L:查看
添加后端RealServer
语法:ipvsadm -a [-t|u|f] [vip_addr:port] [-r ip_addr] [-g|i|m] [-w 指定权重]
-a:添加
-t:TCP协议
-u:UDP协议
-f:防火墙标记
-r:指定后端realserver的IP
-g:DR模式
-i:TUN模式
-m:NAT模式
-w:指定权重
-d:删除realserver记录
-e:修改realserver记录
-l:查看
通用:
ipvsadm -ln:查看规则
service ipvsadm save:保存规则
ipvsadm配置LVS负载均衡
需求
用LVS实现后端两台httpd的负载均衡
环境说明
lb01 | 192.168.0.91 | lvs |
realserver-1 | 192.168.0.92 | httpd |
realserver-2 | 192.168.0.93 | httpd |
test | 192.168.0.94 | 用来测试负载均衡 |
负载均衡器端
安装LVS
yum -y install ipvsadm
ipvsadm
添加绑定VIP
ip addr add 192.168.0.89/24 dev eth0 label eth0:1
配置LVS-DR模式
ipvsadm -A -t 192.168.0.89:80 -s rr
ipvsadm -a -t 192.168.0.89:80 -r 192.168.0.93 -g
ipvsadm -a -t 192.168.0.89:80 -r 192.168.0.94 -g
Real-Server端
配置httpd省略 curl 192.168.0.93 #测试realserver-1网站是否正常 192.168.0.93 curl 192.168.0.94 #测试realserver-2网站是否正常 192.168.0.94 绑定VIP到lo网卡 ip addr add 192.168.0.89/32 dev lo label lo:1 #由于DR模式需要realserver也有VIP 抑制ARP echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore
客户端测试
[root@test ~]#curl 192.168.0.89
192.168.0.93
[root@test ~]#curl 192.168.0.89
192.168.0.94
配置LVS+keepalived
需求
- LVS给两台httpd做负载均衡
- keepalived做lvs高可用,同时做Real-Server健康检查,如果发现Real-Server80端口没开,就认为故障,从集群中剔除
- 在keepalived配置文件内就能配置LVS
环境说明
lb01 | 192.168.0.91 | lvs keepalived-master |
lb02 |
192.168.0.92 | lvs keepalived-backup |
realserver-1 | 192.168.0.93 | httpd |
realserver-2 | 192.168.0.94 | httpd |
在负载均衡器端配置lvs+keepalived
lb01节点
vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
##################全局配置##########################
global_defs {
#如有故障,发邮件地址
notification_email {
9618154@qq.com #收件人
}
notification_email_from Alexandre.Cassen@firewall.loc #keepalived报警邮件,发件人
smtp_server 192.168.200.1 #邮件服务器地址
smtp_connect_timeout 30 #邮件服务器超时时间
router_id LVS_01 #类似于MySQL的server-id,每个keepalived节点不能相同
}
#################keepalived配置#####################
vrrp_instance VI_1 {
state MASTER #keepalived角色,MASTER和BACKUP
interface eth0 #通信接口,下面的virtual_ipaddress(VIP)绑定到这个网卡
virtual_router_id 51 #vrrp_instance的唯一标识
priority 150 #keepalived权重,数值越大权重越大,MASTER应大于BACKUP
advert_int 1 #发送心跳间隔,如果backup1秒收不到心跳就接管,单位是秒
authentication { #每个keepalived节点通过这里设置的验证通信,必须得设置成一样
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.89/24 #VIP
}
}
##################LVS配置##############
#添加虚拟服务器
#相当于 ipvsadm -A -t 192.168.0.89:80 -s wrr
virtual_server 192.168.0.89 80 {
delay_loop 6 #服务健康检查周期,单位是秒
lb_algo wrr #调度算法
lb_kind DR #模式
nat_mask 255.255.255.0
persistence_timeout 50 #回话保持时间,单位是秒
protocol TCP #TCP协议转发
#添加后端realserver
#相当于 ipvsadm -a -t 192.168.0.89:80 -r 192.168.0.93:80 -w 1
real_server 192.168.0.93 80 { #realserver的真实IP
weight 1 #权重
#健康检查
TCP_CHECK {
connect_timeout 8 #超时时间
nb_get_retry 3 #重试次数
delay_before_retry 3 #重试间隔
connect_port 80 #检查realserver的80端口,如果80端口没监听,就会从集群中剔除
}
}
real_server 192.168.0.94 80 {
weight 1
TCP_CHECK {
connect_timeout 8
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
lb02节点
vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
################全局配置###########################
global_defs {
notification_email {
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id LVS_02
}
################keepalived配置#####################
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.89/24
}
}
################lvs配置##########################
virtual_server 192.168.0.89 80 {
delay_loop 6
lb_algo wrr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.0.93 80 {
weight 1
TCP_CHECK {
connect_timeout 8
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.0.94 80 {
weight 1
TCP_CHECK {
connect_timeout 8
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
配置后端Real-Server
确保网站服务是正常的
curl 192.168.0.93
192.168.0.93
curl 192.168.0.94
192.168.0.94
绑定VIP到lo网卡
ip addr add 192.168.0.89/32 dev lo label lo:0
抑制ARP
[root@realserver-1 ~]#echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
[root@realserver-1 ~]#echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
[root@realserver-1 ~]#echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
[root@realserver-1 ~]#echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore
客户端测试
- 负载均衡是否正常
- 后端Real-Server出问题是否自动剔除
- lvs高可用是否正常,提供服务的LVS宕机,vip漂移到另一台LVS继续提供服务
温馨提示:
如果在是实际环境中使用Keepalived做高可用集群解决方案时,为了解决脑裂的问题,我们需要把MASTER与BACKUP服务器的Keepalived的主配置文件(keepalived.conf)中的 "state" 状态都改为 "BACKUP" 优先级 "priority" 选项的值不要设置为相同,可以设置一个数值大另一个数值小;如优先级分别为:priority 100 priority 90
以上是关于IPVS(LVS)负载均衡简介及实验测试的主要内容,如果未能解决你的问题,请参考以下文章