keepalived怎样高可用

联启网络工具 2026-07-16 13

Keepalived高可用实战指南：从原理到集群部署的完整解析

目录导读

Keepalived是什么？为什么需要它？
核心工作原理：VRRP协议与健康检查
实战部署：主备模式配置详解
高级特性：双主模型与负载均衡整合
常见问题与问答集锦
性能优化与排错指南

Keepalived是什么？为什么需要它？

核心定义：Keepalived是一个基于VRRP（虚拟路由冗余协议）实现的高可用解决方案，主要用于Linux系统下的服务故障转移和负载均衡场景，它通过虚拟IP（VIP） 漂移技术，让多台服务器对外表现为一个统一入口，当主节点宕机时，备用节点自动接管服务,保证业务连续性。

keepalived怎样高可用-第1张图片-电脑手机工具软件下载 - 免费实用工具合集 | 联启科技

关键价值：

避免单点故障（SPOF）：单一服务器故障不会导致服务中断
实现秒级切换：故障检测时间通常在1-3秒内完成
无状态透明切换：客户端无需修改连接配置

适用场景：

Web服务集群（Nginx/Apache）
数据库主从切换（MySQL/MariaDB）
负载均衡器高可用（LVS/HAProxy结合）
任何需要稳定VIP服务的场景

核心工作原理：VRRP协议与健康检查

1 VRRP协议的精髓

Keepalived通过VRRP协议在多台服务器间选举MASTER角色,每台节点拥有：

优先级：0-255的数值，数值越高越可能成为MASTER
抢占模式：高优先级节点恢复后自动夺回MASTER角色（默认开启）
多播心跳：使用224.0.0.18:VrrpPort（默认112）发送组播消息

2 健康检查的三种机制

ICMP检查：检测服务器是否存活（最基础）
TCP端口检查：检测指定端口（如80/3306）是否响应
自定义脚本检查：执行Shell脚本，返回0表示正常，非0表示异常

切换流程示例：

正常状态：主节点（Priority:150）拥有VIP 192.168.1.100
故障检测：主节点连续3次未响应（默认间隔1秒）
状态变更：备节点（Priority:100）提升为MASTER
VIP漂移：备节点发送免费ARP更新交换机MAC表
服务恢复：原主节点重启后，因优先级更高重新接管VIP（需开启抢占）

实战部署：主备模式配置详解

1 环境准备

节点角色	IP地址	配置要求
Master	168.1.10	CentOS 7+，双网卡
Backup	168.1.11	CentOS 7+，双网卡
VIP	168.1.100	虚拟IP

2 安装配置（双节点相同操作）

# 安装依赖
yum install -y keepalived
# 主节点配置 /etc/keepalived/keepalived.conf
global_defs {
   router_id LVS_MASTER  # 节点标识，需唯一
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}
vrrp_instance VI_1 {
    state MASTER          # 备节点改为BACKUP
    interface eth0        # VIP绑定网卡
    virtual_router_id 51  # 同一VRRP组内ID需一致
    priority 150          # 主节点优先级建议150-200
    advert_int 1          # 心跳间隔1秒
    authentication {
        auth_type PASS
        auth_pass 1234    # 认证密码（最多8位）
    }
    virtual_ipaddress {
        192.168.1.100/24  # VIP及掩码
    }
    track_script {
        chk_service       # 自定义检查脚本
    }
}
# 健康检查脚本
vrrp_script chk_service {
    script "/etc/keepalived/check.sh"
    interval 2
    weight 2
}

3 检查脚本示例（/etc/keepalived/check.sh）

#!/bin/bash
# 检查核心服务是否存活
if systemctl is-active nginx &>/dev/null; then
    exit 0   # 正常
else
    exit 1   # 故障
fi

关键配置解读：

state：仅表示初始状态，最终角色由优先级决定
virtual_router_id：同一广播域内不能重复（0-255）
advert_int：值越小切换越快，但网络流量增加
weight：脚本检测失败后从优先级中扣减值（此处为2）

4 启动验证

# 启动服务并查看状态
systemctl start keepalived && systemctl enable keepalived
ip addr show dev eth0 | grep 192.168.1.100  # 检查VIP是否在Master上
# 测试故障转移
# 在Master上停止keepalived或Nginx，观察VIP迁移

高级特性：双主模型与负载均衡整合

1 双主模型配置

创建两个VRRP实例，使两台机器分别作为不同VIP的MASTER,实现负载分流：

# 节点A配置
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    virtual_ipaddress {
        192.168.1.100/24  # 节点A持有
    }
}
vrrp_instance VI_2 {
    state BACKUP
    interface eth1
    virtual_router_id 52
    priority 100
    virtual_ipaddress {
        192.168.1.200/24  # 节点B持有（故障时A接管）
    }
}
# 节点B配置则相反：VI_1为BACKUP，VI_2为MASTER

2 与Nginx/LVS联动实现七层高可用

# 整合LVS的DR模式（在Keepalived配置中加入）
virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    protocol TCP
    real_server 192.168.1.10 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
        }
    }
    real_server 192.168.1.11 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
        }
    }
}

效果：VIP漂移时，后端的真实服务器列表自动切换,前端应用毫秒级感知。

常见问题与问答集锦

Q1：Keepalived切换后，为什么客户端无法立即访问？ A：这是由于ARP缓存延迟,解决方案：

配置vrrp_garp_master_repeat 5（发送5次免费ARP）
调整交换机MAC表老化时间（通常5分钟）
在生产环境中使用非抢占模式减少不必要的切换

Q2：两台服务器同时成为MASTER（脑裂）怎么处理？ A：根本原因是心跳通讯中断,排查步骤：

检查防火墙是否开放VRRP组播（224.0.0.18）
使用tcpdump检测组播包：tcpdump -i eth0 vrrp -n
配置仲裁机制：引入第三方仲裁节点（如SNMP或数据库心跳）
开启vrrp_strict严格模式（会拒绝无效MAC的VRRP包）

Q3：Keepalived可以配合容器使用吗？ A：直接运行在容器中不建议（因为有网络栈和组播限制）,推荐方案：

使用宿主级别Keepalived绑定VIP
容器通过hostNetwork模式共享网络
或者使用MetalLB（K8s环境）等原生方案

Q4：优先级相同会怎样？ A：当优先级完全一致时，Keepalived会比较IP地址大小，地址大的成为MASTER，建议始终设置明确优先级差值（至少20以上）。

性能优化与排错指南

1 系统级优化

# 调整ARP学习参数
echo "net.ipv4.conf.all.arp_ignore=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.arp_announce=2" >> /etc/sysctl.conf
# 优化组播接收（多网卡场景）
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

2 排错工具链

日志定位：journalctl -u keepalived -f 或 /var/log/messages
精简调试：将global_defs段追加log 5开启详细日志
抓包分析：tcpdump -i eth0 -nn 'host 224.0.0.18'

3 常见报错处理

错误日志	含义	解决方案
`VRRP_Instance: Not receiving Master advertisement`	心跳丢失	检查网络连通性和防火墙
`Gratuitous ARP: Could not set arp filter`	ARP过滤问题	使用非root用户时需CAP_NET_RAW权限
`Track script failed`	检查脚本异常	确认脚本权限为755且输出无错误

生产建议：

使用独立网卡运行VRRP流量
将Keepalived与业务进程分开监控
定期演练故障转移（每月至少1次）
对于跨机房高可用，避免使用Keepalived（推荐DNS或BGP方案）

Keepalived通过VRRP协议和健康检查机制，为Linux环境提供了简洁高效的高可用解决方案，从单主模式到双主架构，从四层转发到七层负载均衡整合，它能灵活适配各类业务场景，关键在于理解其选举机制、脚本检测逻辑和网络层影响，通过本指南的配置示例和排错思路，你已能构建一个可靠的高可用集群。高可用的价值不在于避免故障，而在于故障发生时服务无感。

标签： Keepalived 高可用

本文地址： https://lianqi.tech/post/13262.html