深入浅出 LVS 负载均衡（四）实操 DR 模型、Keepalived DR 模型的高可用

关注

发布于: 2 小时前

之前介绍了 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 安装 pvsadm、keepalived，并启动 ipvsadm、keepalived

实验机器展示

DR 模式实操

回顾一下 DR 模式的特点

实操开始，前置准备工作和上篇实操中的 NAT 模式的一样，这里就不赘述了。

开始配置 DR 模式：

RS01、RS02

LB01

配置完成，现在我们来验证下 DR 模式下的负载均衡。

发现直接在本地请求 LB01 的外网 IP 地址时，一直处于等待状态，最终报错：Operation timed out。

我们先来看下 LB01 有没有正确的收到连接请求

可以看到 LB01 正确的收到了连接请求，并且转发给了 RS02。接下来我们登陆到 RS02 上，检查 RS02 是否接收到了数据包。

RS02 收到了数据包，并且也发出了返回的数据包，返回数据包的 IP 地址和端口号也和发出的一致。所以可以合理地猜测，问题出在由 RS02 直接返回数据包给客户端的过程中。那么只有两种情况，RS02 无法连接到客户端或者客户端拒绝接收这个数据包。

检查 RS02 是否能正常连接到客户端

RS02 和客户端可以正常请求访问。那么应该是客户端拒绝接收了这个数据包，抓包来看下，客户端是否有收到这个数据包。

再次请求 LB01，并查看客户端和 LB01 交互的数据包

发现只有发出的数据包，而没有收到的数据包。现在情况是：RS02 发出了数据包，但是客户端却没收到。那只有一种可能，就是云主机的 EIP 转发数据包的时候，由于某种条件限制，扔掉了这个数据包。如果是这样的话，在内网环境中应该是可以正常访问的。我们再申请一台在相同网段的云主机，验证一下。

果然是可以正常访问的，后来和官方交流之后也证实了这一点。（我猜测应该是出于对安全的考虑，所有进出的数据包，IP 地址和 MAC 地址必须和本机一致，否则数据包会被丢弃。）

到此实验配置完成，验证也随之完成～

Keepalived 实现 DR 模型的高可用性实操

在成功搭建 DR 模型之后，不由得思考这么一个问题，如果负载均衡服务器宕机了怎么办？负载均衡服务器承载着客户端对服务端的所有请求路由，如果一旦宕机，影响的是整个系统不可用。所以需要一些措施来保证负载均衡的高可用性。

最简单的办法就是将单点部署的负载均衡服务器变成多点部署。如果当前使用的节点出现问题，迅速地切换到另一个节点上，这样就可以保证系统的整个可用性。那么，现在负载均衡服务器单点故障的问题就转换成多点部署的切换问题。

先来看看解决多点部署的切换问题，需要什么条件？首先需要发现问题，即需要不断地检查当前节点是否正常，如果当前节点不正常的话，需要快速地切换到其他的节点上。keepalived 就是这样工作的。

实际操作开始～

ifconfig lo:0 10.23.88.247 netmask 255.255.255.255 broadcast 10.23.88.247 up
LB01、LB02 安装 ipvsadm、keepalivedyum install ipvsadm keepalived -y 修改 keepalived 配置文件 cp keepalived.conf keepalived.conf.bak