银河麒麟服务器KY10上快速部署Keepalived高可用集群
1. 为什么需要Keepalived高可用集群？
想象一下你运营着一个电商网站，突然服务器宕机了，所有用户都无法下单。这种情况每年造成的损失可能高达数百万。而Keepalived就像给服务器买了份"意外保险"——当主服务器故障时，备用服务器能在毫秒级自动接管服务，用户甚至感受不到切换过程。
在银河麒麟KY10服务器操作系统上部署Keepalived特别适合对稳定性要求高的场景，比如金融交易系统、政务服务平台、医疗信息系统等。我去年给某三甲医院部署的挂号系统就采用这个方案，全年实现了99.99%的可用性。
2. 环境准备与安装
2.1 系统要求检查
首先登录你的银河麒麟KY10服务器，建议使用两台配置相同的机器组成集群。执行以下命令检查系统版本：
cat /etc/kylin-release确保输出包含"Kylin Linux Advanced Server release V10"字样。我曾经遇到过用户用桌面版KY10尝试安装导致依赖缺失的情况，服务器版才是正确选择。
2.2 在线安装Keepalived
银河麒麟的软件源已经包含Keepalived，安装非常简单：
yum install keepalived -y安装完成后检查版本：
keepalived --version注意：如果遇到依赖错误，可以先执行
yum update更新软件源。我在某次部署中发现过旧版镜像源缺少openssl-de依赖的情况。
3. 配置文件深度解析
3.1 主配置文件结构
Keepalived的核心配置文件位于/etc/keepalived/keepalived.conf，主要包含三大模块：
- 全局定义块（global_defs）：设置邮件通知、路由ID等
- VRRP实例块（vrrp_instance）：定义主备切换规则
- 虚拟服务器块（virtual_server）：配置负载均衡规则（可选）
这是我优化过的生产环境配置模板：
global_defs { router_id KY10_HA_01 # 建议用主机名+HA标识 } vrrp_instance VI_1 { state MASTER # 初始状态，备机设为BACKUP interface eth0 # 实际网卡名用ip a命令查看 virtual_router_id 51 # 同一组集群必须相同 priority 100 # 备机设为90 advert_int 1 authentication { auth_type PASS auth_pass 12345678 # 建议8位以上复杂密码 } virtual_ipaddress { 192.168.1.100/24 # 对外服务的浮动IP } }3.2 关键参数详解
virtual_router_id：相当于集群的身份证号，范围1-255，同一局域网内不同集群必须不同。有次客户机房出现"脑裂"问题，就是因为多组集群误用了相同的ID。
priority：优先级决定谁当主节点（值大的优先）。我习惯主设100，备设90-95，这样需要维护时可以通过临时调低主节点优先级实现无损切换。
advert_int：心跳检测间隔，默认1秒。对于跨机房部署可以适当调大，但超过3秒会影响故障感知速度。
4. 高可用集群实战部署
4.1 双机热备配置
假设我们有两台服务器：
- 主机：192.168.1.101（priority 100）
- 备机：192.168.1.102（priority 90）
配置完成后，启动服务：
systemctl start keepalived systemctl enable keepalived验证浮动IP是否绑定到主服务器：
ip addr show eth0应该能看到类似输出：
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.1.101/24 brd 192.168.1.255 scope global eth0 inet 192.168.1.100/24 scope global secondary eth04.2 故障模拟测试
真实环境中一定要做这些验证：
- 手动关闭主节点keepalived服务，观察备机是否在1-3秒内接管IP
- 断开主节点网线，测试链路故障检测
- 使用tcpdump观察VRRP报文：
tcpdump -i eth0 vrrp -n正常应该看到每秒钟有类似报文：
IP 192.168.1.101 > 224.0.0.18: VRRPv2, length 205. 高级配置技巧
5.1 邮件报警设置
在global_defs区块添加：
notification_email { admin@yourcompany.com } notification_email_from keepalived@yourdomain.com smtp_server smtp.163.com smtp_connect_timeout 30然后配置vrrp_instance中的通知触发条件：
notify_master "/etc/keepalived/notify.sh master" notify_backup "/etc/keepalived/notify.sh backup" notify_fault "/etc/keepalived/notify.sh fault"5.2 健康检查扩展
除了VRRP自带的节点存活检测，还可以添加业务级健康检查：
vrrp_script chk_nginx { script "/usr/bin/killall -0 nginx" # 检查nginx进程 interval 2 weight -20 # 检查失败时降低优先级 } track_script { chk_nginx }这样当Nginx异常时，即使服务器本身正常也会触发主备切换。某次客户MySQL服务僵死但服务器没宕机，就是靠这种机制避免了业务中断。
6. 常见问题排查
问题1：备机无法接管VIP
- 检查防火墙是否放行VRRP协议（IP协议号112）
- 使用
journalctl -u keepalived -f查看实时日志 - 确认两台机器的virtual_router_id和auth_pass完全一致
问题2：脑裂现象（两台机器都声明自己是Master）
- 检查网络连通性，特别是组播通信
- 适当减小advert_int值
- 考虑改用单播模式：
unicast_src_ip 192.168.1.101 # 本机IP unicast_peer { 192.168.1.102 # 对端IP }问题3：切换时业务中断
- 检查ARP缓存更新情况
- 考虑配置notify脚本主动刷新ARP：
notify_master "/usr/sbin/arping -U -I eth0 192.168.1.100 -c 3"在实际项目中，我遇到最棘手的是一次交换机配置问题导致VRRP报文被错误过滤。后来通过抓包分析才发现问题，所以强烈建议部署阶段做好网络设备配置检查。