负载均衡分类:
硬件负载均衡:F5 BIG-IP 不适用于小企业,使用不多
软件负载均衡:lvs 、haproxy 、 nigix 、 httpd 、 varnish
基于应用层划分:
4层-传输层,我们使用lvs、haproxy(tcp) 只针对于ip地质
7层-应用层:haproxy nginx 针对与应用
lvs概述
LVS(Linux Virtual Server)即Linux虚拟服务器,是由章文嵩博士主导的开源负载均衡项目,目前LVS已经被集成到Linux内核模块中。该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案,其体系结构如图1所示,终端互联网用户从外部访问公司的外部负载均衡服务器,终端用户的Web请求会发送给LVS调度器,调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器,比如,轮询算法可以将外部的请求平均分发给后端的所有服务器,终端用户访问LVS调度器虽然会被转发到后端真实的服务器,但如果真实服务器连接的是相同的存储,提供的服务也是相同的服务,最终用户不管是访问哪台真实服务器,得到的服务内容都是一样的,整个集群对用户而言都是透明的。最后根据LVS工作模式的不同,真实服务器会选择不同的方式将用户需要的数据发送到终端用户,LVS工作模式分为NAT模式、TUN模式、以及DR模式。
原文链接:https://blog.csdn.net/weixin_40470303/article/details/80541639
它附着在防火墙input琏上,有自己的函数。
安装lvs
安装lvs策略编写工具:
yum install -y ipvsadm.x86_64^C
ipvsadm -l #列出当前存在的策略
lsmod: 查看当前内核支持的模块:
有ip_vs 。
查看它的配置文件:
开启save_on_restart,重启时保存策略
新建策略文件:
touch /etc/sysconfig/ipcaadm #不建立会报错
重启ipvsadm服务。
添加策略
ipvsadm -h 获取帮助
ipvsadm -A -t 172.25.254.100:80 -s rr
指定虚拟ip是让其他非内部人员访问的一个接口,-s 制定调度器 rr是轮询。
ipvsadm -ln 查看:
再添加两个真实服务:
ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.3:80 -g
ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.4:80 -g
-g 代表使用DR (直接路由模式模式),最常用,其它的还有NAT,TUN(隧道)模式
列出:
重启ipvsadm。
策略已经保存到了刚建立的文件中。
我们还需要,添加100这个ip地址作为接口
ip addr add 172.25.254.100/24 dev ens3
ip a
并且可以ping通。这时我们如果访问100,就会由lvs把请求轮询调度到策略上的两台主机上
可以看出一次增加的连接次数。访问没有问题,但是我们看不到返回的结果,因为:
我们的访问流程是:
client --> virtserver --> realserver --> client
也就是说从真实的主机返回给客户端,他在返回数据包时发现要返回的ip并不是100,客户端就无法接收数据包。所以就卡住了,我们就要给两台realserver 设置100的ip地址,用来给客户返回数据。
再次访问:
调度成功。但这样还存在一些问题:
这样访问的地址是lvs上的mac地址,如果我们访问到的是254.3或者254.4的主机,还会接收到数据嘛?
我们删除l172.25.254.100的缓存地址:
arp -d 172.25.254.100
这次我们就直接绑定的是server4上的mac地址了,没有经过lvs的调度,这在企业和宗是不被允许的,那我们就得强制从调度器获取。我们可以通过配置内核参数的方式解决。(arptables)
在两台rs主机上安装arptables
配置规则:让用户在访问100的ip时,这两台真实服务器不去响应。
arptables -A INPUT -d 172.25.254.100 -j DROP #在输入时拒绝以172.25.254.100接收
arptables -A OUTPUT -s 172.25.254.100 -j mangle --mangle-ip-s 172.25.254.4
# 在输出时以172.25.254.100的身份输出,并且真实ip时172.25.254.4
arptables-save > /etc/sysconfig/arptables #保存策略
就返回正常了。
DR模式工作原理
这就是DR模式的一整个历程,lvs时工作在input链上实现调度,当用户向负载均衡器(ds),发送请求时,调度器先把请求发往内核空间,然后prerouting(路由前) 链会接收到请求,判断访问的ip是不是本机,确认是本机就把请求发到input链上,ipvs就是工作在input链上的,(lvs分为两个组件,一个ipvs,一个ipvsadm,ipvs是真正在lvs生效的东西,它是内核的一段代码,ipvsadm只是一个调度策略的编写工具.)这是,ipvs就会把用户的请求和已经定义好的服务集群进行比对,如果请求就是服务集群,ipvs就会去强行修改请求的目的端口,并更新数据包,发往postrouting 链,在发往 rs 后端。
DR 模式数据流向:
clients --> DS(调度器) --> kernel space --> PRERPUTIING --> CIP(源IP):VIP(目的IP) --> INPUT --> ipvs --> DMAC:RMAC --> POSTROUTING --> DS RS --> 2层传输(数据链路层) --> rs --> lo --> ens3网卡(VIP源ip:CIP目的ip) --> clients
cip :客户端ip
DS:调度器 和RS 在统一网络中,通过2层传输
RS:真实服务器
TUN隧道模式
ipvsadm -C #先清除原先配置的规则
modprobe ipip #添加隧道模式所需要的模块
完成后我们发现执行ip a后:
多了这个东西,当前状态为down。
添加一个 vip和两个rip:
ipvsadm -A -t 172.25.254.100:80 -s rr
ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.3:80 -i
ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.4:80 -i
重启服务。
在server3和server4上也都添加ipip模块。并把他们和lvs主机的100ip挪到刚才出现的哪一块网卡上:
modprobe ipip
ip addr del 172.25.254.100/24 dev ens3
ip addr add 172.25.254.100/24 dev tunl0
ip link set up tunl0 激活网卡
状态不再是DOWN。
激活后我们去关闭 rs 的反向过滤规则
rp_filter 就是反向过滤规则,如果开启的花,就会对流入的数据包进行反向的路径校验,如果不符合规则就会丢弃。
关闭它,把所有为1的都改为0:
sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.default.rp_filter=0
sysctl -w net.ipv4.conf.ens3.rp_filter=0
sysctl -w net.ipv4.conf.tunl0.rp_filter=0
sysctl -p 让其生效
测试:
调度成功。这就是隧道模式的使用
使用原理:
隧道模式就是在原有的报文上多封装一层ip守护,内部的ip守护是 CIP:VIP,在它外面加了一层DIP:RIP。
数据流向:
clients --> DS --> CIP:VIP --> INPUT链 --> 【DIP:RIP】CIP:VIP(封装) --> POSTROUTING链 --> rs -->
DIP:RIP --> rs拆解DIP:RIP发现还有一层报文CIP:VIP 对应tunl0上接口的IP --> 处理请求 --> lo --> ens3 --> VIP:CIP --> client
HA
一,ldirectord :后端功能出现问题
现在我们访问100这个VIP是成功的,如果有一个后端挂了(httpd 服务关闭了)
就好比拨打10086,有的接线员能访问,有的访问不到,就会造成连接到好的接线员是成功,连接到坏的接线员就连接失败了。
[root@server4 ~]# systemctl stop httpd
这样时好时坏会造成很大的困扰,所以我们应该在有后端出问题的时候把他从组里面踢出去,好了在加进来,这样用户是无感知的符合企业环境。
我们使用DR模式
ipvsadm -C 清除策略文件
modprobe -r ipip 删除ipip模块
配置规则:
ipvsadm -A -t 172.25.254.100:80 -s rr
ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.3:80 -g
ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.4:80 -g
systemctl restart ipvsadm.service
ip addr add 172.25.254.100/24 dev ens3 #在三台服务器上都加
访问成功:
如果出现后端挂掉,我们可以用后端的健康检查来解决:
- 第三方插件
先配置yum源,否则会报错缺少依赖性
安装ldirectord
查看配置文件;
配置文件的内容是:
把他复制到配置文件的目录下去
cp /usr/share/doc/ldirectord-3.9.5/ldirectord.cf /etc/ha.d/
我们开始修改配置文件,只需要定义虚拟服务:
systemctl start ldirectord.service 启动服务
测试:
后端服务器正常;
挂掉其中一台:
[root@server4 ~]# systemctl stop httpd
在尝试:
用户访问就不会产生影响了,出了问题后这台服务器就会被踢出集群,恢复后又加进来:
systemctl start httpd
二,keepalived : 调度器出现问题
如果我们的调度器挂掉了游会怎样,就好比10086直接打不通了
新开启一台虚拟机server5,作为server2(调度器)的后备,来实现高可用
- keepalived
keepalived是集群中保证高可用的软件,防止单点故障,在个别节点宕机时保证整个网络不间断的运行,同时duilvs下面的节点有健康检查功能,有了它,就可以不用上面的 ldirectory 了
在官网进行下载:keepalived.org
进行源码编译:
./configure --help 获取帮助
./configure --prefix=/usr/local/keepalived --with-init=systemd 进行编译
yum install -y openssl-devel 安装依赖性
出现这些yes就可以了
make && make install
目标目录已经出现,编译完成。
再删除100的VIP,因为keepalive会自动添加VIP
ip addr del 172.25.254.100/24 dev ens3
配置:
ln -s /usr/local/keepalived/etc/keepalived /etc/ 连接配置文件到/etc/下
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 ens3 虚拟ip网卡
virtual_router_id 51
priority 100 优先级
advert_int 1
authentication { 认证秘密
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.25.254.100 #VIP
}
}
virtual_server 172.25.254.100 80 {
delay_loop 3
lb_algo rr
lb_kind DR
#persistence_timeout 50
protocol TCP
real_server 172.25.254.3 80 { 真实服务器1
TCP_CHECK {
weight 1
connect_timeout 3
retry 3
delay_before_retry 3
}
}
real_server 172.25.254.4 80 { 真实服务器2
TCP_CHECK {
weight 1
在server5上也进行编译和响应配置
vrrp_instance VI_1 {
state BACKUP BACKUP为备份结点
interface ens3
virtual_router_id 51
priority 50 降低优先级
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
启动服务:
可见VIP已经自动加上,而备份状态的服务器没有:
挂掉一个后端,我们查看日至会有相关的健康检查和移出集群的信息,再开启服务也会有相应的add日志。
我们尝试挂掉调度器的keepalived服务,并对备用服务器进行监控日至:
tail -f /var/log/messages
看出进入了主节点,并设置了VIP,此时server2上的VIP已经被移除。
这时我们的用户访问正常:
我们在重新启动keepalived ,此时server又回到主节点,上面的VIP又被设置:
server5又回到备用状态,上的VIP又被移除:
VRRP:虚拟路由冗余协议
实现路由器高可用的协议,把n太相同功能的路由器组成一个路由器组,由一个MASTER 和多个BACKUP组成。当VIP在MASTER时,默认使用MASTER的VIP,当收不到MASTER的报文时,会根据优先级选举一个BACKUP成为MASTER。主节点会不停的向从结点发送心跳检测,告诉从结点它还很健康,当主节点故障时,备结点就收不到报文,就会接管主节点的资源和服务,当主节点恢复正常时,又释放资源,返还给主节点。