Linux服务--7.高可用-Keepalived 文章着重于新手学习保持足够的存储空间后面需要越来越多的虚机做完实验之后及时删除不必要的虚机以免影响下一次学习。但是记得保存好母机哦高可用-Keepalived 全解析官网 KeepalivedHA 集群能解决哪些问题当计划使用 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 的功能VRRPVritrual Router Redundancy Protocol虚拟路由冗余协议出现的目的是解决静态路由出现的单点故障问题通过 VRRP 可以实现网络不间断稳定运行因此 Keepalvied 一方面具有服务器状态检测和故障隔离功能另外一方面也有 HA cluster 功能。VRRP 原理局域网中的用户终端通常采用配置一个默认网关的形式访问外部网络如果默认网关设备发生故障那么所有用户终端访问外部网络的流量将会中断。可以通过部署多个网关的方式来解决单点故障但是需要解决多个网关之间的冲突问题。VRRPVirtual Router Redundancy Protocol虚拟路由器冗余协议既能够实现网关的备份又能解决多个网关之间互相冲突的问题从而提高网络可靠性。单网关面临的问题当网关 Router 出现故障时本网段内以该设备为网关的主机都不能与 Internet 进行通信。VRRP 概述通过把几台路由设备联合组成一台虚拟的路由设备使用一定的机制保证当主机的下一跳路由设备出现故障时及时将业务切换到备份路由设备从而保持通讯的连续性和可靠性。VRRP 的运行结果是在局域网上提供一个虚拟路由器。本例中局域网中有两个路由器 R1 和 R2R1 端口 IP 地址为 192.168.1.251/24R2 端口 IP 地址为 192.168.1.252/24。配置 R1 和 R2 关联到同一个虚拟路由器该虚拟路由器使用 192.168.1.254 做为端口 IP 地址。所有的 PC 使用 192.168.1.254 做为默认网关。VRRP 基本概念VRRP 路由器运行 VRRP 协议的路由器如 R1 和 R2。VRRP 是配置在路由器的接口上的而且也是基于接口来工作的。VRID一个 VRRP 组VRRP Group由多台协同工作的路由器的接口组成使用相同的 VRIDVirtual Router Identifier虚拟路由器标识符进行标识。属于同一个 VRRP 组的路由器之间交互 VRRP 协议报文并产生一台虚拟路由器。一个 VRRP 组中只能出现一台 Master 路由器。虚拟路由器VRRP 为每一个组抽象出一台虚拟路由器Virtual Router该路由器并非真实存在的物理设备而是由 VRRP 虚拟出来的逻辑设备。一个 VRRP 组只会产生一台虚拟路由器。虚拟 IP 地址及虚拟 MAC 地址虚拟路由器拥有自己的 IP 地址以及 MAC 地址其中 IP 地址由网络管理员在配置 VRRP 时指定一台虚拟路由器可以有一个或多个 IP 地址通常情况下用户使用该地址作为网关地址。而虚拟 MAC 地址的格式是0000-5e00-01xx其中 xx 为 VRID。Master 路由器Master 路由器在一个 VRRP 组中承担报文转发任务。在每一个 VRRP 组中只有 Master 路由器才会响应针对虚拟 IP 地址的 ARP Request。Master 路由器会以一定的时间间隔周期性地发送 VRRP 报文以便通知同一个 VRRP 组中的 Backup 路由器关于自己的存活情况。Backup 路由器也被称为备份路由器。Backup 路由器将会实时侦听 Master 路由器发送出来的 VRRP 报文它随时准备接替 Master 路由器的工作。Priority优先级值是选举 Master 路由器和 Backup 路由器的依据优先级取值范围 0-255值越大越优先值相等则比较接口 IP 地址大小大者优先。VRRP 报文格式VRRP 只有一种报文即 Advertisement 报文基于组播方式发送因此只能在同一个广播域传递。Advertisement 报文的目的组播地址为 224.0.0.18。VRRP 报文字段含义如下VerVRRP 目前有两个版本其中 VRRPv2 仅适用于 IPv4 网络VRRPv3 适用于 IPv4 和 IPv6 两种网络。Virtual Rtr ID该报文所关联的虚拟路由器的标识。Priority发送该报文的 VRRP 路由器的优先级。Count IP Addrs该 VRRP 报文中所包含的虚拟 IP 地址的数量。Auth TypeVRRP 支持三种认证类型不认证、纯文本密码认证、MD5 方式认证对应值分别为 0、1、2。Adver Int发送 VRRP 通告消息的间隔。默认为 1 秒IP Address所关联的虚拟路由器的虚拟 IP 地址可以为多个。Authentication Data验证所需要的密码信息。VRRP 定时器在 VRRP 协议工作过程中VRRP 定义了两个定时器ADVER_INTERVAL 定时器Master 发送 VRRP 通告报文时间周期缺省值为 1 秒。MASTER_DOWN 定时器Backup 设备监听该定时器超时后会变为 Master 状态。MASTER_DOWN 定时器计算公式如下MASTER_DOWN 3* ADVER_INTERVAL Skew_time偏移时间其中Skew_Time 256–Priority/ 256VRRP 协议状态VRRP 主备选举初始创建 VRRP 的设备工作在 Initialize 状态收到接口 Up 的消息后若此设备的优先级小于 255则会先切换至 Backup 状态等待 MASTER_DOWN 定时器超时后再切换至 Master 状态。如果优先级高的设备先启动优先级低的设备后启动则优先级高的设备先进入 Master 状态优先级低的设备收到高优先级的 VRRP 通告报文自己仍处于 Backup 状态。如果优先级低的先启动优先级高的后启动则优先级低的先由 Backup 状态切换为 Master 状态优先级高的设备收到优先级低的 VRRP 通告报文重新进行选举将优先级高的设备切换为 Master 状态。通常情况下VRRP 路由器的接口 IP 地址不会与虚拟路由器的 IP 地址重叠也就是说我们会为虚拟路由器单独规划一个 IP 地址而不会使用某台路由器的接口 IP 地址。当然也存在一个特殊的情况例如在某些网络中 IP 地址资源比较紧缺那么也有可能会将某台路由器的接口 IP 地址用于虚拟路由器此时该路由器将无条件成为 Master。无法手动将 VRRP 接口优先级配置为 255当接口 IP 地址为 IP 地址拥有者时优先级自动成为 255。VRRP 主备切换当 Master 设备主动放弃 Master 地位如 Master 设备退出备份组时会发送优先级为 0 的通告报文用来使 Backup 设备快速切换成 Master 设备而不用等到 MASTER_DOWN 定时器超时。这个切换的时间称为 Skew_time。当 Master 设备发生网络故障而不能发送通告报文的时候Backup 设备并不能立即知道其工作状况。等到 MASTER_DOWN 定时器超时后才会认为 Master 设备无法正常工作从而将状态切换为 Master。keepalived VRRP 工作原理Keepalived 通过 VRRP 实现高可用性它还能实现对集群中服务器运行状态的监控以及故障隔离。Keepalived 工作在 TCP/IP 参考模型的三层、四层、七层也就是分别为网络层传输层和应用层。根据 TCP/IP 参数模型隔层所能实现的功能Keepalived 运行机制如下网络层提供四个重要的协议互联网络IP协议、互联网络可控制报文协议ICMP、地址转换协议ARP、反向地址转换协议RARP。Keepalived 在网络层采用最常见的工作方式是通过 ICMP 协议向服务器集群中的每一个节点发送一个 ICMP 数据包有点类似与 Ping 的功能如果某个节点没有返回响应数据包那么认为该节点发生了故障Keepalived 将报告这个节点失效并从服务器集群中剔除故障节点。传输层提供两个主要的协议传输控制协议 TCP 和用户数据协议 UDP。传输控制协议 TCP 可以提供可靠的数据输出服务、IP 地址和端口代表 TCP 的一个连接端要获得 TCP 服务需要在发送机的一个端口和接收机的一个端口上建立连接。Keepalived 在传输层里利用了 TCP 协议的端口连接和扫描技术来判断集群节点的端口是否正常比如对于常见的 WEB 服务器 80 端口。或者 SSH 服务 22 端口Keepalived 一旦在传输层探测到这些端口号没有数据响应和数据返回就认为这些端口发生异常然后强制将这些端口所对应的节点从服务器集群中剔除掉。应用层可以运行 FTPTELNETSMTPDNS 等各种不同类型的高层协议Keepalived 的运行方式也更加全面化和复杂化用户可以通过自定义 Keepalived 工作方式例如可以通过编写程序或者脚本来运行 Keepalived而 Keepalived 将根据用户的设定参数检测各种程序或者服务是否允许正常如果 Keepalived 的检测结果和用户设定的不一致时Keepalived 将把对应的服务器从服务器集群中剔除。VRRP 脑裂脑裂的定义在 keepalived 高可用集群中脑裂Split-Brain是指主从节点或双主节点之间因通信中断导致各自认为对方故障从而同时争抢资源如虚拟 IP引发集群状态混乱的现象。脑裂产生的原因脑裂的核心是节点间心跳检测失败但实际节点均正常运行常见情况可能导致网络问题主从节点间的心跳线路如专用网线、交换机故障、断网或延迟过高。防火墙规则节点间的 VRRP 协议端口默认 112 端口UDP 协议被防火墙屏蔽。资源耗尽某节点因 CPU、内存耗尽或负载过高无法响应心跳请求。配置错误keepalived 配置中 vrrp_instance 的 state、priority 或 authentication 等参数不一致导致节点间无法正常协商。脑裂的危害双节点同时持有虚拟 IPVIP导致客户端请求混乱部分请求成功部分失败。若集群管理的是数据库、存储等资源可能引发数据不一致如双写冲突。集群失去高可用意义甚至因资源竞争导致服务崩溃。如何避免脑裂通过多重检测机制和资源隔离策略预防脑裂常用方案如下增加心跳检测线路除了主网络添加备用通信线路如独立网卡、交叉网线避免单线路故障导致心跳中断。在 keepalived.conf 中指定多网卡检测vrrp_instance VI_1 { state MASTER interface eth0 # 主网卡 virtual_router_id 51 priority 100 advert_int 1 # 同时检测备用网卡如 eth1 track_interface { eth0 eth1 } }启用 VRRP 认证配置节点间的认证机制防止非法节点干扰集群同时确保心跳信息的可靠性。vrrp_instance VI_1 { # ... 其他配置 authentication { auth_type PASS # 认证类型PASS 或 AH auth_pass 123456 # 密码所有节点必须一致 } }配置防火墙规则允许节点间通过 VRRP 协议通信开放 UDP 112 端口# 允许 VRRP 协议CentOS 示例 firewall-cmd --add-protocolvrrp --permanent firewall-cmd --reload部署第三方检测工具使用 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操作。降低脑裂影响范围结合业务层设计如数据库使用主从复制 读写分离避免双写冲突存储使用分布式锁如 Redis控制资源独占。限制虚拟 IP 的使用场景仅在确认集群状态正常时对外提供服务。监控与告警通过 zabbix、prometheus 等工具监控 keepalived 状态如 vrrp_script 检测当发现双主节点同时存在时及时告警。总结脑裂的本质是节点通信失效与状态判断不一致预防核心在于多重检测 自动隔离通过多线路心跳、认证机制降低误判概率结合脚本和第三方工具在脑裂发生时快速隔离异常节点同时配合监控及时干预保障集群稳定。Keepalvied 高可用技术实践网络拓扑主机名IP 地址服务器角色client1.fengkai.cloud10.1.8.21客户端web1.fengkai.cloud10.1.8.11Web 服务器web2.fengkai.cloud10.1.8.12Web 服务器基础配置主机名、IP 地址、网关client1# client1 hostnamectl set-hostname client1.fengkai.cloud nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.21/24 ipv4.gateway 10.1.8.2 ipv4.dns 10.1.8.2 autoconnect yes nmcli connection up ens33web1# web1 hostnamectl set-hostname web1.fengkai.cloud nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.11/24 ipv4.gateway 10.1.8.2 ipv4.dns 10.1.8.2 autoconnect yes nmcli connection up ens33web2# web2 hostnamectl set-hostname web2.fengkai.cloud nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.12/24 ipv4.gateway 10.1.8.2 ipv4.dns 10.1.8.2 autoconnect yes nmcli connection up ens33配置 web在 web1 和 web2 上部署 nginx[rootweb1-2 ~]# # 部署 web wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo yum install -y nginx echo Welcome to $(hostname) /usr/share/nginx/html/index.html systemctl enable nginx.service --now访问后端 nginx 验证# 访问后端 nginx [rootclient1 ~]# curl 10.1.8.11 Welcome to web1.fengkai.cloud [rootclient1 ~]# curl 10.1.8.12 Welcome to web2.fengkai.cloud配置 keepalived配置 web2web2 作为备节点。[rootweb2 ~]# yum install -y keepalived [rootweb2 ~]# cp /etc/keepalived/keepalived.conf{,.ori} [rootweb2 ~]# vim /etc/keepalived/keepalived.conf! Configuration File for keepalived global_defs { router_id web2 } vrrp_instance nginx { state BACKUP interface ens33 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass fengkai123 # 密码长度不能超过 8 位超过则只取前 8 位 } virtual_ipaddress { 10.1.8.100/24 } }# 启动 keepalived 服务 [rootweb2 ~]# systemctl enable keepalived.service --now # 查看 IP [rootweb2 ~]# ip -br a show ens33 ens33 UP 10.1.8.12/24 10.1.8.100/24 fe80::20c:29ff:fe83:619c/64说明router_id web2定义路由器名称每个节点使用不同的名称。state BACKUP定义节点角色为备节点MASTER 则代表主节点。interface ens33定义 VIP 配置到该接口。virtual_router_id 51定义虚拟路由器 ID范围 1-255每个节点使用相同名称。priority 100定义节点优先级值越大优先级越高。authentication定义心跳认证。virtual_ipaddress定义虚拟 VIP。配置 web1web1 作为主节点。[rootweb1 ~]# yum install -y keepalived [rootweb1 ~]# cp /etc/keepalived/keepalived.conf{,.ori} [rootweb1 ~]# vim /etc/keepalived/keepalived.conf! Configuration File for keepalived global_defs { router_id web1 } vrrp_instance nginx { state MASTER interface ens33 virtual_router_id 51 priority 110 # master 节点优先级要高于 BACKUP 节点 advert_int 1 authentication { auth_type PASS auth_pass fengkai123 } virtual_ipaddress { 10.1.8.100/24 } }# 启动服务 [rootweb1 ~]# systemctl enable keepalived.service --now # 查看 IPVIP 切换到 web1 [rootweb1 ~]# ip -br a show ens33 ens33 UP 10.1.8.11/24 10.1.8.100/24 fe80::20c:29ff:fe16:ad99/64 [rootweb2 ~]# ip -br a show ens33 ens33 UP 10.1.8.12/24 fe80::20c:29ff:fe83:619c/64高可用验证# 访问 web [rootclient1 ~]# curl 10.1.8.100 Welcome to web1.fengkai.cloud [rootclient2 ~]# curl 10.1.8.100 Welcome to web1.fengkai.cloud # 关闭 web1 的 keepalive 服务再次访问 [rootweb1 ~]# systemctl stop keepalived.service [rootclient1 ~]# curl 10.1.8.100 Welcome to web2.fengkai.cloud # 再次启动 web1 的 keepalive 服务再次访问 # master 会抢占 [rootweb1 ~]# systemctl start keepalived.service [rootclient1 ~]# curl 10.1.8.100 Welcome to web1.fengkai.cloudkeepalived 配置文件配置文件位置/etc/keepalived/keepalived.conf配置文件主要包括三部分GLOBAL全局配置部分VRRPDVRRP 协议配置部分LVSLVS 服务管理配置部分示例! Configuration File for keepalived # 全局配置 global_defs { # 邮件接收者清单 notification_email { acassenfirewall.loc failoverfirewall.loc sysadminfirewall.loc } # 邮件发送者 notification_email_from Alexandre.Cassenfirewall.loc # 邮件发送服务器 smtp_server 192.168.200.1 # 连接邮件服务器超时时间 smtp_connect_timeout 30 # 标识本机名称集群中主机身份标识名称不能重复 router_id LVS_DEVEL # 检查一个 VRRP 通告中的所有地址是很耗时的。设置这个标志意味着如果这个通告和之前接收到的通告 来自同一个主路由器则不会执行检查。 vrrp_skip_check_adv_addr # 严格遵守 VRRP 协议。 vrrp_strict # 接口发送免费 ARP 消息的延迟毫秒数 vrrp_garp_interval 0 # 接口发送未经请求的 NA 消息的延迟毫秒数 vrrp_gna_interval 0 } # VRRP 协议配置 # VI_1 是虚拟实例名称可自定义 vrrp_instance VI_1 { # 指定当前节点角色可以值为 MASTER 和 BACKUP这里的值不重要。配置文件的 state 只是启动初始 状态实际会根据 priority 优先级竞选。 state MASTER # VIP 使用的接口 interface eth0 # 从 0 到 255 的任意唯一数字用于区分 VRRPD 的多个实例同一个高可用集群使用相同的 id virtual_router_id 51 # 用于选举为 MASTER高于其他节点 50将成为 MASTER priority 100 # VRRP 通告之间间隔1s advert_int 1 # VRRP 通告认证凭据 authentication { auth_type PASS auth_pass 1111 } # 提供的 VIP 列表还可以通过 IPADDR/MASK 指定多个地址 virtual_ipaddress { 192.168.200.16 192.168.200.17 192.168.200.18 } } # LVS 服务管理配置 # 虚拟服务器是 192.168.200.100 443 virtual_server 192.168.200.100 443 { # delay timer for service polling delay_loop 6 # LVS scheduler支持 lb_algo rr|wrr|lc|wlc|lblc|sh|dh lb_algo rr # LVS forwarding method支持 NAT|DR|TUN lb_kind NAT # LVS persistence timeout in seconds, default 6 minutes persistence_timeout 50 # L4 protocol支持 TCP|UDP|SCTP protocol TCP # one entry for each realserver real_server 192.168.201.100 443 { # relative weight to use, default: 1 weight 1 } }详细信息参考keepalived.conf (5)Keepalived 日志# 以下步骤在 web1 和 web2 节点完成 [rootweb1,web2 ~]# vim /etc/sysconfig/keepalived 14 KEEPALIVED_OPTIONS-D -d -S 0参数含义-D后台守护进程模式Daemon默认必带-d开启 debug 调试日志日志会打印更多 vrrp 细节会打大量日志到 /var/log/messages-S 0syslog facility 0使用 LOG_SYSLOG 设施输出日志⚠️ -d debug 模式生产环境不建议长期开日志量非常大会刷爆 messages。排查问题临时打开问题解决后要删掉 -d。[rootweb1,web2 ~]# vim /etc/rsyslog.d/keepalived.conf local0.* /var/log/keepalived.log # 把 keepalived 日志单独输出到 /var/log/keepalived.log不再混在 /var/log/messages。# 重启日志服务 [rootweb1,web2 ~]# systemctl restart rsyslog # 重启 keepalived观察日志 [rootweb1,web2 ~]# systemctl restart keepalived.service # 监控日志 [rootweb1,web2 ~]# tail -f /var/log/keepalived.logKeepalived 心跳参数mcast_src_ip。! Configuration File for keepalived global_defs { router_id Cluster1 } vrrp_instance Nginx { state MASTER interface ens36 mcast_src_ip 20.0.0.11 # 指定心跳组播报文的源 IP就是 ens36 网卡上的 IP多网卡环境必须 写防止从别的网卡发心跳导致对端收不到如果不指定keepalived 可能随便选一张网卡发心跳报文备 机收不到 VRRP 包两台机器都抢 VIP产生双主故障。 virtual_router_id 51 priority 110 advert_int 1 # 心跳报文发送间隔单位秒master 每 1s 发一次心跳 authentication { auth_type PASS auth_pass fengkai123 } virtual_ipaddress { 10.1.1.10/24 } }生产实践配置 keepalived 配置文件初始 web1 是 masterweb2 是 backupweb1 挂了web2 成为 masterweb1 又恢复了为了保持稳定性不抢占维持 backup 身份当 web2 挂了web1 成为 master# 配置 web1 [rootweb1 ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id web1 } vrrp_instance nginx { state BACKUP # 核心配置所有的节点都是 BACKUP nopreempt # 不抢占 interface ens33 virtual_router_id 51 priority 110 advert_int 1 authentication { auth_type PASS auth_pass fengkai124 } virtual_ipaddress { 10.1.8.100/24 } }[rootweb1 ~]# systemctl restart keepalived.service [rootweb1 ~]# ip -br a # 此刻 web1 是 master lo UNKNOWN 127.0.0.1/8 ::1/128 ens33 UP 10.1.8.11/24 10.1.8.100/24 fe80::3aac:87e5:fa52:e87b/64 fe80::6d0e:a95:db7a:2d31/64# 配置 web2 [rootweb2 ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id web2 } vrrp_instance nginx { state BACKUP interface ens33 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass fengkai123 } virtual_ipaddress { 10.1.8.100/24 } }[rootweb2 ~]# systemctl restart keepalived.service # 测试将 web1 master 关掉web2 成为 master [rootweb1 ~]# systemctl stop keepalived.service #web2 成为 master [rootweb2 ~]# ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 ens33 UP 10.1.8.12/24 10.1.8.100/24 # 将 web1 keepalived 服务恢复观察现象 [rootweb1 ~]# systemctl start keepalived.service # 发现 master 还是 web2 [rootweb2 ~]# ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 ens33 UP 10.1.8.12/24 10.1.8.100/24 # 把 web2 keepalived 关掉观察 web1 [rootweb1 ~]# ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 ens33 UP 10.1.8.11/24 10.1.8.100/24总结Keepalived 基于 VRRP 协议实现高可用核心通过虚拟 IPVIP对外提供统一访问入口支持主从、双主两种部署模式。它通过优先级配置确定主节点主节点故障时备节点自动接管 VIP 与服务实现无缝切换还可搭配健康检查脚本实时监测后端服务状态。常与 LVS、Nginx 等负载均衡工具联动解决单点故障问题为 Web、数据库等服务构建稳定的高可用架构。