简介针对Freeswitch高可用场景的Keepalived HA方案资源包面向需要为VoIP通信系统构建主备高可用架构的运维、通信工程师及项目决策者可用于避免单点故障导致通话中断尤其适合已在生产环境使用Freeswitch但缺乏双机热备落地经验的团队。压缩包内共4个文件包含两个Shell脚本服务健康检查与故障切换后SSH辅助连接、一份Keepalived安装配置手册和一张Visio格式的FS主备逻辑图总大小仅38KB便于快速下载与工程落地。已有665人学习下载。手册内容覆盖Keepalived的安装、VRRP实例定义、虚拟IP配置、健康检查脚本挂载以及状态验证方法示例脚本可直接检测Freeswitch运行状态逻辑图则清晰展示了从健康检查到VIP漂移的完整故障切换流程。阅读后既能理解主备设计逻辑也能参照脚本和配置说明在真实服务器上实施逻辑图还可作为方案设计文档的一部分便于团队评审或向领导汇报整体轻量、针对性强非常适合希望快速掌握FS高可用搭建思路的运维人员。 做VoIP这么多年FreeSWITCH行内一般直接叫FS作为信令和媒体处理核心稳定性和可用性始终是平台建设的头等大事。FS本身并没有内置高可用能力无论mod_sofia的注册状态、通话中的RTP媒体流还是与上游SIP中继、下游话机的对接只要进程挂了或者机器宕了轻则新呼叫无法建立重则正在通话的媒体全部中断客服中心、外呼平台、调度系统会跟着一起遭殃。我最近在几个项目中落实的FS高可用落地方案就是keepalivedVRRP这套组合。它做的事情其实很简单用虚拟IPVIP抽象业务入口用健康检查脚本感知FS的存活状态在主备节点之间快速切换让话机和运营商中继感知不到底层节点变化。这篇就把方案架构、核心配置、实操步骤和踩坑记录一次讲透适合正在搭建FS主备容灾或者想把单点FS改造成高可用架构的运维和通信工程师参考。1. 方案设计思路与HA架构选型1.1 FS的高可用痛点与keepalived的定位FS的故障场景分好几层进程崩溃、主机宕机、网卡异常、网络分区、磁盘写满导致SIP注册表异常等等。很多刚接触HA的同学第一反应是“进程在就行”实际上业务侧的判断标准远比进程存活严格。SIP客户端能注册上、能拨出电话、媒体包能收得到这三个层面都要照顾到才算是真正的高可用。市面上标着“HA软件”的方案并不少PacemakerCorosync、LVSKeepalived、Keepalived单独做VIP、各类商业HA套件各有各的适用场景。我在FS的HA选型里更倾向于纯keepalived核心原因是FS的HA需求本质上是“把故障快速暴露出来把入口IP快速切走”。HA方案适用场景优点缺点VRRP/keepalived双节点主备业务入口是VIP配置短平快故障收敛快便于对接进程/端口健康检查不做资源约束主备间没有协调动作PacemakerCorosync需要资源级约束、多服务联动、双主场景资源管理强大多个服务统一编排配置复杂学习成本高对FS这种“无状态迁移”业务来说偏重LVSKeepalived负载均衡 后端多节点天然支持多活容量扩展好需要额外一次转发媒体场景下要小心流量路径商业HA套件全托管适合怕麻烦的场景界面友好支持丰富检测成本高且黑盒逻辑难定制对大多数中小型VoIP平台来说两个节点、一个VIP、一组健康检查脚本就足够了。keepalived用VRRP协议把两个节点抽象成一个虚拟网关省掉了消息队列、资源约束这类复杂组件恰恰是它的价值所在。1.2 设计逻辑图与节点角色划分动手部署前先把拓扑和节点角色画清楚。我这套方案的整体逻辑图如下---------------------------- | 话机 / 软终端 / 上游SIP中继 | --------------------------- | 业务访问入口 VIP 192.168.1.100 | --------------------------- | 核心交换机 | --------------------------- | --------------------------- | keepalived 主备决策 | --------------------------- ---------------------------- | | --------------- --------------- | FS节点AMASTER| | FS节点BBACKUP| | freeswitch | | freeswitch | | keepalived | | keepalived | | priority100 | | priority90 | | 物理IP .11 | | 物理IP .12 | --------------- --------------- | | --------共享资源区------------- | CDR数据库 / 录音文件 v ------------------ | 外部数据库 / 存储 | -------------------设计上的关键是区分三类地址物理IP用于节点真实通信VIP用于对外提供业务入口两者不能混用。两个节点上分别部署完整的FSFS本身互相独立运行keepalived在主备之间跑VRRP正常情况下VIP落在MASTER节点A上所有话机和中继感知到的都是A。当A的FS进程异常、主机宕机或网络隔离检测失败时B通过健康检查脚本发现主节点不可用在配置的优先级机制下把自己提升为MASTER将VIP绑定到本机网卡并发ARP刷新。业务侧新的注册和呼叫自然切到B用户几乎无感知。生产部署中有几个角色设计细节容易忽略virtual_router_id在同一二层网络内必须唯一主备认证密码必须一致优先级数字不能做反VIP所在网段必须与业务侧二层打通。FS侧配置强烈建议做成模板化的相同配置不要因为节点不同而搞出“差异配置地狱”。2. 核心配置与细节解析2.1 环境准备与基础安装以CentOS/RHEL系统为例两个节点分别安装依赖和keepalived即可yum install -y keepalived ipvsadm # 如果跑的是Ubuntu/Debian apt install -y keepalived ipvsadm这里多说一句如果FS是通过Docker容器部署的我不建议把keepalived塞进同一个容器里。容器内部跑VRRP需要NET_ADMIN权限容器网络模型变了之后心跳行为会很怪而且容器重启和FS服务重启的故障判定会互相干扰。更稳妥的做法是keepalived部署在宿主机上健康检查脚本直接探测容器暴露的端口或FS的IPC接口。这也是为什么有时候看到“pulling fs layer”下载镜像卡半天即使镜像pull下来了如果宿主机的keepalived没有体系化配置容器一重建、IP一漂移业务照样断。镜像可以重试拉取但架构上的单点不会因为容器化就自动消失。2.2 主备节点的keepalived配置详解主节点A的keepalived配置global_defs { router_id FS_HA_NODE_A enable_script_security } vrrp_script chk_fs { script /etc/keepalived/check_fs.sh interval 2 timeout 2 fall 2 rise 2 } vrrp_instance VI_FS { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass FS_HA_2024 } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:vip } track_script { chk_fs } notify_master /etc/keepalived/notify.sh MASTER notify_backup /etc/keepalived/notify.sh BACKUP notify_fault /etc/keepalived/notify.sh FAULT }备节点B的配置把router_id改成FS_HA_NODE_Bstate改成BACKUPpriority改成90其余保持一致。为什么要给主备优先级之间留出10甚至20的差值因为VRRP的主备切换依赖优先级比较如果两个节点优先级一样谁抢到谁说了算容易在恢复阶段出现来回横跳。10以上的差值让切换结果足够稳定配合advert_int 1秒的心跳间隔故障感知速度基本在3秒以内SIP注册的临时抖动完全扛得住。2.3 健康检查脚本与故障判定标准配置里track_script引用的check_fs.sh是这套HA方案里最值得花心思的地方。我建议的探测逻辑分三层#!/bin/bash # /etc/keepalived/check_fs.sh # 第一层进程级检查 FS_PID$(pgrep -x freeswitch) if [ -z $FS_PID ]; then exit 1 fi # 第二层FS内部状态检查 timeout 3 fs_cli -x status /dev/null 21 if [ $? -ne 0 ]; then exit 1 fi # 第三层SIP端口探测UDP 5060 timeout 2 bash -c echo -n /dev/udp/127.0.0.1/5060 2/dev/null if [ $? -ne 0 ]; then exit 1 fi exit 0进程级检查能发现FS崩溃的极端情况但发现不了“进程还活着、内部已经卡死”的问题。所以第二层用fs_cli -x status去走一遍FS的IPC接口这个命令能通说明事件循环和核心模块是响应状态正常的。第三层再加一个UDP端口探测是为了防止出现网络配置变化、防火墙策略异常导致SIP信令端口不通的场景。这里必须提一个关键机制keepalived的健康检查脚本退出码非0会导致当前节点权重下降当权重降到低于对端时节点会丢掉MASTER身份。所以我特意加了interval 2秒的周期和timeout 2秒的超时避免脚本因为fs_cli偶发慢响应就误报故障。脚本权限要给执行位否则keepalived会报“script not executable”然后永远不切换属于最容易被忽略的坑之一。3. 实操落地与踩坑记录3.1 部署操作与故障转移演练部署流程我习惯按下面顺序来两个节点先装好FS确保SIP注册、媒体转发功能各自独立可跑。在两个节点上分别放好check_fs.sh加上执行权限。主节点配置MASTER备节点配置BACKUP语法检查keepalived -t。先启动备节点keepalived再启动主节点keepalived避免备节点先抢到VIP造成一闪而过的漂移。用ip addr show eth0确认VIP落在主节点上再用keepalived -n -l方式看VRRP报文交互。进行故障演练。我给客户做验收时故障切换演练是必须项。模拟三类故障# 故障一停掉FS服务观察VIP是否漂移 systemctl stop freeswitch tail -f /var/log/messages此时主节点的keepalived日志应该出现Entering BACKUP STATE备节点出现Entering MASTER STATE随后备用节点网卡上出现VIPSIP终端重新注册到VIP后业务恢复。# 故障二直接把主节点的keepalived停掉模拟HA组件故障 systemctl stop keepalived这种场景下备节点应该感知到对端心跳丢失在3到4秒内接管VIP。# 故障三关掉主节点网卡模拟网络隔离 ip link set eth0 down这个场景最容易暴露问题因为主备之间心跳走的就是这个网卡。如果防火墙放行了VRRP协议备节点会立即接管如果没放行两边都可能认为自己才是MASTER出现脑裂。这也是为什么我要求防火墙必须显式放行VRRP协议协议号是112。3.2 常见故障与排查速查表把我在真实环境中遇到过的问题整理成表格排错效率会高很多故障现象可能原因处理办法备节点永远不接管VIP健康检查脚本没有执行权限或FS未启动导致权重一直为0给脚本加x权限确认systemctl status freeswitch正常出现两个节点同时持有VIPVRRP报文被防火墙拦截或心跳网段不通放行协议112VRRP检查双网卡/交换机端口VLAN配置切换后SIP终端迟迟不恢复注册VIP漂移后没有及时发ARP更新在notify脚本里手动arping -U -I eth0 -c 3 192.168.1.100主节点恢复后VIP不回到主节点默认nopreempt模式或备节点优先级未降回来去掉nopreempt或完全不启用该选项确认priority差值明显健康检查偶发误报导致抖切fs_cli偶发超时脚本超时判断太短增加timeout 2fall 2rise 2参数提升判定弹性虚拟IP冲突业务时好时坏其他设备手动配了同网段IP全局扫描IP冲突避免用网关地址做VIP还有一个VMware环境独有的坑虚拟网卡默认的MAC地址策略在某些虚拟化平台会漂移导致VRRP报文源MAC地址不稳定备节点经常误判对端状态。解决办法是给两个虚拟网卡分别设置静态MAC或者在虚拟交换机上关闭MAC地址更改策略。4. 生产环境建议与经验沉淀4.1 数据同步与资源一致性主备切换之后业务能不能真正恢复取决于FS依赖的外部数据是否一致。FS最核心的外部数据有这么几块SIP账号注册表、CDR话单、录音文件、拨号计划/网关配置、以及与业务系统对接的数据库表。别把话单写在本地磁盘上否则主节点一挂话单直接丢财务对账会出大麻烦。我一般建议CDR直接写入外部数据库数据库自身再上HA比如达梦或MySQL的主备集群。FS的配置文件和录音文件保持双节点一致方式可以根据团队习惯选用Ansible/SaltStack做配置下发或者写rsync定时同步。录音这类媒体文件量大且实时性要求不高rsync加--bwlimit限速在低峰期同步即可拨号计划和网关配置则应该走版本化配置管理避免两台机器之间的差异越滚越大。4.2 通话连续性与媒体流问题很多文章把VIP切换讲得过于理想实际上已建立通话的RTP媒体流并不会因为VIP漂移而自动恢复。SIP会话本质上是端到端协商出来的就算VIP切到备用节点正在通话的话机到原主节点的RTP路径已经断了。这个话题在网络热词里经常被讨论比如“tdm的fs波形”这种说法指的是FS在处理TDM媒体流时时隙和波形数据是绑定在具体硬件资源上的这类媒体更没法跨节点无缝迁移。因此我对使用方的期望管理是keepalived这套HA方案的核心价值在于“新呼叫快速恢复”而不是“零中断热迁移”。要逼近零中断就得在架构上引入SBC做注册代理或者让话机本身配置多个SIP服务器地址。对大多数场景来说切换时间控制在5秒以内加上SIP终端的自动重注册用户体验已经足够平滑。4.3 监控、告警与运行维护keepalived的HA方案解决的是“发生故障时自动切换”解决不了“故障发生了没人知道”。我在生产环境一定会叠加一层外部监控让故障切换的整个过程都能被观测到。最简单有效的组合是Prometheus Alertmanager用node_exporter看系统指标用blackbox_exporter探测SIP端口和VIP连通性再写一个自定义exporter去读keepalived的vrrp状态。注意区分这里的HA和智能家居领域的开源ha系统完全不是一回事不要照搬那边的思路。keepalived的监控指标里最需要盯的就是vrrp状态切换次数如果一周内切了三四次那绝对不是“高可用很勤奋”而是健康检查脚本或网络环境有问题得赶紧排查。我自己在实际项目里还有一个习惯每次故障演练之后把ip addr、keepalived.log、fs_cli -x status的输出全部归档成一份切换记录久而久之就能总结出这套系统在什么条件下切换最顺畅、什么条件下会踩坑。运维排查靠的不是临场灵感是这些平时积累下来的记录。4.4 最后补一个扩展方向如果后面业务量增长这套双节点主备架构还可以平滑演进成“多VIP 多节点”模式。比如在keepalived里同时定义两个vrrp_instance让节点A在实例1里是MASTER、在实例2里是BACKUP节点B相反。这样两个节点都有业务流量进来资源利用率翻倍同时每个实例仍然保持主备的安全边界。配置上只是把priority和virtual_router_id做区分健康检查脚本完全复用。对于FS这种CPU密集型业务这个“负载分摊 互为备份”的模式比单一主备的性价比高不少。本文还有配套的精品资源点击获取