简介这份资源面向运维工程师与VoIP通信系统开发者聚焦Freeswitch高可用架构的落地实践通过Keepalived实现主备节点故障自动切换解决单点故障导致通信服务中断的问题。资源包共4个文件约38KB包含2个Shell脚本、1份安装手册文本和1张Visio逻辑图分别用于健康检查与SSH辅助操作、Keepalived安装配置说明以及主备切换全流程的可视化梳理。已有668人学习下载适合具备一定Linux与通信平台基础的读者参考。读者可从中获取健康检查脚本的编写思路、VIP漂移与故障转移的配置要点并借助逻辑图直观理解从服务监控到备用节点接管的完整链路为实际部署Freeswitch HA方案提供可复用的脚本与排错依据。1. 从一次凌晨三点的故障说起FreeSWITCH 高可用到底在解决什么凌晨三点监控告警响了——单台 FreeSWITCH 进程还在但 SIP 注册全部超时坐席电话集体掉线。运维重启服务花了六分钟这六分钟里所有呼入全部漏接。事后复盘发现问题不在 FreeSWITCH 本身而在于整条链路只有一台机器在扛没有任何故障转移机制。这就是 freeswitch HA 要解决的核心问题让呼叫控制层在单点故障时能自动切换把中断时间从分钟级压到秒级。这份资源给出的方案是用 keepalived 做 FreeSWITCH 的高可用包含方案设计逻辑和架构图。它适合已经在跑单机 FreeSWITCH、想往生产级高可用演进的中小团队也适合正在做呼叫中心或语音平台选型的工程师。方案本身不复杂但真正落地时VIP 漂移、SIP 注册状态同步、媒体流重建这几个环节都有不少细节要处理。下面按「方案怎么设计 → 环境怎么搭 → 脚本怎么写 → 坑在哪 → 怎么验证」的顺序拆开讲。2. keepalived FreeSWITCH 的架构选型与设计逻辑2.1 为什么是 keepalived 而不是其他方案做 FreeSWITCH 高可用常见思路有几种DNS 轮询、负载均衡器前置、keepalived VIP 漂移。DNS 轮询的问题在于 TTL 缓存不可控故障时客户端可能几分钟都切不过来负载均衡器方案需要额外维护一层对中小规模部署来说成本偏高。keepalived 走的是 VRRP 协议在主备节点之间用虚拟 IP 做漂移切换时间通常在 1 到 3 秒对 SIP 信令来说基本可以接受。选 keepalived 的另一个理由是它足够轻。它不需要额外端口不侵入 FreeSWITCH 本身的配置通过 notify 脚本就能联动控制 FreeSWITCH 的启停和状态检查。对于已经有一套 FreeSWITCH 配置的团队来说改造成本最低。但要注意keepalived 解决的是 IP 层的高可用它不负责 SIP 注册状态的同步。也就是说主节点挂了切到备节点备节点上的 FreeSWITCH 是全新启动的之前注册在上面的分机需要重新注册。这是这个方案最大的边界后面会详细讲怎么缓解。2.2 主备模式与双主模式的取舍keepalived 支持两种典型模式主备MASTER/BACKUP和双主两个节点互为主备。FreeSWITCH 场景下我一般推荐主备模式原因有两个。第一FreeSWITCH 的呼叫状态是有状态的。一通电话建立后信令和媒体都绑定在具体节点上如果两个节点同时活跃呼叫状态没法共享容易出现回铃异常或单通。第二双主模式下两个节点都要处理信令SIP 注册冲突的概率会上升排查起来很头疼。主备模式的结构很清晰两台机器一台 MASTER 持有 VIP对外提供服务另一台 BACKUP 待命定期检查 MASTER 的健康状态。MASTER 挂了BACKUP 接管 VIP启动 FreeSWITCH继续服务。2.3 健康检查的设计逻辑keepalived 默认用 VRRP 心跳判断对端是否存活但这只能判断机器是否宕机判断不了 FreeSWITCH 进程是否正常。如果 FreeSWITCH 进程还在但已经假死比如线程池耗尽、数据库连接断开VRRP 心跳是正常的VIP 不会漂移业务照样中断。所以方案里必须加一层应用级健康检查。常见做法是写一个检测脚本定期检查 FreeSWITCH 的端口响应或执行fs_cli命令看返回是否正常。脚本返回非零keepalived 就把节点权重降低或触发切换。这个检测脚本的检查频率和超时时间需要权衡太灵敏容易误切太迟钝切换慢。我一般设成每 2 秒检查一次连续 3 次失败才触发切换这样既能快速响应又不会因为一次网络抖动就误判。2.4 架构逻辑图的关键节点方案里的设计逻辑图通常包含这几个部分两台 FreeSWITCH 节点、VIP 地址、keepalived 的 VRRP 实例、健康检查脚本、以及 notify 脚本的触发点。VIP 是对外暴露的地址SIP 客户端和网关都指向这个 VIP。keepalived 负责在 MASTER 和 BACKUP 之间漂移 VIPnotify 脚本负责在状态切换时启动或停止 FreeSWITCH。有一个细节容易被忽略BACKUP 节点上的 FreeSWITCH 在待命期间应该是停止状态而不是运行状态。如果 BACKUP 上的 FreeSWITCH 也在跑它可能会尝试注册到同一个网关造成注册冲突。所以 notify 脚本里要在 BACKUP 状态时确保 FreeSWITCH 是停的切换到 MASTER 时再启动。3. 环境搭建与 keepalived 配置实操3.1 基础环境准备假设两台机器IP 分别是 192.168.1.10 和 192.168.1.11VIP 用 192.168.1.100。操作系统以常见的 Linux 发行版为例FreeSWITCH 已经编译安装好路径在 /usr/local/freeswitch。先确认两台机器的基础条件# 关闭防火墙或放行 VRRP 协议协议号 112 # 如果用的是 iptables需要放行 VRRP iptables -I INPUT -p vrrp -j ACCEPT # 确认两台机器时间同步 ntpdate pool.ntp.org # 确认内核允许绑定非本地 IPVIP 漂移需要 sysctl -w net.ipv4.ip_nonlocal_bind1 echo net.ipv4.ip_nonlocal_bind1 /etc/sysctl.confnet.ipv4.ip_nonlocal_bind这个参数很关键。默认情况下Linux 不允许进程绑定一个不属于本机的 IP。VIP 漂移过来之前FreeSWITCH 配置里如果写了监听 VIP启动时会报错。开启这个参数后FreeSWITCH 可以绑定 VIP即使当前 VIP 不在本机。3.2 安装 keepalived# CentOS/RHEL 系 yum install -y keepalived # Debian/Ubuntu 系 apt-get install -y keepalived # 确认版本 keepalived --version安装完成后配置文件在 /etc/keepalived/keepalived.conf。默认配置先备份然后重写。3.3 MASTER 节点配置# /etc/keepalived/keepalived.conf on MASTER (192.168.1.10) global_defs { router_id FS_MASTER # 节点标识主备要不同 enable_script_security # 允许非 root 执行脚本时需注意权限 } # 健康检查脚本定义 vrrp_script chk_freeswitch { script /etc/keepalived/check_fs.sh # 检测脚本路径 interval 2 # 每 2 秒检查一次 timeout 2 # 脚本超时时间 fall 3 # 连续 3 次失败才认为异常 rise 2 # 连续 2 次成功才恢复 weight -30 # 失败时优先级降低 30 } vrrp_instance VI_FS { state MASTER interface eth0 # 网卡名称按实际改 virtual_router_id 51 # 主备必须一致 priority 100 # MASTER 优先级高于 BACKUP advert_int 1 # VRRP 通告间隔 1 秒 authentication { auth_type PASS auth_pass fsvrrp2024 # 主备密码一致 } virtual_ipaddress { 192.168.1.100/24 dev eth0 # VIP 地址 } track_script { chk_freeswitch # 引用上面的检测脚本 } notify_master /etc/keepalived/notify.sh master notify_backup /etc/keepalived/notify.sh backup notify_fault /etc/keepalived/notify.sh fault }几个参数说明virtual_router_id是 VRRP 组标识同一组的主备必须相同不同组不能冲突。priority决定谁当 MASTER数值大的胜出。weight -30表示健康检查失败时优先级减 30如果 BACKUP 的优先级是 90减完后 MASTER 变成 70BACKUP 就会抢占。3.4 BACKUP 节点配置# /etc/keepalived/keepalived.conf on BACKUP (192.168.1.11) global_defs { router_id FS_BACKUP enable_script_security } vrrp_script chk_freeswitch { script /etc/keepalived/check_fs.sh interval 2 timeout 2 fall 3 rise 2 weight -30 } vrrp_instance VI_FS { state BACKUP interface eth0 virtual_router_id 51 # 与 MASTER 一致 priority 90 # 低于 MASTER advert_int 1 authentication { auth_type PASS auth_pass fsvrrp2024 # 与 MASTER 一致 } virtual_ipaddress { 192.168.1.100/24 dev eth0 } track_script { chk_freeswitch } notify_master /etc/keepalived/notify.sh master notify_backup /etc/keepalived/notify.sh backup notify_fault /etc/keepalived/notify.sh fault }主备配置的差异只有state、router_id和priority三处。其他参数必须一致尤其是virtual_router_id和auth_pass不一致会导致 VRRP 协商失败。3.5 健康检查脚本#!/bin/bash # /etc/keepalived/check_fs.sh # 检查 FreeSWITCH 是否正常响应 FS_CLI/usr/local/freeswitch/bin/fs_cli TIMEOUT2 # 方法一检查 fs_cli 是否能执行成功 result$(timeout $TIMEOUT $FS_CLI -x status 2/dev/null | grep -c UP) if [ $result -eq 0 ]; then # 方法二检查 SIP 端口是否监听 if ! ss -ulnp | grep -q :5060; then exit 1 fi fi exit 0脚本逻辑是先用fs_cli执行 status 命令看返回里有没有 UP 字样。如果 fs_cli 本身卡住或返回异常再检查 5060 端口是否在监听。两个都失败才返回 1触发 keepalived 的权重调整。timeout命令很重要防止 fs_cli 卡死导致检测脚本一直挂起。fall 3配合interval 2意味着最多 6 秒后会触发切换。3.6 notify 脚本#!/bin/bash # /etc/keepalived/notify.sh # 根据 keepalived 状态切换控制 FreeSWITCH FS_START/usr/local/freeswitch/bin/freeswitch -nc -nonat FS_STOP/usr/local/freeswitch/bin/freeswitch -stop LOG/var/log/keepalived_fs.log case $1 in master) echo $(date) 切换到 MASTER启动 FreeSWITCH $LOG # 先确认没有残留进程 pgrep freeswitch /dev/null $FS_STOP sleep 1 $FS_START ;; backup) echo $(date) 切换到 BACKUP停止 FreeSWITCH $LOG $FS_STOP ;; fault) echo $(date) 进入 FAULT 状态停止 FreeSWITCH $LOG $FS_STOP ;; *) echo 未知状态: $1 $LOG ;; esac这个脚本的核心逻辑是成为 MASTER 时启动 FreeSWITCH成为 BACKUP 或 FAULT 时停止 FreeSWITCH。这样保证同一时间只有一个节点在跑 FreeSWITCH避免 SIP 注册冲突。-nc表示不进入控制台-nonat表示不自动检测 NAT。这两个参数按实际环境调整如果 FreeSWITCH 在 NAT 后面-nonat要去掉。3.7 启动与基础验证# 两台机器都启动 keepalived systemctl start keepalived systemctl enable keepalived # 在 MASTER 上查看 VIP 是否绑定 ip addr show eth0 | grep 192.168.1.100 # 查看 keepalived 日志 tail -f /var/log/messages | grep Keepalived # 在 MASTER 上确认 FreeSWITCH 已启动 /usr/local/freeswitch/bin/fs_cli -x status正常情况下MASTER 上能看到 VIP 绑定在 eth0 上FreeSWITCH 处于运行状态。BACKUP 上没有 VIPFreeSWITCH 是停止的。4. 避坑指南VIP 漂移与 SIP 状态的那些坑4.1 坑一VIP 漂移后 SIP 客户端不重新注册现象主节点故障VIP 漂移到备节点FreeSWITCH 也启动了但分机还是打不通看日志发现分机没有向新节点发起注册。原因SIP 客户端通常只在启动时注册一次之后靠注册有效期续约。VIP 漂移对客户端来说是透明的它不知道后端换了机器注册请求还是发往原来的连接。如果原来的 TCP 连接已经断了客户端可能等注册过期才重新注册这个时间可能是几分钟。解决两个方向。一是缩短 SIP 客户端的注册有效期让它们更频繁地续约这样漂移后能更快重新注册。二是用sip_profile里的force-register-db或类似机制但 FreeSWITCH 本身不共享注册数据库所以更实际的做法是在 notify 脚本里加一步切换后主动发 NOTIFY 或重启网络接口触发客户端重连。我一般会把注册有效期设成 60 秒配合客户端的自动重连实际中断能控制在 1 分钟内。4.2 坑二BACKUP 节点 FreeSWITCH 未完全停止导致注册冲突现象主备切换后网关侧看到同一个账号有两个注册源呼叫路由混乱出现单通或回铃异常。原因BACKUP 节点上的 FreeSWITCH 没有完全停止或者停止后残留了注册状态切换到 MASTER 时新旧注册冲突。解决notify 脚本里停止 FreeSWITCH 后要确认进程真的退出了。freeswitch -stop是优雅停止如果卡住可以用kill -9兜底。另外在 BACKUP 状态下可以定期清理 FreeSWITCH 的注册数据库确保切换后是干净状态。# 在 notify.sh 的 backup 分支里加确认逻辑 $FS_STOP sleep 2 if pgrep freeswitch /dev/null; then pkill -9 freeswitch echo $(date) 强制杀死残留 FreeSWITCH 进程 $LOG fi4.3 坑三健康检查脚本误判导致频繁切换现象keepalived 日志里频繁出现 MASTER/BACKUP 状态切换业务忽好忽坏。原因健康检查脚本太敏感或者 fs_cli 执行偶尔超时导致 keepalived 误以为 FreeSWITCH 挂了。解决调整fall和rise参数增加容错次数。同时优化检测脚本不要只依赖 fs_cli可以结合端口检查和进程检查。另外interval不要太短2 秒是比较平衡的值。如果服务器负载高可以放宽到 3 秒。4.4 坑四VIP 漂移后 ARP 缓存导致流量不到新节点现象VIP 已经漂移到备节点但部分客户端还是连到旧节点或者完全连不上。原因交换机或客户端的 ARP 缓存里还留着旧节点的 MAC 地址VIP 的流量还是发往旧节点。解决keepalived 在漂移 VIP 时会发送免费 ARPgratuitous ARP正常情况下交换机会更新缓存。如果网络设备不支持或配置有问题可以在 notify 脚本里手动发 ARP。# 在 notify.sh 的 master 分支里加发免费 ARP arping -c 3 -I eth0 -s 192.168.1.100 192.168.1.1-s指定源 IP 为 VIP-I指定网卡最后的 IP 是网关地址。发 3 次确保交换机更新缓存。4.5 坑五FreeSWITCH 配置里监听的 IP 写死现象VIP 漂移后 FreeSWITCH 启动失败日志报 Cannot bind to 192.168.1.100。原因FreeSWITCH 的 sip_profile 里sip-ip或rtp-ip写死了 VIP但 VIP 还没漂移过来绑定失败。解决确认net.ipv4.ip_nonlocal_bind1已生效。如果还是不行可以把sip-ip改成0.0.0.0监听所有地址或者用auto让 FreeSWITCH 自动检测。但注意监听0.0.0.0时FreeSWITCH 对外通告的 SIP 地址可能不对需要在 profile 里显式指定ext-sip-ip为 VIP。5. 切换验证与进阶技巧5.1 手动触发切换验证配置完成后必须做一次完整的切换验证。最直接的方式是手动停止 MASTER 的 keepalived观察 BACKUP 是否能接管。# 在 MASTER 上停止 keepalived systemctl stop keepalived # 在 BACKUP 上观察 VIP 是否漂移过来 ip addr show eth0 | grep 192.168.1.100 # 在 BACKUP 上确认 FreeSWITCH 已启动 /usr/local/freeswitch/bin/fs_cli -x status # 从客户端发起呼叫测试 # 确认通话正常后在 MASTER 上重新启动 keepalived systemctl start keepalived验证时重点看三个时间点VIP 漂移用了多久、FreeSWITCH 启动用了多久、客户端重新注册用了多久。这三个时间加起来就是实际中断时长。我实测下来VIP 漂移 1 到 2 秒FreeSWITCH 启动 3 到 5 秒客户端重新注册 10 到 30 秒总中断在 15 到 40 秒之间。如果对中断时间有更高要求需要上双活方案或注册状态共享那是另一个量级的复杂度了。5.2 用日志确认切换过程keepalived 的日志会记录状态切换的完整过程排查问题时很有用。# 查看 keepalived 状态切换日志 grep VRRP_Instance /var/log/messages | tail -20 # 查看 notify 脚本的执行日志 tail -50 /var/log/keepalived_fs.log # 查看 FreeSWITCH 启动日志 tail -100 /usr/local/freeswitch/log/freeswitch.log正常情况下日志里能看到 Entering MASTER STATE 或 Entering BACKUP STATE 的记录以及 notify 脚本的执行输出。如果切换失败日志里通常会有 VRRP_Instance(VI_FS) Transition to MASTER STATE 后没有后续动作说明 notify 脚本可能没执行或执行失败。5.3 进阶用 unicast 替代 multicast默认情况下keepalived 用 multicast 发送 VRRP 通告。如果网络环境不支持 multicast或者两台机器不在同一个二层网络需要改成 unicast。# 在 vrrp_instance 里加 unicast 配置 vrrp_instance VI_FS { # ... 其他配置 ... unicast_src_ip 192.168.1.10 # 本机 IP unicast_peer { 192.168.1.11 # 对端 IP } }unicast 模式下VRRP 通告直接发往对端 IP不依赖 multicast。跨网段部署时必须用这种方式。5.4 进阶双节点互相监控的脚本增强基础的 keepalived 配置只能判断本机 FreeSWITCH 是否正常判断不了对端是否真的在服务。可以加一个脚本定期检查对端节点的 FreeSWITCH 状态如果对端异常但本机是 BACKUP可以主动降低优先级触发切换。#!/bin/bash # /etc/keepalived/check_peer.sh # 检查对端 FreeSWITCH 是否正常 PEER_IP192.168.1.10 TIMEOUT2 # 检查对端 SIP 端口是否响应 if ! timeout $TIMEOUT nc -zu $PEER_IP 5060 2/dev/null; then # 对端 SIP 端口不通返回失败 exit 1 fi exit 0这个脚本可以加到track_script里配合weight使用。但要注意对端检查失败不一定意味着要切换因为可能是网络问题而不是 FreeSWITCH 问题。我一般会把这个检查的weight设得小一点比如 -10让它只作为辅助判断。5.5 一个容易忽略的细节FreeSWITCH 的 PID 文件FreeSWITCH 启动时会写 PID 文件如果 PID 文件残留下次启动可能报错。notify 脚本里停止 FreeSWITCH 后最好清理一下 PID 文件。# 在 notify.sh 的 backup 和 fault 分支里加 rm -f /usr/local/freeswitch/run/freeswitch.pid这个细节不起眼但在频繁切换的场景下能避免不少启动失败的问题。从那以后我每次配 keepalived 做 FreeSWITCH HA都会先把健康检查脚本单独跑一遍确认在各种异常情况下返回值正确再启动 keepalived。这个习惯帮我省了很多次半夜被叫起来排查的麻烦。希望帮到你。本文还有配套的精品资源点击获取