当前位置： 首页 > news >正文

集群与集群概念

news 2025/8/26 12:35:16

集群与集群的概念

集群是什么

集群（cluster）是由一组独立的计算机系统构成的一个松耦合的多处理器系统，作为一个整体向用户提供一组网络资源，这些单个的计算机系统就是集群的节点（node）。它们之间通过网络实现进程间的通信。

通俗一点来说，就是让若干台计算机联合起来工作(服务)，可以是并行的，也可以是做备份。

集群类型

Load Balance cluster(负载均衡集群)

即把负载压力根据某种算法合理分配到集群中的每一台计算机上，以减轻主服务器的压力，降低对主服务器的硬件和软件要求。

例如：四兄弟开裁缝铺，生意特别多，一个人做不下来，老是延误工期，于是四个兄弟商量：老大接订单, 三个兄弟来干活。客户多起来之后，老大根据一定的原则(policy) 根据三兄弟手上的工作量来分派新任务。

High Availability cluster(高可用集群)

利用集群管理软件，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。

例如：两兄弟开早餐铺，生意不大，但是每天早上7点到9点之间客户很多并且不能中断。为了保证2个小时内这个早餐铺能够保证持续提供服务，两兄弟商量几个方法:

方法一：平时老大做生意，老二这个时间段在家等候，一旦老大无法做生意了，老二就出来顶上，这个叫做 Active/Standby(双机冷备)

方法二：平时老大做生意，老二这个时候就在旁边帮工，一旦老大无法做生意，老二就马上顶上，这个叫做Active/Passive(双机热备)

方法三：平时老大卖包子，老二也在旁边卖豆浆，老大有问题，老二就又卖包子，又卖豆浆，老二不行了，老大就又卖包子，又卖豆浆。这个叫做Active/Active (dual Active)(双机互备)。

High Performance Computing clustering(高性能计算集群)

即充分利用集群中的每一台计算机的资源，实现复杂运算的并行处理，通常用于科学计算领域，比如基因分析、化学分析等。

例如：10个兄弟一起做手工家具生意，一个客户来找他们的老爹要求做一套非常复杂的仿古家具，一个人做也可以做，不过要做很久很久，为了1个星期就交出这一套家具，10个兄弟决定一起做。老爹把这套家具的不同部分分开交给儿子们作，然后每个儿子都在做木制家具的加工，最后拼在一起。老爹是scheduler任务调度器，儿子们是compute node. 他们做的工作叫做作业

负载均衡集群

LB集群的主要功能就是解决如何在Real Servers前添加一台主机作为调度器，从而将客户端请求按照某种算法调度给后端主机。

实现方式

按照调度器通过硬件实现还是软件实现，可以分为：

硬件实现调度器：

  • F5 Big-IP
  • Citrix NetScaler
  • A10
  • Radware
  • Array

软件实现调度器：

  • Nginx
  • LVS
  • HAProxy

按照调度器工作在OSI协议的哪一层，可以分为：

传输层（内核空间，四层调度）

  • LVS
  • HAProxy（mode tcp）

应用层（用户空间，七层调度）

  • HAProxy（mode http）
  • Nginx

HAProxy

HAProxy 是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，支持虚拟主机。它是免费、快速并且可靠的一种解决方案。 lb 特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。lb 运行在时下的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上

实践

通过lb实现4层和7层负载均衡。

主机名IP地址服务器角色
client2.yy.cloud10.1.1.21客户端
client1.yy.cloud10.1.8.21客户端
router.yy.cloud10.1.1.20, 10.1.8.20路由器
lb.yy.cloud10.1.1.10, 10.1.8.10代理服务器
web1.yy.cloud10.1.8.11Web 和 SSH 服务器
web2.yy.cloud10.1.8.12Web 和 SSH 服务器
web3.yy.cloud10.1.8.13Web 和 SSH 服务器

网络说明：

  1. 所有主机：第一块网卡名为 ens33，第二块网卡名为 ens192
  2. 默认第一块网卡模式为nat，第二块网卡模式为hostonly
  3. 网关设置：10.1.1.0/24 网段网关为10.1.1.20，10.1.8.0/24 网段网关为10.1.8.20
基础配置

  • 主机名

  • IP 地址

  • 网关

# 网关配置命令参考# 10.1.1.0/24 网段网关为10.1.1.20
nmcli connection modify ens33 ipv4.gateway 10.1.8.20
nmcli connection up ens33# 10.1.8.0/24 网段网关为10.1.8.20
nmcli connection modify ens33 ipv4.gateway 10.1.1.20
nmcli connection up ens33
配置 router
# 开启路由
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p
安装 haproxy
[root@lb ~]# yum install -y lb
http 模式
配置 web
[root@web1-3 ~]## 部署 web
yum install -y nginx
echo Welcome to $(hostname) > /usr/share/nginx/html/index.html 
systemctl enable nginx.service --now# 访问后端 nginx
[root@client1 ~]# curl 10.1.8.11
Welcome to web1.yy.cloud
[root@client1 ~]# curl 10.1.8.12
Welcome to web2.yy.cloud
[root@client1 ~]# curl 10.1.8.13
Welcome to web3.yy.cloud# 准备虚拟主机
[root@web1-3 ~]# cat > /etc/nginx/conf.d/vhost-test.conf <<'EOF'
server {listen       81;root         /test;
}
EOF
[root@web1-3 ~]# systemctl restart nginx# 准备测试文件
[root@web1-3 ~]# mkdir /test
[root@web1-3 ~]# echo hello txt from $(hostname -s) > /test/index.txt
[root@web1-3 ~]# echo hello html from $(hostname -s) > /test/index.html# 测试
[root@client1 ~]# curl http://web1:81/
hello html from web1
[root@client1 ~]# curl http://web2:81/
hello html from web2
[root@client1 ~]# curl http://web3:81/
hello html from web3
配置 haproxy
# 备份  haproxy配置文件
cp /etc/lb/lb.cfg{,.ori}# 修改 配置文件，最后添加以下内容
echo '
########### web 代理 ###########
frontend front_webbind *:80default_backend  back_webacl test url_reg -i \.txt$use_backend test if testbackend back_webbalance     roundrobinserver web1 10.1.8.11:80 checkserver web2 10.1.8.12:80 checkserver web3 10.1.8.13:80 checkbackend testbalance    roundrobinserver test1 10.1.8.11:81 checkserver test2 10.1.8.12:81 checkserver test3 10.1.8.13:81 check
' >> /etc/lb/lb.cfg# 启用并启动服务
systemctl enable lb.service --now
测试
[root@client1 ~]# for n in {1..90}; do curl http://10.1.8.10 -s; done | sort |uniq -c30 Welcome to web1.yy.cloud30 Welcome to web2.yy.cloud30 Welcome to web3.yy.cloud[root@client2 ~]# for n in {1..90}; do curl http://10.1.1.10 -s; done | sort |uniq -c30 Welcome to web1.yy.cloud30 Welcome to web2.yy.cloud30 Welcome to web3.yy.cloud

这段操作的核心目的，是搭建一套 “能按请求类型智能分流、同时实现负载均衡的 Web 服务架构”，本质是解决 “不同需求的请求如何高效分配到对应后端” 以及 “多节点服务如何分摊压力、保障稳定” 这两个关键问题，具体可拆解为 3 个核心目标：

1. 实现 “请求类型分流”：让不同需求的请求走不同通道

通过 HAProxy 的 ACL 规则和 Nginx 多端口配置，把两种不同类型的请求精准分发到对应后端：

  • 普通 Web 请求（如访问首页、.html 文件）：
    当用户访问 http://lb地址/（无特殊后缀）或 http://lb地址/xxx.html 时，HAProxy 会将请求转发到 back_web 后端，对应 Nginx 的 80 端口（默认 Web 服务），返回 Welcome to webx.yy.cloud 或 hello html from webx 这类内容。
  • .txt 文件请求：
    当用户访问 http://lb地址/index.txt（URL 以 .txt 结尾）时，HAProxy 会触发 test 规则，将请求转发到 test 后端，对应 Nginx 的 81 端口（虚拟主机专属端口），返回 hello txt from webx 这类特定内容。

简单说：让 “看网页” 和 “读文本文件” 的请求分开处理，避免不同类型的业务逻辑互相干扰。

2. 实现 “负载均衡”：多节点分摊压力，避免单点故障

无论是普通 Web 请求（80 端口）还是 .txt 请求（81 端口），HAProxy 都配置了 roundrobin（轮询） 负载均衡算法：

  • 当多个用户同时访问时，请求会依次分发到 web1、web2、web3 三个节点（比如第一个请求到 web1，第二个到 web2，第三个到 web3，第四个再回到 web1）。
  • 每个后端节点都加了 check 关键字，HAProxy 会自动检测节点是否存活：如果某节点（如 web2）故障，会自动跳过它，只把请求发给正常节点，避免用户访问到 “死服务”。

比如：100 个用户访问首页，会分到 3 个节点各处理约 33 个请求，既避免单个节点因压力过大崩溃，也保障了服务的 “高可用性”。

3. 搭建 “可扩展的服务架构”：为后续业务升级留空间

这套配置不是 “一次性操作”，而是为后续业务扩展打基础：

  • 若后续需要新增 “处理图片的请求”，只需再给 Nginx 加一个监听端口（如 82 端口）、创建对应目录和测试文件，然后在 HAProxy 里加一条 “匹配 .jpg/.png 后缀” 的 ACL 规则，就能快速实现新请求的分流。
  • 若某类请求（如 .txt）访问量激增，只需新增更多 “配置了 81 端口的 Nginx 节点”，再把新节点加入 HAProxy 的 test 后端，就能轻松扩容，无需改动整体架构。
总结：最终要解决的实际问题

本质是为了应对 “多业务、高访问量的 Web 服务场景”：
比如一个网站既需要提供 “用户浏览的网页”（80 端口），又需要提供 “供下载的文本文件”（81 端口），同时每天有上万用户访问 —— 通过这套架构，既能让两种业务分开处理（避免混乱），又能让多节点分摊压力（避免崩溃），还能方便后续加功能、加节点（方便扩展），最终实现 “稳定、高效、易维护” 的 Web 服务。

nginx

介绍

反向代理服务可以缓存资源以改善网站性能。在部署位置上，反向代理服务器处于Web服务器前面，缓存Web响应，加速访问。这个位置也正好是负载均衡服务器的位置，所以大多数反向代理服务器同时提供负载均衡的功能，管理一组Web服务器，将请求根据负载均衡算法转发到不同的Web服务器上。

Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。由于web服务器不直接对外提供访问，因此Web服务器不需要使用外部ip地址，而反向代理服务器则需要配置双网卡和内部外部两套IP地址。

实践

主机名IP地址服务器角色
client2.yy.cloud10.1.1.21客户端
client1.yy.cloud10.1.8.21客户端
router.yy.cloud10.1.1.20, 10.1.8.20路由器
lb.yy.cloud10.1.1.10, 10.1.8.10代理服务器
web1.yy.cloud10.1.8.11Web 服务器
web2.yy.cloud10.1.8.12Web 服务器
web3.yy.cloud10.1.8.13Web 服务器

网络说明：

  1. 所有主机：第一块网卡名为 ens33，第二块网卡名为 ens192
  2. 默认第一块网卡模式为nat，第二块网卡模式为hostonly
  3. 网关设置：10.1.1.0/24 网段网关为10.1.1.20，10.1.8.0/24 网段网关为10.1.8.20
基础配置

  • 主机名

  • IP 地址

  • 网关

    # 网关配置命令参考# 10.1.1.0/24 网段网关为10.1.1.20
nmcli connection modify ens33 ipv4.gateway 10.1.8.20
nmcli connection up ens33# 10.1.8.0/24 网段网关为10.1.8.20
nmcli connection modify ens33 ipv4.gateway 10.1.1.20
nmcli connection up ens33
配置 router
# 开启路由
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# 或者
# sed -i "s/ip_forward=0/ip_forward=1/g" /etc/sysctl.conf
sysctl -p# 设置防火墙
systemctl enable firewalld.service --now
firewall-cmd --set-default-zone=trusted
firewall-cmd --add-masquerade --permanent
配置 web
[root@web1-3 ~]## 部署 web
yum install -y lb
echo Welcome to $(hostname) > /usr/share/lb/html/index.html 
systemctl enable lb.service --now# 访问后端 nginx
[root@client1 ~]# curl 10.1.8.11
Welcome to web1.yy.cloud
[root@client1 ~]# curl 10.1.8.12
Welcome to web2.yy.cloud
[root@client1 ~]# curl 10.1.8.13
Welcome to web3.yy.cloud
配置 nginx代理
# 配置代理
[root@lb ~]# yum install -y lb# 配置nginx
[root@lb ~]# vim /etc/lb/lb.conf
......
http {# http 块中增加upstreamupstream web {server 10.1.8.11:80;server 10.1.8.12:80;server 10.1.8.13:80;}server {.......# 增加 location / 记录，后端指向web，上一步配置的upstreamlocation / {# 添加如下语句proxy_pass http://web;}}
}# 启动服务
[root@lb ~]# systemctl start lb.service
访问验证
[root@client1 ~]# for i in {1..90};do curl -s 10.1.8.10 ;done|sort|uniq -c30 Welcome to web1.yy.cloud30 Welcome to web2.yy.cloud30 Welcome to web3.yy.cloud[root@client2 ~]# for i in {1..90};do curl -s 10.1.1.10 ;done|sort|uniq -c30 Welcome to web1.yy.cloud30 Welcome to web2.yy.cloud30 Welcome to web3.yy.cloud

结论：后端服务器轮询处理客户端请求。

LVS

LVS 介绍

Linux 虚拟服务器(LVS，Linux Virtual Servers) ，使用负载均衡技术将多台服务器组成一个虚拟服务器。它为适应快速增长的网络访问需求提供了一个负载能力易于扩展，而价格低廉的解决方案。

LVS是 章文嵩博士 于1998年创建的一款开源负载均衡软件。LVS工作在内核空间中，能够根据请求报文的目标IP和目标 PORT 将请求调度转发至后端服务器集群中的某节点。

LVS 术语

  • 调度器，负载均衡器，Director，Virtual Server（VS）

  • 后端服务器，真实服务器，Real Server（RS），Backend Server

  • 调度器一般配两个IP地址：VIP，向外提供服务的IP地址；DIP，与后端RS通信的IP地址。

  • RIP：RS 的 IP，CIP：客户端的IP。

LVS由 ipvsadm 和 ipvs 组成：

  • ipvsadm：用户空间命令行工具，用于在Director上定义集群服务和添加集群上的 Real Servers。
  • ipvs：工作于内核上 netfilter 中 INPUT 钩子上的程序代码。

NAT 模式

主机名IP地址服务器角色
client2.yy.cloud10.1.1.21客户端
client1.yy.cloud10.1.8.21客户端
router.yy.cloud10.1.1.20, 10.1.8.20路由器
lvs.yy.cloud10.1.1.10, 10.1.8.10LVS 服务器
web1.yy.cloud10.1.8.11Web 服务器
web2.yy.cloud10.1.8.12Web 服务器
web3.yy.cloud10.1.8.13Web 服务器

网络说明：

  1. 所有主机：第一块网卡名为 ens33，第二块网卡名为 ens192
  2. 默认第一块网卡模式为nat，第二块网卡模式为hostonly
  3. 网关设置：10.1.1.0/24 网段网关为10.1.1.10，10.1.8.0/24 网段网关为10.1.8.10
基础配置

  • 主机名

  • IP 地址

  • 网关

    # 网关配置命令参考# 10.1.8.0/24 网段网关为10.1.8.10
nmcli connection modify ens33 ipv4.gateway 10.1.8.10
nmcli connection up ens33# 10.1.1.0/24 网段网关为10.1.1.10
nmcli connection modify ens33 ipv4.gateway 10.1.1.10
nmcli connection up ens33
配置 web

注意：所有web都要执行以下命令。

[root@web1-3 ~]## 部署 web
yum install -y nginx
echo Welcome to $(hostname) > /usr/share/nginx/html/index.html 
systemctl enable nginx.service --now# 访问后端 nginx
[root@client1 ~]# curl 10.1.8.11
Welcome to web1.yy.cloud
[root@client1 ~]# curl 10.1.8.12
Welcome to web2.yy.cloud
[root@client1 ~]# curl 10.1.8.13
Welcome to web3.yy.cloud
配置 LVS
[root@lb ~]# # 开启路由
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# 或者
# sed -i "s/ip_forward=0/ip_forward=1/g" /etc/sysctl.conf
sysctl -p# 安装 ipvsadm
yum install -y ipvsadm
touch /etc/sysconfig/ipvsadm
systemctl enable ipvsadm --now# 创建轮询负载
ipvsadm -A -t 10.1.1.10:80 -s rr
ipvsadm -a -t 10.1.1.10:80 -r 10.1.8.11 -m
ipvsadm -a -t 10.1.1.10:80 -r 10.1.8.12 -m
ipvsadm -a -t 10.1.1.10:80 -r 10.1.8.13 -m
ipvsadm-save -n > /etc/sysconfig/ipvsadm# 核实配置是否生效
[root@lb ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.1.1.10:80 rr-> 10.1.8.11:80                  Masq    1      0          0         -> 10.1.8.12:80                  Masq    1      0          0-> 10.1.8.13:80                  Masq    1      0          0# 多次访问验证  
[root@client2 ~]# for i in {1..90};do curl -s 10.1.1.10 ;done|sort|uniq -c30 Welcome to web1.yy.cloud30 Welcome to web2.yy.cloud30 Welcome to web3.yy.cloud

负载均衡模式更改为加权轮询。

[root@lb ~]# 
ipvsadm -E -t 10.1.1.10:80 -s wrr
ipvsadm -e -t 10.1.1.10:80 -r 10.1.8.12 -m -w 2
ipvsadm -e -t 10.1.1.10:80 -r 10.1.8.13 -m -w 3[root@lb ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.1.1.10:80 wrr-> 10.1.8.11:80                 Masq    1      0          30-> 10.1.8.12:80                 Masq    2      0          30-> 10.1.8.13:80                 Masq    3      0          30
访问验证
[root@client2 ~]# for i in {1..90};do curl -s 10.1.1.10 ;done|sort|uniq -c15 Welcome to web1.yy.cloud30 Welcome to web2.yy.cloud45 Welcome to web3.yy.cloud

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

这段操作的核心目的是搭建 LVS-NAT 模式的负载均衡架构，并通过 “加权轮询（WRR）” 算法实现 “按需分配请求”，解决 “不同性能的后端服务器如何合理分摊负载” 的问题，同时保障跨网段客户端的访问能力，具体拆解为 3 个核心目标：

1. 实现 LVS-NAT 模式负载均衡：跨网段请求转发 + 基础负载分摊

首先，这套配置的基础是 LVS-NAT 模式（通过 ipvsadm 配置中 Forward: Masq 标识，Masq = Masquerade，即地址伪装），核心目的是解决 “跨网段客户端访问后端服务” 和 “基础负载均衡”：

  • 跨网段请求转发：客户端（如 client2，10.1.1.21）访问 LVS 调度器（DS）的虚拟服务地址 10.1.1.10:80，LVS 会将请求转发到后端 Web 服务器（10.1.8.11/12/13，属于另一个网段），并通过 “地址伪装” 将后端服务器的响应数据包源 IP 改为 LVS 的 10.1.1.10，再返回给客户端 —— 解决了不同网段（10.1.1.0/24 和 10.1.8.0/24）之间的通信问题。
  • 基础轮询负载：初始配置用 ipvsadm -A -t 10.1.1.10:80 -s rr 启用 “轮询（RR）” 算法，将 90 次请求均匀分给 3 台 Web 服务器（每台 30 次），避免单节点因高负载崩溃，保障服务稳定性。
2. 升级为加权轮询（WRR）：按服务器性能 “按需分配请求”

这是本次配置的核心优化点 —— 将负载均衡算法从 “轮询（RR）” 改为 “加权轮询（WRR）”，目的是让性能更强的服务器承担更多请求，提升整体资源利用率：

  • 为什么需要加权？
    实际场景中，后端 Web 服务器的性能可能不同（如 web3 配置了更强的 CPU / 内存，web1 性能较弱）。如果仍用 “轮询”，性能弱的服务器会和强服务器承担相同请求，可能导致弱服务器过载、强服务器资源闲置，整体架构效率低。

  • 加权配置的逻辑

    ：

    通过

    ipvsadm -e

    （编辑后端节点）给不同服务器设置权重（

    -w

    参数）：

    • web1（10.1.8.11）：权重 1（默认，未显式修改）
    • web2（10.1.8.12）：权重 2
    • web3（10.1.8.13）：权重 3
      权重比例为 1:2:3，意味着请求会按这个比例分配：90 次请求中，web1 处理 15 次（90×1/(1+2+3)）、web2 处理 30 次（90×2/6）、web3 处理 45 次（90×3/6）—— 和验证结果完全匹配，实现了 “性能越强，承担请求越多” 的按需分配。
3. 保障服务可用性与可维护性
  • 服务高可用基础：LVS 作为四层负载均衡器，转发效率高（仅处理 TCP/IP 协议层，不解析 HTTP 内容），能支撑较高并发；同时，后端多节点部署避免了 “单点故障”（若某台 Web 服务器故障，LVS 会自动停止向其转发请求，需配合健康检查配置）。
  • 配置持久化：通过 ipvsadm-save -n > /etc/sysconfig/ipvsadm 将 LVS 配置保存到文件，重启 ipvsadm 服务后配置不会丢失，减少运维成本；通过 ipvsadm -Ln 可直观验证配置是否生效，方便问题排查。
关键配置的 “目的” 补充（理解核心逻辑）
  1. 开启路由转发（net.ipv4.ip_forward=1）
    这是 LVS-NAT 模式的前提：LVS 作为调度器需要转发不同网段的数据包，必须开启内核的 IP 转发功能，否则无法将客户端请求转发到后端 Web 服务器。
  2. Forward: Masq（NAT 模式标识）
    区别于之前的 DR 模式（Forward: Route），NAT 模式下，所有请求和响应都必须经过 LVS 调度器（后端服务器的网关需指向 LVS），LVS 通过 “地址伪装” 完成跨网段通信 —— 虽然转发效率略低于 DR 模式，但配置更简单，无需在后端服务器配置虚拟网卡（dummy）和 ARP 参数，适合对配置复杂度敏感、并发量中等的场景。

总结：核心价值

这套配置的最终目的，是为 “后端服务器性能不均 + 跨网段访问” 的场景 提供优化的负载均衡方案：
既解决了不同网段客户端访问后端服务的通信问题，又通过 “加权轮询” 让资源分配更合理（性能强的服务器多干活），避免资源浪费或弱节点过载，同时依托 LVS 的四层转发能力保障服务的高并发支撑能力，是企业级负载均衡架构中 “兼顾易用性和资源利用率” 的常用方案。

DR 模式

主机名IP地址服务器角色
client2.yy.cloud10.1.1.21客户端
client1.yy.cloud10.1.8.21客户端
router.yy.cloud10.1.1.20, 10.1.8.20路由器
lvs.yy.cloud10.1.8.10LVS 服务器
web1.yy.cloud10.1.8.11Web 服务器
web2.yy.cloud10.1.8.12Web 服务器
web3.yy.cloud10.1.8.13Web 服务器

网络说明：

  1. 所有主机：第一块网卡名为 ens33，第二块网卡名为 ens192
  2. 默认第一块网卡模式为 nat，第二块网卡模式为 hostonly
  3. 网关设置：10.1.1.0/24 网段网关为10.1.1.20，10.1.8.0/24 网段网关为10.1.8.20
基础配置

  • 主机名

  • IP 地址

  • 网关

    # 网关配置命令参考# 10.1.8.0/24 网段网关为10.1.8.20
nmcli connection modify ens33 ipv4.gateway 10.1.8.20
nmcli connection up ens33# 10.1.1.0/24 网段网关为10.1.1.20
nmcli connection modify ens33 ipv4.gateway 10.1.1.20
nmcli connection up ens33
配置 router
# 开启路由
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# 或者
# sed -i "s/ip_forward=0/ip_forward=1/g" /etc/sysctl.conf
sysctl -p
配置 web

注意：所有web都要执行以下命令。

[root@web1-3 ~]## 部署 web
yum install -y nginx
echo Welcome to $(hostname) > /usr/share/nginx/html/index.html 
systemctl enable nginx.service --now# 访问后端 nginx
[root@client1 ~]# curl 10.1.8.11
Welcome to web1.yy.cloud
[root@client1 ~]# curl 10.1.8.12
Welcome to web2.yy.cloud
[root@client1 ~]# curl 10.1.8.13
Welcome to web3.yy.cloud
配置 LVS-RS

所有后端主机都要做相同配置。

[root@web1-3 ~]## 增加虚拟网卡
nmcli connection add type dummy ifname dummy con-name dummy ipv4.method manual ipv4.addresses 10.1.8.100/32
nmcli connection up dummy# 配置 arp 参数，关闭arp对dummy网卡的解析
cat >> /etc/sysctl.conf << EOF
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.dummy.arp_ignore = 1
net.ipv4.conf.dummy.arp_announce = 2
EOF
sysctl -p
配置 LVS-DS
[root@lb ~]# # 配置虚拟网卡
nmcli connection add type dummy ifname dummy con-name dummy ipv4.method manual ipv4.addresses 10.1.8.100/32
nmcli connection up dummy# 安装 ipvsadm
yum install -y ipvsadm
touch /etc/sysconfig/ipvsadm
systemctl enable ipvsadm --now# 创建轮询负载
ipvsadm -A -t 10.1.8.100:80 -s rr
ipvsadm -a -t 10.1.8.100:80 -r 10.1.8.11
ipvsadm -a -t 10.1.8.100:80 -r 10.1.8.12
ipvsadm -a -t 10.1.8.100:80 -r 10.1.8.13
ipvsadm-save -n > /etc/sysconfig/ipvsadm# 核实配置是否生效
[root@lb ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.1.8.100:80 rr-> 10.1.8.11:80                 Route   1      0          0-> 10.1.8.12:80                 Route   1      0          0-> 10.1.8.13:80                 Route   1      0          0
# Forward 值为 Route，代表当前模式为 DR
访问验证
[root@client1 ~]# for i in {1..90};do curl -s 10.1.8.100 ;done|sort|uniq -c30 Welcome to web1.yy.cloud30 Welcome to web2.yy.cloud30 Welcome to web3.yy.cloud[root@client2 ~]# for i in {1..90};do curl -s 10.1.8.100 ;done|sort|uniq -c30 Welcome to web1.yy.cloud30 Welcome to web2.yy.cloud30 Welcome to web3.yy.cloud

这段操作的核心目的是搭建一套基于 LVS（Linux Virtual Server）的 DR 模式（Direct Routing，直接路由）负载均衡架构，本质是解决 “高并发场景下 Web 服务的高性能、高可用请求分发” 问题，具体可拆解为 3 个核心目标：

1. 实现 “高性能负载均衡”：减少请求转发损耗，支撑高并发

LVS-DR 模式是四层（TCP/IP 协议层）负载均衡，相比 Nginx/HAProxy 的七层（HTTP 协议层）负载均衡，最大优势是转发效率极高，原因如下：

  • 请求路径短：客户端请求先到 LVS 调度器（DS，Director Server），但 LVS 仅做 “路由决策”（把请求转发给后端 Web 服务器），后端 Web 服务器（RS，Real Server）处理完请求后，会直接把响应返回给客户端，无需再经过 LVS 调度器（这是 DR 模式的核心 ——“直接路由”）。
    对比 Nginx 反向代理：所有请求 / 响应都要经过 Nginx 中转，高并发时 Nginx 容易成为瓶颈；而 DR 模式下 LVS 仅处理 “请求入站”，“响应出站” 直接走 Web 服务器，极大减少了 LVS 的压力，能支撑数万甚至数十万并发。
  • 四层转发轻量化：LVS 工作在 TCP/IP 协议栈的四层，仅处理 IP 和端口层面的转发，不解析 HTTP 协议（如 URL、Cookie 等），转发逻辑简单，资源消耗极低（CPU / 内存占用远低于 Nginx/HAProxy）。
2. 保障 “服务高可用”：多 Web 节点分摊压力，避免单点故障

和之前的 Nginx/HAProxy 架构类似，DR 模式的核心诉求之一是解决 “单 Web 服务器扛不住压力” 和 “单点故障” 问题：

  • 负载均衡分摊压力：通过 ipvsadm -A -t 10.1.8.100:80 -s rr 配置 “轮询（rr）” 算法，将客户端请求均匀分发到 web1/web2/web3 三个节点（从验证结果看，90 次请求每台处理 30 次，完美平分），避免单节点因高负载崩溃。
  • 隐藏后端节点，提升安全性：客户端仅能看到 LVS 对外提供的 “虚拟 IP（VIP，10.1.8.100）”，不知道真实 Web 服务器的 IP（10.1.8.11/12/13），减少了后端节点被直接攻击的风险。
  • 故障自动隔离（需配合健康检查）：虽然当前配置未显式加健康检查，但 LVS 可通过 ipvsadm 配置或第三方工具（如 keepalived）实现：若某 Web 节点（如 web2）故障，LVS 会自动停止向其转发请求，直到节点恢复，避免用户访问到 “死服务”。
3. 实现 “跨网段访问”：让不同网段客户端都能访问服务

架构中 router 节点（双 IP：10.1.1.20/10.1.8.20）的配置，解决了 “不同网段客户端访问” 的问题：

  • 通过 echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf 开启路由转发功能，让 10.1.1.0/24 网段的 client2（10.1.1.21）能通过 router 节点，访问到 10.1.8.0/24 网段的 LVS VIP（10.1.8.100），最终获取 Web 服务。
  • 验证结果中 client2 能正常访问 10.1.8.100，正是路由配置生效的体现，确保了服务对多网段客户端的可用性。
关键配置的 “目的” 补充（理解架构核心）

为了让 DR 模式正常工作，有两个关键配置需要特别说明其目的：

  1. 所有节点配置虚拟网卡 dummy 并绑定 VIP（10.1.8.100）
    • 原因：DR 模式下，Web 服务器需要直接向客户端返回响应，而响应的 “源 IP” 必须是客户端请求的 “目标 IP（VIP）”，否则客户端会因 “源 IP 不匹配” 拒绝接收响应。
    • 操作：通过 nmcli 创建 dummy 虚拟网卡并绑定 VIP，让 Web 服务器能以 VIP 为源 IP 发送响应，同时通过 arp_ignore=1/arp_announce=2 关闭 ARP 解析，避免网络中出现 VIP 地址冲突。
  2. LVS 配置 Forward: Route
    • 这是 DR 模式的标识：LVS 仅修改请求数据包的 “目标 MAC 地址”（转发给指定 Web 节点），不修改 IP 地址，确保 Web 节点能直接用 VIP 回包给客户端，实现 “直接路由” 的高性能特性。

总结：DR 模式架构的核心价值

这套架构的最终目的，是为 高并发 Web 服务场景（如电商促销、大型网站）提供解决方案：
相比 Nginx/HAProxy 的七层负载均衡，LVS-DR 模式的转发效率更高、能支撑更大并发；相比传统单节点 Web 服务，它通过负载均衡和路由转发，实现了 “高性能、高可用、跨网段访问” 的需求，是企业级高并发服务的常用架构之一。

高可用集群

脑裂

在 keepalived 高可用集群中，脑裂（Split-Brain） 是指主从节点（或双主节点）之间因通信中断，导致各自认为对方故障，从而同时争抢资源（如虚拟 IP），引发集群状态混乱的现象。

脑裂产生的原因

脑裂的核心是节点间心跳检测失败，但实际节点均正常运行，常见情况可能导致：

  1. 网络问题：主从节点间的心跳线路（如专用网线、交换机）故障、断网或延迟过高。
  2. 防火墙规则：节点间的 VRRP 协议端口（默认 112 端口，UDP 协议）被防火墙屏蔽。
  3. 资源耗尽：某节点因 CPU、内存耗尽或负载过高，无法响应心跳请求。
  4. 配置错误：keepalived 配置中 vrrp_instance 的 state、priority 或 authentication 等参数不一致，导致节点间无法正常协商。
脑裂的危害
  • 双节点同时持有虚拟 IP（VIP），导致客户端请求混乱（部分请求成功，部分失败）。
  • 若集群管理的是数据库、存储等资源，可能引发数据不一致（如双写冲突）。
  • 集群失去高可用意义，甚至因资源竞争导致服务崩溃。
如何避免脑裂？

通过 多重检测机制 和 资源隔离策略 预防脑裂，常用方案如下：

  1. 增加心跳检测线路
  • 除了主网络，添加备用通信线路（如独立网卡、交叉网线），避免单线路故障导致心跳中断。
  1. 启用 VRRP 认证
  • 配置节点间的认证机制，防止非法节点干扰集群，同时确保心跳信息的可靠性
  1. 配置防火墙规则

  • 允许节点间通过 VRRP协议通信（开放 UDP 112 端口）

    4.部署第三方检测工具

  • 使用 fence 机制（如 fence_virsh、fence_ipmilan）或脚本，当检测到脑裂时强制隔离异常节点。

  1. 降低脑裂影响范围
  • 结合业务层设计，如数据库使用主从复制 + 读写分离，避免双写冲突；存储使用分布式锁（如 Redis）控制资源独占。
  • 限制虚拟 IP 的使用场景，仅在确认集群状态正常时对外提供服务。
  1. 监控与告警
  • 通过 zabbix、prometheus 等工具监控 keepalived 状态（如 vrrp_script 检测），当发现双主节点同时存在时及时告警

Keepalvied 实践

主机名IP地址服务器角色
client2.yy.cloud10.1.1.21客户端
client1.yy.cloud10.1.8.21客户端
router.yy.cloud10.1.1.20, 10.1.8.20路由器
web1.yy.cloud10.1.8.11Web 服务器
web2.yy.cloud10.1.8.12Web 服务器

网络说明：

  1. 所有主机：第一块网卡名为 ens33，第二块网卡名为 ens192
  2. 默认第一块网卡模式为 nat，第二块网卡模式为 hostonly
  3. 网关设置：10.1.1.0/24 网段网关为10.1.1.20，10.1.8.0/24 网段网关为10.1.8.20
基础配置

  • 主机名

  • IP 地址

  • 网关

    # 网关配置命令参考# 10.1.1.0/24 网段网关为10.1.1.20
nmcli connection modify ens33 ipv4.gateway 10.1.8.20
nmcli connection up ens33# 10.1.8.0/24 网段网关为10.1.8.20
nmcli connection modify ens33 ipv4.gateway 10.1.1.20
nmcli connection up ens33
配置 router
# 开启路由
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# 或者
# sed -i "s/ip_forward=0/ip_forward=1/g" /etc/sysctl.conf
sysctl -p
配置 web
[root@web1-2 ~]## 部署 web
yum install -y nginx
echo Welcome to $(hostname) > /usr/share/nginx/html/index.html 
systemctl enable nginx.service --now# 访问后端 nginx
[root@client1 ~]# curl 10.1.8.11
Welcome to web1.yy.cloud
[root@client1 ~]# curl 10.1.8.12
Welcome to web2.yy.cloud
配置 keepalived
配置 web2

web2 作为备节点。

[root@web2 ~]# yum install -y keepalived
cp /etc/keepalived/keepalived.conf{,.ori}
vim /etc/keepalived/keepalived.conf

 ! Configuration File for keepalivedglobal_defs {router_id web2
}vrrp_instance nginx {state BACKUPinterface ens33virtual_router_id 51priority 100advert_int 1authentication {auth_type PASSauth_pass yy@123}virtual_ipaddress {10..8.100/24}
}
双节点

web1

! Configuration File for keepalivedglobal_defs {router_id web1
}vrrp_instance web1 {state MASTERinterface ens33virtual_router_id 51priority 200advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {10.1.8.100/24}
}vrrp_instance web2 {state BACKUPinterface ens33virtual_router_id 52priority 100advert_int 1authentication {auth_type PASSauth_pass 1111}

web2

vrrp_instance web1 {state BACKUPinterface ens33virtual_router_id 51priority 100advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {10.1.8.100/24}
}vrrp_instance web2 {state MASTERinterface ens33virtual_router_id 52priority 200advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {10.1.8.200/24}
}
interface ens33
virtual_router_id 51
priority 200
advert_int 1
authentication {auth_type PASSauth_pass 1111
}
virtual_ipaddress {10.1.8.100/24
}

}

vrrp_instance web2 {
state BACKUP
interface ens33
virtual_router_id 52
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}


web2```bash
vrrp_instance web1 {state BACKUPinterface ens33virtual_router_id 51priority 100advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {10.1.8.100/24}
}vrrp_instance web2 {state MASTERinterface ens33virtual_router_id 52priority 200advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {10.1.8.200/24}
}
http://www.xdnf.cn/news/1364707.html

相关文章：

  • 如何在 Jenkins 中安装 Master 和 Slave 节点以优化 CI/CD 流程
  • 【数据可视化-98】2025年上半年地方财政收入Top 20城市可视化分析：Python + Pyecharts打造炫酷暗黑主题大屏
  • 【数据可视化-100】使用 Pyecharts 绘制人口迁徙图：步骤与数据组织形式
  • Linux下的软件编程——网络编程（http）
  • 基于git的场景解决
  • DeepSeek 14B模型本地部署与预训练实现方案
  • 从零开始学习单片机15
  • MySQL常见报错分析及解决方案总结(1)---Can‘t connect to MySQL server on ‘localhost‘(10061)
  • 什么是事件循环（Event Loop）？浏览器和 Node.js 中的事件循环有什么区别？
  • 维度建模 —— 雪花模型 和 星型模型的优缺点
  • 冯·诺依曼架构：现代计算机的基石与瓶颈
  • Linux驱动开发笔记（七）——并发与竞争（下）——自旋锁信号量互斥体
  • k8s笔记03-常用操作命令
  • vite 项目创建、插件配置
  • JBL音响代理——河北正娱科技的声学精品工程
  • 智慧城市SaaS平台/交通设施运行监测系统之桥梁运行监测、城市道路塌陷风险运行监测系统架构内容
  • 网络编程--TCP/UDP Socket套接字
  • 验证码流程
  • 【AI解读源码系列】ant design mobile——Space间距
  • 京东API分类接口实战指南：获取各类商品信息
  • 【大模型本地运行与部署框架】Ollama的API交互
  • Spring拦截器中@Resource注入为null的问题
  • PAT乙级_1120 买地攻略_Python_AC解法_含疑难点
  • 6.3Element UI 的表单
  • 【python断言插件responses_validator使用】
  • 分布式系统与单机系统的优劣势对比
  • Reachability Query
  • Linux系统编程——进程 | 线程
  • 直播美颜SDK技术解析：人脸美型功能的算法原理与实现方案
  • TCP与HTTP协议以及爬虫