Keepalived主节点优先级降低后无法切换至备节点问题排查

核心问题定位 #

从备节点日志received lower priority (150) advert from 192.168.1.122 - discarding可以明确：主节点的优先级并未实际降低到预期的148（150-2），备节点收到的主节点通告优先级仍为初始值150，因此判定主节点优先级仍高于自身（149），不会触发切换。你提到的“优先级降低日志”可能仅为脚本执行日志，实际优先级调整未生效。

排查与修复步骤 #

1. 统一VRRP实例名称（关键） #

主节点实例名为VI_1，备节点为VI_2，虽virtual_router_id均为51，但单播模式下实例名称不一致可能导致优先级识别异常。将备节点的VRRP实例名称修改为与主节点一致：

备节点修改后的配置片段：

vrrp_instance VI_1 {
    state BACKUP
    interface ens160
    virtual_router_id 51
    priority 149
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass d0cker
    }
    virtual_ipaddress {
        192.168.1.128
    }
    unicast_peer {
        192.168.1.122
    }
    track_script {
        chk_myscript
    }
}

2. 验证检查脚本的有效性与权限 #

• 确保脚本具备执行权限：

  chmod +x /home/tp/keepalived/checkscript.sh
  

• 切换到deployer用户手动执行脚本，确认返回值符合预期：

  su - deployer -c "/home/tp/keepalived/checkscript.sh"
  echo $?  # Web服务正常时返回0，停止后返回1
  

• 若deployer用户无法调用curl，将脚本中的curl替换为绝对路径（Ubuntu下通常为/usr/bin/curl）：

  #!/bin/bash
  
  /usr/bin/curl -sSf -m 1 http://localhost:80/ping > /dev/null 2>&1
  if [ $? -ne 0 ]; then
    echo "Failed to ping localhost:80"
    exit 1
  fi
  

3. 优化优先级配置 #

当前主备优先级差值仅为1，结合weight=2的设置，主节点故障后优先级仅比备节点低1，容易出现识别延迟。建议调整：

• 增大主备初始优先级差：主节点设为150，备节点设为140
• 将weight设为负数，让故障时优先级变化更直观：

  vrrp_script chk_myscript {
    script       "/home/tp/keepalived/checkscript.sh"
    interval 2
    fall 2
    rise 2
    weight -5  # 脚本失败时优先级直接减5
  }
  

4. 核对Keepalived日志细节 #

查看主节点日志，确认脚本执行与优先级调整的实际记录：

journalctl -u keepalived -f

若日志中无VRRP_Script(chk_myscript) succeeded或failed的条目，说明脚本未被正确调用，需检查enable_script_security配置是否限制了脚本执行权限。

验证修复 #

1. 重启两台节点的Keepalived服务：

   systemctl restart keepalived
   

2. 停止主节点Web服务，观察主节点日志是否显示优先级降低，备节点是否自动接管虚拟IP。

内容的提问来源于stack exchange，提问作者quibusus