深入浅出 LVS 负载均衡系列概览(已完结)
📌 本系列按照负载均衡器对数据包的处理方式分类,从计算机间通信的角度出发,浅谈 NAT、FULLNAT、DR、TUN 模型的实现原理。
LVS(Linux Virtual Server) 是一个虚拟服务器集群系统。工作在 OSI 模型的传输层,即四层负载均衡。LVS 本身实现了 NAT、DR、TUN 模型,这些模型仅做数据包的转发,而不会与客户端建立连接,成本低效率高。FULLNAT 基于 NAT 实现,LVS 本身不支持,需要额外对内核打补丁后才能使用。
之前介绍了 LVS 负载均衡 NAT、FULLNAT、DR、TUN 模型的实现原理。现在来继续动手实践一下~
实验环境
LVS 目前已经是 Linux 内核中的一部分,在内核中的模块叫做 ipvs,支持 NAT、DR、TUNNEL 模型。用户不能直接操作 ipvs 模块,需要安装交互软件 ipvsadm,使用 ipvsadm 和 ipvs 进行交互。
我使用 4 台 UCloud 云主机来搭建实验环境,创建云主机的时候选择分时购买,更划算一点。
-
实验机器及环境
- 4 台 UCloud 云主机,CentOS 7.9 64 位,1 核 1 G,需要注意一下防火墙规则,我选择的是【Web 服务器推荐】,开放 22、3389、80、443 的端口号,这个可以自行配置
- 两台 Real Server:RS01、RS02,一台负载均衡服务器:LB01
- RS01:10.23.190.76、RS02:10.23.122.152、LB01:10.23.21.184、LB02:10.23.115.100
- VIP:10.23.88.247
- RS01、RS02 安装 httpd,快速启动 http 服务器,且配置不同的请求响应
- LB01、LB02 安装 ipvsadm、keepalived,并启动 ipvsadm、keepalived
- 4 台 UCloud 云主机,CentOS 7.9 64 位,1 核 1 G,需要注意一下防火墙规则,我选择的是【Web 服务器推荐】,开放 22、3389、80、443 的端口号,这个可以自行配置
-
实验机器展示
DR 模式实操
回顾一下 DR 模式的特点:
- DR 模式仅修改数据包的「目标 MAC 地址」,只有请求数据包需要经过负载均衡器,所以 DR 模式不支持对端口的转换
- 真实服务器和负载均衡器必须在同一个网段,且真实服务器的默认网关不能是负载均衡器
- 真实服务器的 lo 接口上需要配置 VIP 的 IP 地址,且真实服务器需要更改 ARP 协议,“隐藏” lo 接口上的 VIP
前置准备工作和 NAT 模式的一样,这里就不赘述了。直接开始配置 DR 模式。
-
RS01、RS02
- 修改 ARP 协议
- echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
- echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
- echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
- echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
- 在 lo 接口上配置 VIP
-
ifconfig lo:0 10.23.21.184 netmask 255.255.255.255
-
验证配置
ifconfig
-
LB01
- 配置路由入口规则
ipvsadm -A -t 10.23.21.184:80 -s rr
- 配置路由出口规则
ipvsadm -a -t 10.23.21.184:80 -r 10.23.190.76 -g -w 1
ipvsadm -a -t 10.23.21.184:80 -r 10.23.122.152 -g -w 1
- 如果 VIP 和本机地址不一致,要配置 VIP(我这里就不用了)
- 配置 VIP
ifconfig eth0:0 VIP/24
- 配置 VIP
- 验证配置
-
ipvsadm -ln
-
ifconfig
-
- 配置路由入口规则
-
验证配置
配置完成,现在我们来验证下 DR 模式下的负载均衡。
发现直接在本地请求 LB01 的外网 IP 地址时,一直处于等待状态,最终报错:Operation timed out。
-
我们先来看下 LB01 有没有正确的收到连接请求:
-
查看 LB01 记录的连接信息:ipvsadm -Lnc
可以看到 LB01 正确的收到了连接请求,并且转发给了 RS02。接下来我们登陆到 RS02 上,检查 RS02 是否接收到了数据包。 -
查看 RS02 上的 TCP 连接信息:netstat -natp | grep 10.23.21.184
RS02 收到了数据包,并且也发出了返回的数据包,返回数据包的 IP 地址和端口号也和发出的一致。所以可以合理地猜测,问题出在由 RS02 直接返回数据包给客户端的过程中。那么只有两种情况,RS02 无法连接到客户端或者客户端拒绝接收这个数据包。
-
检查 RS02 是否能正常连接到客户端
-
ping 106.75.220.2
RS02 和客户端可以正常请求访问。那么应该是客户端拒绝接收了这个数据包,抓包来看下,客户端是否有收到这个数据包。
再次请求 LB01,并查看客户端和 LB01 交互的数据包
-
tcpdump host 106.75.253.112 -nne
发现只有发出的数据包,而没有收到的数据包。现在情况是:RS02 发出了数据包,但是客户端却没收到。那只有一种可能,就是云主机的 EIP 转发数据包的时候,由于某种条件限制,扔掉了这个数据包。如果是这样的话,在内网环境中应该是可以正常访问的。我们再申请一台在相同网段的云主机,验证一下。果然是可以正常访问的,后来和官方交流之后也证实了这一点。(我猜测应该是出于对安全的考虑,所有进出的数据包,IP 地址 和 MAC 地址必须和本机一致,否则数据包会被丢弃。)
到此实验配置完成,验证也完成~
Keepalived 实现 DR 模型的高可用性实操
在成功搭建 DR 模型之后,不由得思考这么一个问题,如果负载均衡服务器宕机了怎么办?负载均衡服务器承载着客户端对服务端的所有请求路由,如果一旦宕机,影响的是整个系统不可用。所以我们需要一些措施来保证负载均衡的高可用性。
最简单的办法就是将单点部署的负载均衡服务器变成多点部署。如果当前使用的节点出现问题,迅速地切换到另一个节点上,这样就可以保证系统的整个可用性。那么,现在负载均衡服务器单点故障的问题就转换成多点部署的切换问题。
我们先来看看解决多点部署的切换问题,需要什么条件?首先我们需要发现问题,即需要不断地检查当前节点是否正常,如果当前节点不正常的话,需要快速地切换到其他的节点上。keepalived 就是这样工作的。我们来实际操作一下~
配置步骤:
-
RS01、RS02 和 DR 模型实操类似,只不过我们要重新申请一个 VIP:10.23.88.247,绑定在 RS01、RS02 的 lo:0 上
ifconfig lo:0 10.23.88.247 netmask 255.255.255.255 broadcast 10.23.88.247 up
-
LB01、LB02
-
安装 ipvsadm、keepalived
yum install ipvsadm keepalived -y
-
修改 keepalived 配置文件
cp keepalived.conf keepalived.conf.bak
! Configuration File for keepalived vrrp_instance VI_1 { state MASTER // 备节点:BACKUP interface eth0 virtual_router_id 51 priority 100 // 备节点:50 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.23.88.247 dev eth0 } } virtual_server 10.23.88.247 80 { delay_loop 6 lb_algo rr lb_kind DR nat_mask 255.255.0.0 persistence_timeout 0 protocol TCP real_server 10.23.190.76 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 10.23.122.152 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }
-
重新启动 keepalived
systemctl restart keepalived
-
验证部署:
验证 keepalived DR 模型
可以正常访问到两台服务器,接下来把 LB01 的 keepalived 停掉,继续访问 VIP。
还是可以正常访问,VIP 漂到了 LB02 上。使用 ipvsadm -lnc
查看具体连接信息。
实验完成,差不多断断续续的用了 4.5 小时,包括一些额外的排查时间,共计花费不到 5 ¥~
原创不易,期待点赞收藏,任何建议欢迎评论区交流~
more about me