视频链接：4-6 搭建LVS-DR模式- 为两台RS配置虚拟IP_哔哩哔哩_bilibili

视频笔记链接：笔记

---

一、服务器与Ip约定

LVS

• DIP: 192.168.1.151

• VIP: 192.168.1.150

Nginx1

• RIP: 192.168.1.171

• VIP: 192.168.1.150

Nginx2

• RIP: 192.168.1.172

• VIP: 192.168.1.150

二、CentOS配置——配置网络

1 关闭 NetworkManager

注意：三台机器都需要配置

systemctl stop NetworkManager
systemctl disable NetworkManager

三、配置LVS

1 配置LVS网络

cd /etc/sysconfig/network-scripts/
cp ifcfg-ens33 ifcfg-ens33:1
vim ifcfg-ens33:1

新cp出来的网络配置文件 ifcfg-ens33:1 内容：

2 重启网络 并 查看

重启才生效

service network restart（或者 systemctl restart network ）

查看，发现eth33 网卡中有两个ip

ip addr（或 ip address）

3 安装LVS——集群管理工具ipvsadm

yum install -y ipvsadm

4 查看 ipvs 信息

ipvsadm -Ln

四、配置RS

1 配置两台RS的虚拟IP——两台Nginx

目的：配置后，服务器通过网络虚拟IP（vip）返回数据报文，而不会被用户看到真实服务器IP

构建 网络配置文件 ifcfg-lo 的子接口：

cp ifcfg-lo ifcfg-lo:1

ifcfg-lo:1文件内容：

重启刷新一下网络：

service network restart

查看，发现lo 网卡中有两个ip

ip addr（或 ip address）

另一台RS同理，略。

以上为Nginx的虚拟ip的配置。

2 配置两台RS的网卡行为——禁止arp通信——arp-ignore 和 arp-announce

本小节额外参考博客：ARP在LVS中的应用 | Linbo的博客 （备用：ARP 在 LVS 中的应用 - 开发者头条，已摘录到我的博客：ARP在LVS中的应用_HD243608836的博客-CSDN博客）

--问题：

DR模式下，由于三台机器（LVS+两台RS）都绑定的VIP，当client发过来一个请求（vip : port）时，就不一定发给谁了。

解释：
在同一局域网内，当 Client 与 Server 通信，如果 Client 不知道 Server 的 MAC 地址，Client 就会发送 ARP 广播请求，Server 响应 ARP 广播请求，发送自己的 MAC 地址给 Client。
通过网关先arp广播，看谁arp返回的响应包快，也就缓存对应的IP-MAC关系，10分钟生命周期内也就固定发送给谁了。

所以要想办法禁止 RS 的 VIP 直接去接收 Client 的请求，而只允许LVS的VIP去接收。

--采取办法：

禁用两台RS的网卡的arp功能，即达到了针对该VIP 的 ARP 广播请求就不会响应。这样，”VIP“与“RS的MAC“地址也就不会绑定了。完美~ （如果arp_ignore/arp_announce没有配置，就可能出现请求直接到达 RS 上）

所以需要对两台RS（两个Nginx）都做如下参数配置：

① vim /etc/sysctl.conf
② 复制以上图片内容，粘贴进去
③ sysctl -p #刷新到内存，立即生效
④ 在另一台Nginx上重复以上内容

解释一下：(假如默认网卡是eth0)

• arp-ignore: ARP 响应级别（处理请求）

  

  • 0 —— 响应任意网卡上接收到的对本机IP地址的arp请求（包括环回网卡lo上的地址），而不管该目的IP是否在接收网卡上（eth0）。 表示目标 IP 是本机的，则响应 ARP 请求。（不管是不是lo上配置的虚拟IP，只要网卡配置文件中有配置对应的IP就响应）

  对于默认值0，当192.168.2.101的 eth0 收到 192.168.2.200的 ARP 请求，发现192.168.2.200在本机上，所以回应了这个 ARP 请求。

  • 1 —— "只"响应目的IP地址为接收网卡(eth0)上的本地地址的arp请求。 如果接收 ARP 请求的网卡 IP（一般是eth0） 和目标 IP（VIP） 相同，则响应 ARP 请求。

  对于默认值1，当192.168.2.101的 eth0 收到 192.168.2.200的 ARP 请求，发现这个 IP 虽然是本机的，但不是 eth0 的IP地址（eth0 是接收这个 ARP 请求的网卡）， 所以不会响应这个 ARP 请求

• arp-announce: ARP通告行为（返回响应）

  

  • 0——允许使用任意网卡上的IP地址作为arp请求的源IP，通常就是使用数据包a的源IP。

  • 1——尽量避免使用不属于该发送网卡子网的本地地址作为发送arp请求的源IP地址。

  • 2——忽略IP数据包的源IP地址，选择该发送网卡上最合适的本地地址作为arp请求的源IP地址。 sysctl.conf中包含all和eth/lo（具体网卡）的arp_ignore参数，取其中较大的值生效。

更具体的图文解说参看——（强烈建议参看一下）
链接：https://www.cnblogs.com/lipengxiang2009/p/7451050.html
（备用链接：https://blog.csdn.net/HD243608836/article/details/128619166）

3 配置两台RS的网卡行为——配置静态路由Router——隐藏RS真实IP

1. 命令：

route add -host 192.168.1.150 dev lo:1

由于到达RS的Request是LVS（vip为150）发过来的，所以响应的“目的网段/IP”一定是150（可以指定“目标网段”也可以指定“目标IP”）。 在RS服务器中，执行上述命令配置“静态路由”后，即“目的IP为150”的Response都必须通过lo:1虚拟网卡发送，而lo:1配置的IP（即VIP）也为150，这样就成功的把数据包的“源IP地址”置为150了，而不是RS的“真实IP”，达到了隐藏RS真实IP的目的。

解释：
ip route add [目的网段] via [网关] dev [接口] [table <table_number>]

# e.g. 目标网段为 10.15.150.0/24 的数据包通过接口 enp0s3 转发到网关 192.168.150.253。
# ip route add 10.15.150.0/24 via 192.168.150.253 dev enp0s3

1. 但是重启后失效，所以建议如下方式（开机自启动）：

vim /etc/rc.local

或

echo "route add -host 192.168.1.150 dev lo:1" >> /etc/rc.local

1. 还有一种方式

   在/etc/sysconfig/network里添加到末尾

查看路由表：

route -n

另一台同理，略。

五、配置LVS集群

1 配置LVS集群

查看帮助文档：

ipvsadm -h

配置集群：

ipvsadm -A -t 192.168.150:80 -s rr

解释：

-A：创建一个虚拟服务集群(add virtual service with options)

-t：即tcp-service，后面接service-address，如host[:port] ,（-u：udp）

-s：scheduler, 负载均衡规则设置，rr表示轮询

查看集群配置：

ipvsadm -Ln

添加真实服务器节点：

ipvsadm -a -t 192.168.150:80 -r 192.168.171:80 -g

ipvsadm -a -t 192.168.150:80 -r 192.168.172:80 -g

解释：

-a：添加一台真实服务器RS到集群中

-g：即使用DR模式，gatwaying（direct routing）

-r：真实服务器地址 real server

查看集群配置：

ipvsadm -Ln

2 验证DR模式

ipvsadm -Ln --stats

其中outBytes为零，则表示数据没有经过171和172两台RS机器对应的eth33出去（因为数据是经过两台RS各自的lo网卡出去），这样也就验证了DR模式生效了。

LVS持久化设置

进一步验证rr是否生效，参看视频，略

六、Keepalived + LVS + Nginx 高可用

1 keepalived+LVS整体架构

LVS分为master、backup两台机器

• master宕机后，slaver会顶上，master恢复恢复后，backup会让出，把vip“权力”还给原master。

• 可以对所有的RS真实服务器进行健康检查，宕机则自动踢出集群，恢复则自动加入回集群。

keepalived原生就是为LVS设计的。

2 安装keepalived

1. 上传keepalived

2. ./configure

3. make

4. make install（安装好后，核心配置文件位于 /etc/keepalived）

5. 把keepalived注册到系统服务（具体步骤参看视频，略）

3 配置keepalived核心配置文件keepalived.conf

LVS集群“MASTER”配置（建议先备份原配置文件bak）

全局的配置（注意：master的router_id为LVS_151, backup的router_id为LVS_152）：

继续（注意：①master的state为MASTER, backup的state为BACKUP。②master与backup的virtual_router_id保持相同。③backup的priority轮询权重改为50（因为是备份，所以低一些，官方建议相差50））：

继续：

接上图，配置需要健康监测的两台RS（171、172）：

注意，配置每行的结尾没有分号“ ; ”。

4 使 keepalived.conf 配置生效

"清除"所有LVS规则：

ipvsadm -C

查看ipvsadm -Ln，会发现规则全部没有了：

"重启"，使刚才配置的keepalived配置文件生效：

systemctl restart keepalived

注意，其中persistent（持久化）为5秒，即5秒内不会rr切换（参看“验证DR模式”部分的视频，有相关讲解）。

刷新浏览器网页后，立即通过命令ipvsadm -Lnc查看：（可以看到expire还剩几秒）

七、验证 Keepalived + LVS + Nginx 高可用与健康检查

1 验证Keepalived高可用

1. 在master中执行systemctl stop keepalived， 再在master中执行ip addr查看VIP，会发现，vip已经不存在于当前网卡eth33中了：

1. 来到backup中查看，会发现vip绑定在这里了：

1. 恢复master的keepalived，执行systemctl stop keepalived。 发现VIP 150又重新绑定到151机器上了（backup把VIP还回给原master了）

1. 查看backup机器，发现刚才的vip已经不存在了（只剩152了）：

   

2 验证keepalived对RS服务器的健康检查（自动剔除与自动恢复）

1. 在一台RS（nginx 171）上执行nginx -s stop，然后去LVS-Master中查看ipvsadm -Ln，发现171被LVS集群自动剔除了：

1. 浏览器刷新，发现网页显示的服务器ip始终为172

   

2. 启动刚才的RS（nginx171）服务，执行./nginx，然后再次去LVS-Master中查看ipvsadm -Ln，发现171自动加入到LVS集群中，回来了：