高可用-Keepalived、综合实践：web 集群

高可用-Keepalived

HA 集群能解决哪些问题？

当计划使用HA集群时候，有一个重要的问题需要回答：服务放到HA集群中，可用性是否会增加？

回答这个问题，需要弄清楚服务的能力和该服务的客户端如何配置。

• 取决于解决方案，例如DNS和LDAP自带故障转移或者负载均衡，放到HA集群中没什么好处。DNS或者LDAP服务使用多个服务，具备master/slave角色，或者多个master关系。该服务可在多个服务器之间配置数据冗余。DNS和LDAP的客户端也可以使用多个服务器，这里就没有故障转移，因此，这种服务放置到HA集群中不会增加服务的可用性。

• 那些未自带Failover或者LB的服务，如果配置为HA集群，将会有很多好处。例如在 Openstack 平台解决方案中，将 RabbitMQ 和 Galera 放置到HA集群中，可以带来很多好处。

并不是每个可用性问题都可以通过HA集群解决：

• 如果应用程序存因bug导致crash，即使配置为HA集群，应用同样会crash。这种情况下，服务将会转移到其他节点。但是其他节点上的应用也存在相同的bug问题，同样会导致crash。

• HA集群同样不提供端到端的冗余。集群本身可以正常提供服务，但是网络架构存在问题，导致集群不可达，客户端仍然无法访问服务。因此需要慎重考虑集群架构，避免单点故障，包括集群中的任何组件。

Keepalived 介绍

Keepalived 是一个用 C 语言编写的路由软件。这个项目的主要目标是为 Linux 系统和基于 Linux 的基础设施的负载平衡和高可用性提供简单而健壮的设施。

Keepalived 起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层机制检测每个服务节点的状态，如果某个服务器节点出现异常，或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。

后来 Keepalived 又加入了VRRP的功能，VRRP（Vritrual Router Redundancy Protocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行，因此Keepalvied 一方面具有服务器状态检测和故障隔离功能，另外一方面也有HA cluster功能。

VRRP 原理

VRRP 协议

在现实的网络环境中，主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效。因此这种通信模式当中，路由器就成了一个单点瓶颈，为了解决这个问题，就引入了VRRP协议。

VRRP协议是一种主备模式的协议，通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。

VRRP可以将两台或者多台物理路由器设备虚拟成一个虚拟路由，这个虚拟路由器通过虚拟IP（一个或者多个)对外提供服务，而在虚拟路由器内部十多个物理路由器协同工作，同一时间只有一台物理路由器对外提供服务，这台物理路由设备被成为：主路由器（Master角色)，一般情况下Master是由选举算法产生，它拥有对外服务的虚拟IP，提供各种网络功能，如：ARP请求，ICMP 数据转发等，而且其它的物理路由器不拥有对外的虚拟IP，也不提供对外网络功能，仅仅接收MASTER的VRRP状态通告信息，这些路由器被统称为“BACKUP的角色”，当主路由器失败时，处于BACKUP角色的备份路由器将重新进行选举，产生一个新的主路由器进入MASTER角色，继续提供对外服务，整个切换对用户来说是完全透明的。

每个虚拟路由器都有一个唯一的标识号，称为VRID，一个VRID与一组IP地址构成一个虚拟路由器，在VRRP协议中，所有的报文都是通过IP多播方式发送的，而在一个虚拟路由器中，只有处于Master角色的路由器会一直发送VRRP数据包，处于BACKUP角色的路由器只会接受Master角色发送过来的报文信息，用来监控Master运行状态，一般不会发生BACKUP抢占的情况，除非它的优先级更高，而当MASTER不可用时，BACKUP也就无法收到Master发过来的信息，于是就认定Master出现故障，接着多台BAKCUP就会进行选举，优先级最高的BACKUP将称为新的MASTER，这种选举角色切换非常之快，因而保证了服务的持续可用性。

VRRP 工作原理

Keepalived通过VRRP实现高可用性，它还能实现对集群中服务器运行状态的监控以及故障隔离。

Keepalived工作在TCP/IP 参考模型的 三层、四层、七层，也就是分别为：网络层，传输层和应用层。

根据TCP/IP参数模型隔层所能实现的功能，Keepalived运行机制如下：

• 网络层：提供四个重要的协议，互联网络IP协议、互联网络可控制报文协议ICMP、地址转换协议ARP、反向地址转换协议RARP。

  Keepalived在网络层采用最常见的工作方式是通过ICMP协议向服务器集群中的每一个节点发送一个ICMP数据包，如果某个节点没有返回响应数据包，那么认为该节点发生了故障，Keepalived将报告这个节点失效，并从服务器集群中剔除故障节点。

• 传输层：提供两个主要的协议：传输控制协议TCP和用户数据协议UDP。传输控制协议TCP可以提供可靠的数据输出服务、IP地址和端口，代表TCP的一个连接端，要获得TCP服务，需要在发送机的一个端口和接收机的一个端口上建立连接。

  Keepalived在传输层里利用了TCP协议的端口连接和扫描技术来判断集群节点的端口是否正常，比如对于常见的WEB服务器80端口。或者SSH服务22端口，Keepalived一旦在传输层探测到这些端口号没有数据响应和数据返回，就认为这些端口发生异常，然后强制将这些端口所对应的节点从服务器集群中剔除掉。

• 应用层：可以运行FTP，TELNET，SMTP，DNS等各种不同类型的高层协议，Keepalived的运行方式也更加全面化和复杂化，用户可以通过自定义Keepalived工作方式，例如：可以通过编写程序或者脚本来运行Keepalived，而Keepalived将根据用户的设定参数检测各种程序或者服务是否允许正常，如果Keepalived的检测结果和用户设定的不一致时，Keepalived将把对应的服务器从服务器集群中剔除。

VRRP 脑裂

脑裂的定义

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

脑裂产生的原因

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

1. 网络问题：主从节点间的心跳线路（如专用网线、交换机）故障、断网或延迟过高。
2. 防火墙规则：节点间的VRRP协议端口（默认112端口，UDP 协议）被防火墙屏蔽。
3. 资源耗尽：某节点因 CPU、内存耗尽或负载过高，无法响应心跳请求。
4. 配置错误：keepalived配置中vrrp_instance的state、priority或authentication等参数不一致，导致节点间无法正常协商。

脑裂的危害

• 双节点同时持有虚拟 IP（VIP），导致客户端请求混乱（部分请求成功，部分失败）。
• 若集群管理的是数据库、存储等资源，可能引发数据不一致（如双写冲突）。
• 集群失去高可用意义，甚至因资源竞争导致服务崩溃。

如何避免脑裂？

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

1. 增加心跳检测线路

   除了主网络，添加备用通信线路（如独立网卡、交叉网线），避免单线路故障导致心跳中断。

   在 keepalived.conf中指定多网卡检测：

   vrrp_instance VI_1{state MASTER interface eth0# 主网卡virtual_router_id51priority100advert_int1# 同时检测备用网卡（如eth1）track_interface{eth0 eth1}}

2. 启用 VRRP 认证

   配置节点间的认证机制，防止非法节点干扰集群，同时确保心跳信息的可靠性。

   vrrp_instance VI_1{# ... 其他配置authentication{auth_type PASS# 认证类型（PASS或AH）auth_pass123456# 密码（所有节点必须一致）}}

3. 配置防火墙规则

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

   # 允许VRRP协议（CentOS示例）firewall-cmd --add-protocol=vrrp--permanentfirewall-cmd--reload

4. 部署第三方检测工具

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

   示例：在 keepalived.conf中配置 notify 脚本，检测到节点成为主节点后，检查对方是否存活，若存活则强制关闭对方服务：

   vrrp_instance VI_1 { # ... 其他配置 notify_master "/etc/keepalived/check_split_brain.sh master" notify_backup "/etc/keepalived/check_split_brain.sh backup" }

   脚本逻辑：通过 ping、端口检测等方式确认对方状态，若脑裂则执行

   kill

   或

   reboot

   操作。

5. 降低脑裂影响范围

   • 结合业务层设计，如数据库使用主从复制 + 读写分离，避免双写冲突；存储使用分布式锁（如 Redis）控制资源独占。
   • 限制虚拟 IP 的使用场景，仅在确认集群状态正常时对外提供服务。

6. 监控与告警

   通过zabbix、prometheus等工具监控keepalived状态（如vrrp_script检测），当发现双主节点同时存在时及时告警。

总结

脑裂的本质是节点通信失效与状态判断不一致，预防核心在于“多重检测 + 自动隔离”：通过多线路心跳、认证机制降低误判概率，结合脚本和第三方工具在脑裂发生时快速隔离异常节点，同时配合监控及时干预，保障集群稳定。

Keepalvied 实践

网络拓扑

网络说明：

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.20nmcli connection modify ens33 ipv4.gateway10.1.8.20 nmcli connection up ens33# 10.1.8.0/24 网段网关为10.1.8.20nmcli connection modify ens33 ipv4.gateway10.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.confsysctl-p# 此时10.1.8.0/24 网段虚拟机可以访问公网了。# 设置防火墙：开启SNAT功能，实现不同网段也可以通过路由器访问公网systemctlenablefirewalld.service--nowfirewall-cmd --add-masquerade--permanentfirewall-cmd --add-masquerade

配置 web

[root@web1-2 ~]## 部署 webyuminstall-ynginxechoWelcome to$(hostname)>/usr/share/nginx/html/index.html systemctlenablenginx.service--now# 访问后端 nginx[root@client1 ~]# curl 10.1.8.11Welcome to web1.zyf.cloud[root@client1 ~]# curl 10.1.8.12Welcome to web2.zyf.cloud

配置 keepalived

配置 web2

web2 作为备节点。

[root@web2 ~]#yuminstall-ykeepalivedcp/etc/keepalived/keepalived.conf{,.ori}vim/etc/keepalived/keepalived.conf

!Configuration Fileforkeepalived global_defs{router_id web2}vrrp_instance nginx{state BACKUP interface ens33 virtual_router_id51priority100advert_int1authentication{auth_type PASS auth_pass zyf@123}virtual_ipaddress{10.1.8.100}}

说明：

1. router_id web2，定义路由器名称，每个节点使用不同的名称。
2. state BACKUP，定义节点角色为备节点，MASTER则代表主节点。
3. interface ens33，定义VIP配置到该接口。
4. virtual_router_id 51，定义虚拟路由器ID，范围1-255，每个节点使用相同名称。
5. priority 100，定义节点优先级，值越大优先级越高。
6. authentication，定义心跳认证。
7. virtual_ipaddress，定义虚拟VIP。

# 启动 keepalived 服务[root@web2 ~]# systemctl enable keepalived.service --now# 查看 IP[root@web2 ~]# ip -br a show ens33ens33 UP10.1.8.12/2410.1.8.100/24 fe80::20c:29ff:fe83:619c/64

配置 web1

web1 作为主节点。

[root@web1 ~]#yuminstall-ykeepalivedcp/etc/keepalived/keepalived.conf{,.ori}vim/etc/keepalived/keepalived.conf

!Configuration Fileforkeepalived global_defs{router_id web1}vrrp_instance nginx{state MASTER interface ens33 virtual_router_id51# master节点优先级要高于BACKUP节点priority110advert_int1authentication{auth_type PASS auth_pass zyf@123}virtual_ipaddress{10.1.8.100}}

# 启动服务[root@web1 ~]# systemctl enable keepalived.service --now# 查看 IP，VIP 切换到 web1[root@web1 ~]# ip -br a show ens33ens33 UP10.1.8.11/2410.1.8.100/24 fe80::20c:29ff:fe16:ad99/64[root@web2 ~]# ip -br a show ens33ens33 UP10.1.8.12/24 fe80::20c:29ff:fe83:619c/64

高可用验证

# 访问 web[root@client1 ~]# curl 10.1.8.100Welcome to web1.zyf.cloud[root@client2 ~]# curl 10.1.8.100Welcome to web1.zyf.cloud# 关闭 web1 的 keepalive服务，再次访问[root@web1 ~]# systemctl stop keepalived.service[root@client1 ~]# curl 10.1.8.100Welcome to web2.zyf.cloud# 再次启动 web1 的keepalive服务，再次访问[root@web1 ~]# systemctl start keepalived.service[root@client1 ~]# curl 10.1.8.100Welcome to web1.zyf.cloud

keepalived 配置文件

配置文件位置：/etc/keepalived/keepalived.conf

配置文件主要包括三部分：

• GLOBAL，全局配置部分
• VRRPD，VRRP协议配置部分
• LVS，LVS服务管理配置部分

示例：

!Configuration Fileforkeepalived# 全局配置global_defs{# 邮件接收者清单notification_email{acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc}# 邮件发送者notification_email_from Alexandre.Cassen@firewall.loc# 邮件发送服务器smtp_server192.168.200.1# 连接邮件服务器超时时间smtp_connect_timeout30# 标识本机名称，集群中主机身份标识名称不能重复router_id LVS_DEVEL# 检查一个VRRP通告中的所有地址是很耗时的。设置这个标志意味着，如果这个通告和之前接收到的通告来自同一个主路由器，则不会执行检查。vrrp_skip_check_adv_addr# 严格遵守VRRP协议。vrrp_strict# 接口发送免费ARP消息的延迟毫秒数vrrp_garp_interval0# 接口发送未经请求的NA消息的延迟毫秒数vrrp_gna_interval0}# VRRP协议配置# VI_1是虚拟实例名称，可自定义vrrp_instance VI_1{# 指定当前节点角色，可以值MASTER和BACKUP，角色由priority决定，这里的值不重要。state MASTER# VIP使用的接口interface eth0#从0到255的任意唯一数字，用于区分VRRPD的多个实例，同一个高可用集群使用相同的idvirtual_router_id51# 用于选举为MASTER，高于其他节点50，将成为MASTERpriority100# VRRP通告之间间隔，1sadvert_int1# VRRP通告认证凭据authentication{auth_type PASS auth_pass1111}# 提供的VIP列表，还可以通过<IPADDR>/<MASK>指定多个地址virtual_ipaddress{192.168.200.16192.168.200.17192.168.200.18}}# LVS服务管理配置# 虚拟服务器是 192.168.200.100 443virtual_server192.168.200.100443{# delay timer for service pollingdelay_loop6# LVS scheduler，支持lb_algo rr|wrr|lc|wlc|lblc|sh|dhlb_algo rr# LVS forwarding method，支持NAT|DR|TUNlb_kind NAT# LVS persistence timeout in seconds, default 6 minutespersistence_timeout50# L4 protocol，支持TCP|UDP|SCTPprotocol TCP# one entry for each realserverreal_server192.168.201.100443{# relative weight to use, default: 1weight1}}

Keepalived 日志

# 以下步骤在 web1 和 web2 节点完成vim/etc/sysconfig/keepalived# 把 KEEPALIVED_OPTIONS="-D"# 修改为：KEEPALIVED_OPTIONS="-D -d -S 0"# 重启 keepalived，查看日志systemctl restart keepalived.servicevim/etc/rsyslog.d/keepalived.conf local0.* /var/log/keepalived.log# 重启日志服务systemctl restart rsyslog# 监控日志tail-f/var/log/keepalived.log

Keepalived 心跳

参数：mcast_src_ip。

!Configuration Fileforkeepalived global_defs{router_id Cluster1}vrrp_instance Nginx{state MASTER interface ens36 mcast_src_ip20.0.0.11 virtual_router_id51priority110advert_int1authentication{auth_type PASS auth_pass zyf@123}virtual_ipaddress{10.1.1.10/24}}

总结

Keepalived 基于 VRRP 协议实现高可用，核心通过虚拟 IP（VIP）对外提供统一访问入口，支持主从、双主两种部署模式。

它通过优先级配置确定主节点，主节点故障时，备节点自动接管 VIP 与服务，实现无缝切换；还可搭配健康检查脚本，实时监测后端服务状态。常与 LVS、Nginx 等负载均衡工具联动，解决单点故障问题，为 Web、数据库等服务构建稳定的高可用架构。

综合实践：web 集群

项目背景

业务场景与核心需求

随着企业数字化转型加速，Web 服务作为业务对外输出的核心载体，其高可用性、高并发承载能力、数据一致性成为支撑业务稳定运行的关键。以电商平台、企业官网、在线教育等典型场景为例，需满足以下核心需求：

1. 高可用保障：Web 服务需实现 7×24 小时不间断运行，避免因单点故障（如服务器宕机、网络中断）导致业务中断，尤其在促销活动、峰值访问时段，服务不可用将直接造成经济损失或用户流失；

2. 高并发承载：面对日益增长的用户访问量（如日均 PV 从 10 万级提升至百万级），单台 Web 服务器的 CPU、内存、网络带宽易成为瓶颈，需通过负载均衡分摊请求压力，保障页面响应速度（目标：95% 请求响应时间＜1 秒）；

3. 数据一致性：Web 服务涉及大量静态资源（如 HTML、CSS、图片、视频）与动态业务数据（如用户上传文件、订单记录），多台 Web 服务器需共享资源，避免出现 “不同服务器展示内容不一致”（如用户在 A 服务器上传的图片，在 B 服务器无法访问）的问题；

4. 易维护与扩展性：业务增长过程中，需支持快速新增 Web 节点扩展集群能力，同时减少运维复杂度（如避免每台服务器重复部署资源、手动同步配置）。

传统架构的痛点与局限

在采用《Keepalived + LVS（DR）+ Nginx+ NFS》方案前，多数企业曾使用 “单 Web 服务器” 或 “简单负载均衡” 架构，面临以下难以突破的局限：

1. 单点故障风险高：

   • 传统 “单台 Nginx服务器 + 本地存储” 架构中，服务器硬件故障（如硬盘损坏、电源故障）或软件异常（如 Nginx进程崩溃）将直接导致服务完全不可用，MTTR（平均恢复时间）依赖人工干预，通常超过 30 分钟，远无法满足业务连续性要求；

     • 即使采用 “2 台 Nginx服务器 + 简单 DNS 轮询”，若其中一台服务器宕机，DNS 缓存可能导致部分用户仍被解析至故障节点，且 DNS 轮询无法感知服务器负载状态，易出现 “故障节点持续接收请求” 或 “高负载节点被分配更多请求” 的问题。

2. 并发承载能力不足：

   • 单台 Nginx服务器受限于 CPU 核心数（如 4 核 8G 服务器仅能稳定承载约 2000-3000 并发连接），当访问量峰值超过阈值时，会出现请求排队、页面超时、503 错误等问题；

   • 若仅通过 “增加服务器数量” 扩展，缺乏高效的负载均衡机制，无法将请求合理分配至各节点，导致资源浪费（部分服务器空闲）与性能瓶颈（部分服务器过载）并存。

3. 数据共享与一致性难题：

   • 多台 Nginx服务器采用 “本地存储静态资源” 时，需通过脚本定期同步资源（如 rsync），但同步延迟易导致 “用户访问不同节点看到不同版本内容”（如首页图片更新后，部分节点仍展示旧图）；

     • 动态数据（如用户上传的头像、订单附件）若存储在本地，将无法在多节点间共享，导致 “用户在 A 节点上传文件后，切换至 B 节点无法查看” 的业务异常。

4. 运维效率低下：

   • 每台 Web 服务器需单独部署 Nginx配置、静态资源、业务代码，新增节点时运维人员需重复操作，耗时且易出错（如配置文件漏改、资源版本不一致）；

     • 缺乏统一的资源管理机制，当静态资源更新（如 CSS 样式调整、图片替换）时，需逐台服务器修改，运维成本随节点数量增加呈线性上升。

技术方案的选型逻辑

针对上述痛点，需构建一套 “高可用负载均衡 + 共享存储 + Web 服务集群” 的一体化架构，而《Keepalived + LVS（DR）+ Nginx+ NFS》组合正是基于以下核心诉求选型：

1. 解决高可用与负载均衡：

   • LVS（Direct Routing 模式）作为四层负载均衡器，具备超高并发承载能力（单机可支撑 10 万 + 并发连接），通过 DR 模式避免 “请求回程流量” 占用带宽，保障转发效率；

     • Keepalived 通过 VRRP 协议实现 LVS 主备高可用，主节点故障时，备节点可在 1-3 秒内自动接管虚拟 IP（VIP），实现 “无感知切换”，彻底消除负载均衡层单点故障。

2. 保障 Web 服务稳定性：

   • Nginx作为成熟的 Web 服务器，兼容性强、配置灵活，可稳定运行 PHP、Python 等动态业务代码，同时通过模块（如 mod_cache、mod_gzip）优化静态资源访问性能；

     • 多台 Nginx组成集群，通过 LVS 分摊请求压力，单节点故障时，LVS 自动将请求转发至其他健康节点，保障服务连续性。

3. 实现数据一致性与共享：

   • NFS（网络文件系统）作为共享存储，将所有 Web 服务器的静态资源（如 /images、/css 目录）与动态上传目录（如 /uploads）挂载至 NFS 服务器，实现 “多节点访问同一存储资源”，彻底解决数据同步问题；

     • NFS 支持权限控制与读写分离（可选配置），可保障资源访问安全性与存储性能。

4. 降低运维复杂度：

   • 架构模块化设计，各组件职责清晰（LVS 负责转发、Nginx负责服务、NFS 负责存储），便于故障定位与单独扩展；

     • 新增 Web 节点时，仅需安装 Nginx并挂载 NFS 目录，无需重复部署资源，运维效率提升 80% 以上。

项目价值与预期目标

通过部署《Keepalived + LVS（DR）+ Nginx+ NFS》架构，预期实现以下业务与技术价值：

1. 业务连续性：Web 服务可用性从 99.9% 提升至 99.99%（年均 downtime 从 8.76 小时降至 52.56 分钟），核心业务场景（如电商促销、在线考试）无服务中断风险；

2. 性能提升：并发承载能力从单台服务器 3000 并发提升至集群 10 万 + 并发，页面响应时间稳定在 500ms 以内，用户体验显著优化；

3. 运维效率：资源部署与更新效率提升 80%，新增节点时间从 2 小时缩短至 15 分钟，减少重复人工操作；

4. 扩展性：支持 Web 节点与 NFS 存储独立扩展（如新增 Nginx节点提升并发、扩容 NFS 存储容量），满足业务 3-5 年增长需求。

项目实践

网络拓扑

网络说明：

1. 所有主机：第一块网卡名为 ens33，第二块网卡名为 ens192
2. 默认第一块网卡模式为nat，第二块网卡模式为hostonly
3. 网关设置：

• 10.1.1.0/24 网段网关为10.1.1.20
• 10.1.2.0/24 网段网关为10.1.2.20
• 10.1.8.0/24 网段网关为10.1.8.20
• 路由器自身网关为10.1.8.2

基础配置

• 主机名

• IP 地址

• 网关：

## 10.1.1.0/24 网段网关为10.1.1.20nmcli connection modify ens33 ipv4.gateway10.1.1.20 nmcli connection up ens33## 10.1.2.0/24 网段网关为10.1.2.20nmcli connection modify ens33 ipv4.gateway10.1.2.20 nmcli connection up ens33## 10.1.8.0/24 网段网关为10.1.8.20nmcli connection modify ens33 ipv4.gateway10.1.8.20 nmcli connection up ens33

提示：

• 单个网卡主机，按网段配置一个网关。
• 多个网卡主机只配置一个网关10.1.8.20

配置 router

## 开启路由echo"net.ipv4.ip_forward=1">>/etc/sysctl.conf## 或者## sed -i "s/ip_forward=0/ip_forward=1/g" /etc/sysctl.confsysctl-p# 防火墙开启伪装：为了其他网段通过路由器访问外网。systemctlenablefirewalld.service--nowfirewall-cmd --add-masquerade firewall-cmd --add-masquerade--permanent

配置免密登录-可选

[root@client ~]# echo 'StrictHostKeyChecking no' >> /etc/ssh/ssh_config[root@client ~]# ssh-keygen -t rsa -f .ssh/id_rsa -N ''[root@client ~]# vim /etc/hosts10.1.1.21 client2.zyf.cloud client210.1.8.20 router.zyf.cloud router10.1.8.21 client1.zyf.cloud client110.1.8.11 web1.zyf.cloud web110.1.8.12 web2.zyf.cloud web210.1.8.13 web3.zyf.cloud web310.1.8.14 ha1.zyf.cloud ha110.1.8.15 ha2.zyf.cloud ha210.1.2.100 nfs.zyf.cloud nfs10.1.8.100 www.zyf.cloud www# 生成密钥对[root@client ~]# ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''# 推送秘钥和hosts[root@client ~]# for host in client2 router web1 web2 web3 ha1 ha2 nfsdo# 推送秘钥sshpass-p123ssh-copy-id root@$host# 推送/etc/hostsscp/etc/hosts root@$host:/etc/hostsdone# 验证秘钥登录[root@client ~]# for host in client2 router web1 web2 web3 ha1 ha2 nfsdosshroot@$hosthostnamedone

配置 nfs

## 安装软件yuminstall-ynfs-utils## 准备共享目录和文件mkdir/usr/share/nginx/html-pechoWelcome to www.zyf.cloud>/usr/share/nginx/html/index.html## 配置共享echo'/usr/share/nginx/html 10.1.2.0/24(rw,sync)'>>/etc/exports## 启用并启动服务systemctlenablenfs-server.service--now

配置 web

[root@web1-3 ~]### 部署 webyuminstall-ynginxechoWelcome to$(hostname)>/usr/share/nginx/html/index.html systemctlenablenginx.service--now## 访问后端 web[root@client1 ~]# curl 10.1.8.11Welcome to web1.zyf.cloud[root@client1 ~]# curl 10.1.8.12Welcome to web2.zyf.cloud[root@client1 ~]# curl 10.1.8.13Welcome to web3.zyf.cloud## 配置NFS挂载[root@web1-3 ~]#yuminstall-ynfs-utilsecho'10.1.2.100:/usr/share/nginx/html /usr/share/nginx/html nfs defaults 0 0'>>/etc/fstab systemctl daemon-reloadmount-adf/usr/share/nginx/html

配置 LVS-RS

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

[root@web1-3 ~]### 增加虚拟网卡nmcli connectionaddtypedummy ifname dummy con-name dummy ipv4.method manual ipv4.addresses10.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 EOFsysctl-p

配置 HA 和 LVS-DS

配置 ha1

yuminstall-ykeepalived ipvsadmcp/etc/keepalived/keepalived.conf{,.bak}vim/etc/keepalived/keepalived.conf

!Configuration Fileforkeepalived global_defs{router_id ha1}vrrp_instance web{state MASTER interface ens33 virtual_router_id51priority110advert_int1authentication{auth_type PASS auth_pass zyf@123}virtual_ipaddress{10.1.8.100/24}}virtual_server10.1.8.10080{delay_loop6lb_algo rr lb_kind DR protocol TCP real_server10.1.8.1180{weight1TCP_CHECK{connect_timeout3retry3delay_before_retry3}}real_server10.1.8.1280{weight2TCP_CHECK{connect_timeout3retry3delay_before_retry3}}real_server10.1.8.1380{weight2TCP_CHECK{connect_timeout3retry3delay_before_retry3}}}

systemctlenablekeepalived.service--now

配置 ha2

yuminstall-ykeepalived ipvsadmcp/etc/keepalived/keepalived.conf{,.bak}vim/etc/keepalived/keepalived.conf

!Configuration Fileforkeepalived global_defs{router_id ha2}vrrp_instance web{state BACKUP interface ens33 virtual_router_id51priority100advert_int1authentication{auth_type PASS auth_pass zyf@123}virtual_ipaddress{10.1.8.100/24}}virtual_server10.1.8.10080{delay_loop6lb_algo rr lb_kind DR protocol TCP real_server10.1.8.1180{weight1TCP_CHECK{connect_timeout3retry3delay_before_retry3}}real_server10.1.8.1280{weight1TCP_CHECK{connect_timeout3retry3delay_before_retry3}}real_server10.1.8.1380{weight1TCP_CHECK{connect_timeout3retry3delay_before_retry3}}}

systemctlenablekeepalived.service--now

测试

功能性测试

[root@client1 ~]# while true ;do curl -s http://10.1.8.100;sleep 1;doneWelcome to www.zyf.cloud......[root@client2 ~]# while true ;do curl -s http://10.1.8.100;sleep 1;doneWelcome to www.zyf.cloud......

高可用测试

持续监控集群可用性。

[root@client2 ~]# while true ;do curl -s http://10.1.8.100;sleep 1;done......

测试1：停止 ha1 上 keepalived 服务。

[root@ha1 ~]# systemctl stop keepalived.service

结果：客户端无感知故障，正常访问集群。

测试2：恢复 ha1 上 keepalived 服务。

[root@ha1 ~]# systemctl start keepalived.service

结果：客户端无感知故障，正常访问集群。

负载均衡测试

测试1：停止 web2 上 nginx 服务，监控客户端访问情况。

[root@web2 ~]# systemctl stop nginx

结果：大概 15 秒，LVS 将 web2 从后端虚拟主机中剔除。

测试2：启动 web2 上 nginx 服务，监控客户端访问情况。

[root@web2 ~]# systemctl start nginx.service

结果：大概 5 秒，LVS将web2加入后端虚拟主机中。