1. 项目概述为什么需要 Keepalived Nginx在线上业务里最怕的就是服务突然“挂掉”。想象一下你负责的电商网站正在搞大促流量瞬间冲上来结果承载所有用户请求的 Nginx 服务器因为硬件故障或者网络波动宕机了整个网站直接无法访问。这不仅仅是技术故障更是业务灾难直接导致收入损失和用户口碑下滑。这时候“高可用”就成了必须考虑的核心架构。高可用不是让单台服务器永不宕机那几乎不可能而是通过冗余设计确保当一台服务器出问题时另一台能立刻顶上对外提供的服务不间断用户毫无感知。这就像给核心服务上了“双保险”。“Keepalived Nginx”就是实现 Web 服务高可用最经典、最直接的组合拳之一。Nginx 本身性能强悍能处理高并发请求但它是个单点。Keepalived 则是一个专注于实现 IP 高可用的软件它的核心工作是管理一个“虚拟 IP”。在多台服务器上部署相同的 Nginx 服务然后让 Keepalived 来决定这个虚拟 IP 应该“飘”在哪台服务器的网卡上。用户和上游服务都访问这个虚拟 IP而 Keepalived 会通过健康检查机制确保只有健康的 Nginx 服务器才能持有这个 IP。一旦主服务器故障虚拟 IP 会在秒级内自动漂移到备服务器完成无缝切换。这个方案特别适合中小型团队和业务场景它不依赖于昂贵的硬件负载均衡器完全基于开源软件配置清晰运维成本相对可控。接下来我会拆解这个组合的每一个核心环节从设计思路到实操配置再到避坑指南带你彻底掌握这套高可用架构的搭建与运维。2. 架构设计与核心原理拆解2.1 高可用架构的两种典型模式在动手之前我们先理清两种最常见的部署模式这决定了你服务器的角色和流量走向。主备模式这是最常用、也最易于理解的模式。我们准备两台服务器一台是Master另一台是Backup。在正常情况下虚拟 IP 绑定在 Master 服务器上所有流量都流向它。Backup 服务器上的 Nginx 和 Keepalived 虽然也在运行但它不接收任何用户流量处于“热备”状态。当 Master 故障Keepalived 会触发切换虚拟 IP 漂移到 Backup它开始接管流量。这种模式资源利用率不是最高备机闲置但架构简单切换逻辑清晰。双主模式这种模式要求有两台以上的服务器并且每台服务器上都有独立的业务服务。通过配置多个虚拟 IP并利用 DNS 轮询或上层负载均衡让流量可以分摊到多台服务器。Keepalived 在这里的作用是确保每个虚拟 IP 在当前服务器健康时由其持有故障时则释放。这种模式资源利用率高但配置和运维更复杂通常用于更大型的集群。对于入门和大多数业务场景我强烈建议从主备模式开始。它逻辑简单排错容易足以应对绝大多数的高可用需求。我们后续的讲解也将围绕主备模式展开。2.2 Keepalived 的核心工作原理VRRP 协议Keepalived 的高可用能力其基石是VRRP协议。你可以把 VRRP 理解为一个“选举协议”。在一个 VRRP 组里有多台路由器在我们的场景里就是服务器参与。它们会共同选举出一个Master其他的成为Backup。这个 Master 负责承载虚拟 IP并转发数据。所有的 VRRP 成员之间会通过组播报文进行心跳通信通告自己的优先级和状态。几个关键概念虚拟路由器 ID一个数字比如 51。同一个高可用组内的所有 Keepalived 节点必须配置相同的 VRID这样它们才能相互识别组成一个团体。优先级一个 1-254 之间的数字数字越大优先级越高。在初始选举中优先级最高的节点会成为 Master。这是控制哪台机器“主”哪台“备”的核心参数。虚拟 IP对外提供服务的 IP 地址它不属于任何一台物理服务器而是由当前的 Master 节点“临时持有”。抢占模式当 Backup 节点发现 Master 节点的心跳丢失故障并且自己的优先级更高时它是否会主动抢占成为新的 Master。默认是开启的。工作流程简化版初始化两台服务器都启动 Keepalived加入同一个 VRID 组。选举比较优先级优先级高的成为 Master将虚拟 IP 绑定到自己的网卡上并开始发送心跳报文。稳态Master 定期发送心跳。Backup 监听心跳。用户访问虚拟 IP流量到达 Master 的 Nginx。故障如果 Backup 在连续几个心跳周期内都收不到 Master 的心跳它就认为 Master 挂了。切换Backup 节点此时可能成为新的 Master会发送一个免费 ARP 报文到网络中宣告“这个虚拟 IP 现在归我了”。网络中的交换机、路由器以及其他服务器的 ARP 表会随之更新之后发往虚拟 IP 的流量就自然导向了新的服务器。注意免费 ARP 是切换能成功的关键。它解决了 IP 地址和 MAC 地址映射更新的问题。如果没有这个机制即使虚拟 IP 绑定了新网卡网络设备也不知道该把包发给谁。2.3 Nginx 的角色与健康检查联动在这个架构里Nginx 是真正干活的“业务进程”而 Keepalived 是负责“调度和容灾”的“管家”。但这里有个关键问题如果 Nginx 进程本身崩溃了但服务器操作系统和 Keepalived 进程还活着会怎样答案是虚拟 IP 依然绑定在这台故障服务器上但用户请求发过来后Nginx 无法响应服务依然中断。所以一个健壮的高可用方案必须让“管家”能监控“工人”的健康状态。这就是Keepalived 对 Nginx 的健康检查。Keepalived 可以配置自定义的检查脚本定期执行。比如写一个脚本检查 Nginx 的 80 端口是否可访问或者直接请求一个本地网页。如果检查失败脚本返回非 0 状态码Keepalived 就会认为本机“不健康”从而主动降低自己的优先级比如减去一个很大的数值触发主备切换。这样无论是整机故障、网络故障还是单纯的 Nginx 进程故障都能被感知并触发高可用切换实现了真正的服务层高可用。3. 环境准备与软件安装3.1 服务器规划与网络配置我们以最典型的两台 CentOS 7 服务器为例进行规划。实际中请替换为你的服务器 IP。服务器A (计划作为初始 Master):主机名: nginx-node-01系统: CentOS 7.9内网 IP: 192.168.1.101虚拟 IP: 192.168.1.100服务器B (计划作为初始 Backup):主机名: nginx-node-02系统: CentOS 7.9内网 IP: 192.168.1.102虚拟 IP: 192.168.1.100关键准备工作主机名与 hosts 文件为方便管理建议设置不同的主机名。同时在两台服务器的/etc/hosts文件中添加对方记录确保能通过主机名互相解析这在查看日志和排查问题时很有用。# 在两台服务器上分别执行 hostnamectl set-hostname nginx-node-01 # 在A上执行 hostnamectl set-hostname nginx-node-02 # 在B上执行 # 编辑 /etc/hosts在两台服务器上都添加 192.168.1.101 nginx-node-01 192.168.1.102 nginx-node-02防火墙与 SELinux确保两台服务器之间的VRRP 组播通信通常是 224.0.0.18 和 IP 协议号 112以及后续 Nginx 的端口如 80是开放的。对于学习环境可以临时关闭防火墙和 SELinux 以排除干扰但生产环境务必配置精确的安全策略。# 临时关闭防火墙重启后失效 systemctl stop firewalld systemctl disable firewalld # 临时关闭 SELinux重启后失效 setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config时间同步确保两台服务器的时间基本一致这对于日志分析至关重要。yum install -y ntpdate ntpdate time.windows.com3.2 Nginx 的安装与基础配置在两台服务器上执行相同的安装操作。这里采用官方仓库安装版本稳定且便于管理。安装 EPEL 仓库和 Nginxyum install -y epel-release yum install -y nginx启动 Nginx 并设置开机自启systemctl start nginx systemctl enable nginx为了区分两台服务器我们修改默认的欢迎页面。这有助于在测试时直观地看到请求落在了哪台服务器上。# 在服务器A (192.168.1.101) 上执行 echo This is Nginx Master Node - 192.168.1.101 /usr/share/nginx/html/index.html # 在服务器B (192.168.1.102) 上执行 echo This is Nginx Backup Node - 192.168.1.102 /usr/share/nginx/html/index.html此时分别访问http://192.168.1.101和http://192.168.1.102应该能看到不同的欢迎语证明 Nginx 安装成功。3.3 Keepalived 的安装与核心配置同样在两台服务器上安装 Keepalived。yum install -y keepalived安装完成后最重要的就是配置文件/etc/keepalived/keepalived.conf。我们先备份默认配置然后从头编写。服务器A (Master) 配置vim /etc/keepalived/keepalived.conf写入以下内容! Configuration File for keepalived global_defs { router_id nginx_node_01 # 标识本节点的字符串通常为 hostname必须唯一 } vrrp_script chk_nginx { script /etc/keepalived/check_nginx.sh # 健康检查脚本路径 interval 2 # 检查间隔秒 weight -20 # 如果检查失败优先级降低20 fall 2 # 连续失败2次才认为故障 rise 1 # 成功1次就认为恢复 } vrrp_instance VI_1 { # 定义VRRP实例VI_1是自定义名称 state MASTER # 初始状态设置为MASTER interface ens33 # 绑定虚拟IP的物理网卡名称请根据实际情况修改ifconfig查看 virtual_router_id 51 # 虚拟路由ID主备必须相同范围0-255 priority 100 # 初始优先级MASTER要比BACKUP高 advert_int 1 # 心跳通告间隔秒 authentication { # 认证机制防止非法节点加入 auth_type PASS # 认证类型 auth_pass 1111 # 认证密码主备必须相同 } virtual_ipaddress { 192.168.1.100/24 # 虚拟IP地址可以多个 } track_script { # 调用上面定义的健康检查脚本 chk_nginx } }服务器B (Backup) 配置配置文件大部分相同关键区别在于state和priority。global_defs { router_id nginx_node_02 # 此处改为 node_02保持唯一 } vrrp_script chk_nginx { script /etc/keepalived/check_nginx.sh interval 2 weight -20 fall 2 rise 1 } vrrp_instance VI_1 { state BACKUP # 初始状态设置为BACKUP interface ens33 virtual_router_id 51 # 必须与Master相同 priority 90 # 优先级低于Master advert_int 1 authentication { auth_type PASS auth_pass 1111 # 密码与Master相同 } virtual_ipaddress { 192.168.1.100/24 } track_script { chk_nginx } }3.4 创建 Nginx 健康检查脚本现在创建上面配置中引用的检查脚本/etc/keepalived/check_nginx.sh。这个脚本的任务是判断本机的 Nginx 是否存活。在两台服务器上创建该文件vim /etc/keepalived/check_nginx.sh写入以下内容#!/bin/bash # 检查 Nginx 进程是否存在 # if pgrep -x nginx /dev/null # then # exit 0 # else # exit 1 # fi # 更推荐的方式检查 Nginx 端口是否可访问 if curl -s -o /dev/null -w %{http_code} http://localhost:80 | grep -q 200\|301\|302; then exit 0 else # 如果检查失败可以尝试重启一次 Nginx根据情况决定是否开启 # systemctl restart nginx exit 1 fi给脚本添加执行权限chmod x /etc/keepalived/check_nginx.sh实操心得检查进程存在pgrep是最简单的方式但不够健壮。有可能进程还在但已经僵死或不响应了。因此我强烈推荐使用curl检查本地端口或特定 URL 的方式这更能代表服务的真实可用性。-s静默模式-o /dev/null丢弃输出内容-w只取状态码效率很高。4. 配置详解与启动流程4.1 Keepalived 配置文件深度解析让我们回过头仔细咀嚼一下配置文件的每个部分理解其背后的意图。global_defs.router_id这个标识会出现在日志里。当你在日志中看到nginx_node_01发送了通告你立刻就知道是哪台机器。必须确保集群内唯一否则日志会混乱。vrrp_script这是定义健康检查任务的地方。script指定要执行的脚本路径。脚本必须以exit 0成功或exit 1失败返回。interval检查间隔。太短会增加系统负担太长则故障感知慢。2秒是一个常用折中值。weight检查失败时的优先级调整值。这是一个关键技巧。假设 Master 初始优先级 100检查失败一次优先级变为 100 (-20) 80。此时 Backup 的优先级 90 就更高了会触发切换。weight值通常设置为一个足够大的负数以确保一旦业务故障本机优先级能立刻低于备机。fall和rise用于简单的故障降级和恢复升级判断避免因网络瞬时抖动导致频繁切换。vrrp_instanceVRRP 实例的核心定义。state初始状态。这里有个常见误区很多人认为这里写了MASTER它就永远是 Master。不对这个状态只是启动时的“期望角色”。最终谁当 Master是由优先级和选举决定的。即使 Backup 节点优先级更高它启动时也会先进入 BACKUP 状态然后通过选举抢占成为 MASTER。interface务必填写正确使用ip addr或ifconfig命令查看你的实际网卡名可能是eth0、ens160、enp0s3等填错会导致虚拟 IP 绑定失败。virtual_router_id范围 0-255同一组内必须完全相同。不同组的 ID 必须不同否则会互相干扰。priority优先级是选举的核心。Master 的优先级必须高于 Backup。通常 Master 设为 100Backup 设为 90。通过weight机制可以实现动态调整。advert_int心跳间隔。1秒是默认值在网络良好的内网中完全没问题。authentication简单的密码认证防止网络内其他机器误配置加入同一个 VRRP 组造成混乱。生产环境建议使用。virtual_ipaddress可以配置多个虚拟 IP每行一个。支持指定子网掩码。track_script将健康检查脚本与 VRRP 实例关联起来。4.2 启动服务与验证虚拟 IP配置完成后在两台服务器上启动 Keepalived 并设置开机自启。systemctl start keepalived systemctl enable keepalived检查服务状态和日志systemctl status keepalived journalctl -u keepalived -f # 动态查看日志关键验证步骤查看虚拟 IP 绑定在初始 Masternode-01上执行ip addr show ens33替换为你的网卡名。你应该能在输出中看到两个 IP一个是物理 IP192.168.1.101另一个就是虚拟 IP192.168.1.100。inet 192.168.1.101/24 brd ... scope global ens33 inet 192.168.1.100/32 scope global ens33而在初始 Backupnode-02上应该只能看到物理 IP192.168.1.102没有虚拟 IP。访问虚拟 IP在你的个人电脑或同一网络的其他机器上打开浏览器访问http://192.168.1.100。你应该能看到来自Master 节点的欢迎页面“This is Nginx Master Node - 192.168.1.101”。这说明流量通过虚拟 IP 正确路由到了 Master 服务器。检查 Keepalived 日志在 Master 节点上查看日志应该能看到它定期发送 VRRP 通告并声称自己是MASTER。在 Backup 节点上日志会显示它处于BACKUP状态并接收来自 Master 的通告。至此基础的高可用集群已经搭建成功。但搭建成功只是第一步更重要的是验证它的故障切换能力是否可靠。5. 高可用功能测试与故障模拟一个不能经受考验的高可用架构是纸上谈兵。我们必须模拟各种故障场景验证切换是否如预期般发生。5.1 模拟主服务器 Nginx 进程故障这是最常见的场景。Nginx 因为某种原因崩溃了但服务器本身还在运行。在 Master (node-01) 上停止 Nginxsystemctl stop nginx观察健康检查脚本等待大约 4 秒interval 2*fall 2Keepalived 会执行两次检查脚本均失败。观察 Keepalived 日志在 Master 上执行journalctl -u keepalived -f你会看到类似以下的日志... VRRP_Script(chk_nginx) failed (exited with status 1) ... VRRP_Instance(VI_1) Changing effective priority from 100 to 80因为优先级从 100 降到了 80低于 Backup 的 90Master 会发送一个优先级为 0 的通告表示要放弃 Master 身份然后进入 BACKUP 状态。观察 Backup 节点在 Backup (node-02) 上查看日志会发现它收到低优先级的通告后自己会转换到 MASTER 状态并开始发送通告。同时使用ip addr命令查看会发现虚拟 IP192.168.1.100已经绑定到了 node-02 的网卡上。验证访问再次访问http://192.168.1.100页面内容应该变成了 “This is Nginx Backup Node - 192.168.1.102”。切换过程对用户来说几乎是瞬间完成的可能只感觉到一次短暂的卡顿或刷新后内容变化。恢复测试在 node-01 上重新启动 Nginxsystemctl start nginx。健康检查脚本会恢复成功优先级加回 20注意weight是负值成功时不会加回需要配置weight 20才会增加我们这里没有配。由于我们配置了state MASTER和更高的初始优先级且抢占模式默认开启当 node-01 的优先级恢复为 100 后它会重新抢占成为 Master虚拟 IP 又会漂移回来。你可以通过访问虚拟 IP 和查看ip addr来验证。5.2 模拟主服务器整机故障宕机这是更彻底的故障模拟比如直接断电或强制关机。直接关闭 Master (node-01) 的电源或在虚拟机中将其强制关机。观察 Backup 节点在 node-02 上Keepalived 会收不到来自 node-01 的心跳报文。在等待了3 * advert_int约3秒的“沉默期”后node-02 会判定 Master 失效自己晋升为 Master并绑定虚拟 IP。这个过程比 Nginx 进程故障稍慢一点因为要等待心跳超时。验证访问访问虚拟 IP服务应已切换到 node-02。恢复主服务器重新启动 node-01。它的 Keepalived 进程启动后会发现自己处于MASTER状态但优先级是 100。它会发送 VRRP 通告。此时网络中存在两个 MASTERnode-02 在故障期间已成为 MASTER但 node-01 的优先级更高100 90因此会发生抢占。node-02 收到更高优先级的通告后会退位为 BACKUP并释放虚拟 IP。虚拟 IP 最终会回到 node-01。5.3 测试脑裂与避免脑裂是指在高可用集群中由于网络分区等原因导致两个节点都认为自己是 Master并且都绑定了虚拟 IP。这会造成 IP 冲突服务混乱。在我们的简单主备模式下通过 VRRP 的优先级和心跳机制脑裂通常发生在网络链路出现问题但两台服务器本身都健康运行时。例如连接两台服务器的交换机故障导致它们彼此无法通信但都能连接客户端网络。如何测试可以在防火墙规则中临时丢弃 VRRP 组播包模拟网络隔离。如何避免使用更可靠的心跳链路如果条件允许可以使用直连网线或独立的心跳网络用于 VRRP 通信与业务网络分离。配置多播检测一些高级配置可以利用额外的脚本检测网络多播是否正常。第三方仲裁对于更严格的场景可以引入第三方仲裁节点当两节点无法通信时由仲裁节点决定谁应该是 Master。对于大多数内部网络环境脑裂发生概率较低。我们的基础配置已经能应对服务器进程和整机故障。了解这个现象及其成因在排查复杂问题时非常有用。6. 生产环境进阶配置与优化基础搭建完成后我们需要考虑如何让它更稳定、更易运维适应生产环境的要求。6.1 增强型 Nginx 健康检查之前的检查脚本比较简单。生产环境中我们可能需要更精细的控制。检查特定 URL如果你的 Nginx 承载了多个应用可以检查一个专用于健康检查的 URL这个 URL 能反映核心应用的状态。# /etc/keepalived/check_nginx.sh #!/bin/bash CHECK_URLhttp://localhost/health RESPONSE$(curl -s -o /dev/null -w %{http_code}\n --connect-timeout 2 --max-time 3 ${CHECK_URL}) if [ ${RESPONSE} 200 ]; then exit 0 else logger -t keepalived Nginx health check failed with code: ${RESPONSE} exit 1 fi在 Nginx 配置中你需要添加一个返回 200 状态的/health路径。检查多个业务端口如果 Nginx 同时监听 80 和 443最好都检查。失败后尝试重启在脚本中当检查失败时可以先尝试一次本地重启 Nginx如果重启成功则退出 0避免不必要的切换因为切换本身也有代价。但要注意重启超时问题避免脚本长时间卡住。if [ ${RESPONSE} ! 200 ]; then systemctl try-restart nginx sleep 2 # 再次检查 RESPONSE$(curl -s -o /dev/null -w %{http_code}\n --connect-timeout 2 --max-time 3 ${CHECK_URL}) if [ ${RESPONSE} 200 ]; then logger -t keepalived Nginx restarted successfully. exit 0 else logger -t keepalived Nginx health check failed even after restart. exit 1 fi fi6.2 使用邮件或通知脚本告警Keepalived 状态变化时可以触发通知脚本以便运维人员及时知晓。在global_defs部分可以配置邮件 SMTP 服务器并在vrrp_instance中配置通知脚本。但更灵活的方式是使用自定义的notify脚本。vrrp_instance VI_1 { ... notify_master /etc/keepalived/notify.sh master notify_backup /etc/keepalived/notify.sh backup notify_fault /etc/keepalived/notify.sh fault ... }创建通知脚本/etc/keepalived/notify.sh#!/bin/bash TYPE$1 NAME$2 STATE$3 case $STATE in MASTER) # 执行成为Master后的操作如启动某些服务、发送告警邮件/钉钉/企业微信 echo $(date) - I am the MASTER now. Host: $(hostname) /var/log/keepalived-state.log # 调用发送告警的函数例如 send_alert Keepalived MASTER Node $(hostname) is now MASTER for VI_1 ;; BACKUP) echo $(date) - I am the BACKUP now. Host: $(hostname) /var/log/keepalived-state.log # 可以执行关闭非必需服务的操作 ;; FAULT) echo $(date) - I am in FAULT state. Host: $(hostname) /var/log/keepalived-state.log # 发送严重告警 ;; *) echo Unknown state exit 1 ;; esac记得给脚本加执行权限chmod x。6.3 配置日志与监控清晰的日志是排查问题的生命线。调整 Keepalived 日志级别默认日志可能在/var/log/messages或journalctl中。你可以在/etc/sysconfig/keepalived中修改启动参数将日志输出到独立文件。# 在 /etc/sysconfig/keepalived 中修改 KEEPALIVED_OPTIONS-D -S 0 -l /var/log/keepalived.log-D输出详细日志-S指定 syslog 设备-l指定日志文件。修改后重启服务。监控虚拟 IP在监控系统如 Zabbix, Prometheus中可以添加对虚拟 IP 的 ping 检测或端口检测作为业务可用性的最上层监控。监控 Keepalived 进程和状态监控系统可以检查keepalived进程是否存在或者通过ip addr命令解析出本机是否持有虚拟 IP作为集群状态的监控。7. 常见问题排查与运维技巧即使配置再仔细运维中总会遇到问题。这里记录一些我踩过的坑和排查思路。7.1 虚拟 IP 无法绑定或访问症状Keepalived 服务运行正常但ip addr看不到虚拟 IP或者无法从其他机器 ping 通/访问该虚拟 IP。排查步骤检查网卡名称interface配置错误是最常见的原因。用ip link show确认网卡名。检查防火墙VRRP 协议使用 IP 协议号112和组播地址224.0.0.18。确保防火墙放行了这些通信。可以临时关闭防火墙测试。# 对于 firewalld永久放行 VRRP firewall-cmd --permanent --add-rich-rulerule protocol valuevrrp accept firewall-cmd --reload检查网络配置确保两台服务器在同一个二层网络同一个 VLAN/子网VRRP 组播包才能到达对方。检查日志journalctl -u keepalived查看是否有权限错误、配置解析错误等。检查 IP 冲突网络中是否已经存在192.168.1.100这个 IP可以用arping命令检查。7.2 主备切换不成功或延迟高症状主服务器明显故障如关机但备服务器很久才接管或者一直不接管。排查步骤查看 Backup 日志确认 Backup 是否收到了 Master 的故障通告。如果没收到问题出在网络或 Master 的 Keepalived 进程上。调整advert_int和超时默认advert_int 1超时是3 * advert_int。你可以适当调小advert_int如 1来加快检测但会增加网络负担。也可以直接配置vrrp_instance中的garp_master_delay和garp_master_refresh等参数来调整免费 ARP 的发送。检查抢占模式如果不想让原 Master 恢复后抢回 VIP可以在vrrp_instance中设置nopreempt。但通常我们期望它抢回。检查健康检查脚本脚本执行是否超时脚本本身是否有语法错误在脚本中增加日志输出echo $(date) Check result: $? /tmp/check.log来调试。7.3 脑裂问题排查症状两台服务器上都绑定了虚拟 IP网络中出现 IP 冲突告警服务访问不稳定。应急处理立即登录其中一台服务器手动停止 Keepalived (systemctl stop keepalived)让另一台单独提供服务。然后排查网络问题。根本原因排查网络链路检查连接两台服务器的交换机、网线、物理网卡。是否有丢包、闪断防火墙规则确认没有规则阻止了224.0.0.0/24这个组播网段的通信。配置不一致极少数情况下virtual_router_id或authentication配置错误可能导致它们加入了不同的逻辑组但又配置了相同的虚拟 IP。7.4 日常运维命令备忘查看当前状态systemctl status keepalived ip addr show dev ens33 # 查看VIP绑定情况 journalctl -u keepalived --since 5 minutes ago # 查看近期日志手动强制切换谨慎使用在 Master 上可以通过发送信号来降低优先级触发切换。# 查找 Keepalived 的 master 进程 PID ps aux | grep keepalived | grep -v grep # 向该进程发送 SIGUSR1 信号其优先级会降低需在编译时开启相应功能默认可能不支持 # 更安全的方式是直接修改配置文件降低 priority然后 reload最干净的方式是在 Backup 上临时提高其优先级修改配置并systemctl reload keepalived使其抢占。测试完成后改回。配置文件检查在重启前务必检查配置语法。keepalived -t -f /etc/keepalived/keepalived.conf如果显示Configuration file is OK再执行systemctl reload keepalived平滑重载配置。