DRBD双机热备保障IndexTTS2核心数据不丢失-开发者社区

DRBD双机热备保障IndexTTS2核心数据不丢失

在部署AI语音合成系统（如IndexTTS2）时，一个常被低估却至关重要的问题浮出水面：当主服务器突然断电、硬盘损坏或进程崩溃时，那些已经下载好的模型缓存会不会彻底丢失？服务中断多久才能恢复？

这并非理论假设。在实际交付中，客户往往无法接受“重启后重新下载3GB模型”的等待——尤其是网络环境受限的边缘场景。更严峻的是，一旦cache_hub目录损毁，整个语音服务将陷入瘫痪，直到所有资源重新加载完毕。

为解决这一痛点，我们引入了DRBD（Distributed Replicated Block Device）与Keepalived组合方案，在IndexTTS2 V23版本中实现了接近99.9%可用性的双机热备架构。这套系统不仅确保了核心数据零丢失，还让故障切换变得近乎无感。

为什么是DRBD？而不是RAID、NAS或者数据库复制？

很多人第一反应是：“加个NAS不就行了？”但现实远比想象复杂。

RAID只防磁盘坏，不防主机挂；
NAS虽然共享存储，但单点故障仍在控制器上；
数据库复制只能保护结构化数据，对文件系统无能为力；
而IndexTTS2的核心依赖恰恰是本地文件系统中的/root/index-tts/cache_hub——这个存放着预训练模型和推理缓存的目录，动辄数GB，且必须由应用直接读取。

这时候，块设备级别的镜像技术就成了最优解。DRBD正是为此而生。

它工作在Linux内核层，位于物理磁盘与文件系统之间，像一面“透明镜子”，把一台机器上的写操作实时同步到另一台。从应用角度看，它就是一个普通的块设备（比如/dev/drbd0），但实际上背后是跨主机的双副本存储。

更重要的是，它完全不需要修改上层应用逻辑。IndexTTS2仍然照常启动、读写文件，而底层的数据冗余早已悄然完成。

同步机制怎么选？Protocol C为何成为首选？

DRBD支持三种协议模式：

Protocol A（异步）：本地写入即返回，远程可能滞后；
Protocol B（内存同步）：等待对方收到并写入内存；
Protocol C（同步落盘）：必须等远端真正落盘才确认。

我们选择了Protocol C——尽管会带来轻微延迟，但它保证了强一致性。哪怕主节点瞬间断电，备机也能立即接管，并且数据不会出现撕裂或损坏。

举个例子：假设模型正在写入一半时主节点宕机。如果使用异步复制，这部分数据可能根本没传过去；但在Protocol C下，由于未收到远端落盘确认，该次写操作就不会向上层返回成功，从而避免了“半成品”状态。

配置如下：

resource ttsdata { protocol C; net { cram-hmac-alg sha1; shared-secret "index-tts-drbd-secret"; >modprobe drbd drbdadm create-md ttsdata drbdadm up ttsdata drbdadm primary --force ttsdata # 初始主节点

查看状态：

cat /proc/drbd

输出中若显示Primary/Secondary和UpToDate/UpToDate，说明一切就绪。

没有自动切换，谈何“高可用”？

光有数据同步还不够。真正的高可用，必须做到“故障自愈”。

这时就得请出Keepalived——基于VRRP协议的轻量级HA工具。它的核心任务只有一个：维护一个虚拟IP（VIP），谁是主，谁就拥有这个IP。

客户端永远通过http://192.168.1.100:7860访问服务，而不关心背后到底是node1还是node2。

Keepalived会定时检测本地WebUI是否存活。一旦发现服务异常或主机失联，立刻触发切换脚本，将备机升为主机，接管VIP、升级DRBD角色、挂载文件系统、重启服务。

其配置简洁而强大：

vrrp_script chk_webui { script "/usr/local/bin/check_webui.sh" interval 3 weight 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass indextts2_ha } virtual_ipaddress { 192.168.1.100/24 } track_script { chk_webui } notify_master /usr/local/bin/failover_primary.sh notify_backup /usr/local/bin/failover_secondary.sh }

其中健康检查脚本尝试访问/接口，失败则尝试重启服务：

#!/bin/bash curl -f http://localhost:7860/ > /dev/null 2>&1 if [ $? -ne 0 ]; then systemctl try-restart index-tts-webui sleep 5 curl -f http://localhost:7860/ > /dev/null 2>&1 fi exit $?

而主节点切换脚本才是关键所在：

#!/bin/bash set -e # 升级为DRBD主 drbdadm primary ttsdata # 等待角色生效 while ! drbdadm status ttsdata | grep -q "ro:Primary"; do sleep 1 done # 挂载至应用目录 if ! mountpoint -q /root/index-tts; then mount /dev/drbd0 /root/index-tts fi # 启动IndexTTS服务 cd /root/index-tts && bash start_app.sh &

这些脚本都经过幂等设计，即使重复执行也不会出错。配合systemd守护，整个流程全自动完成，RTO（恢复时间目标）控制在10秒以内。

实际运行流程：从故障到恢复的全过程

设想这样一个场景：

Node1 正常运行，提供TTS服务，所有模型缓存写入/dev/drbd0并实时同步至Node2。用户请求始终打向192.168.1.100。

突然，Node1 断电。

3秒后，Node2 未收到VRRP心跳包；
第4秒，优先级判定触发主备切换；
notify_master脚本被执行：
→ 升级DRBD为主；
→ 挂载/dev/drbd0到/root/index-tts；
→ 启动start_app.sh加载模型并开放服务端口；
第8秒，WebUI响应正常；
第9秒，VIP绑定完成；
客户端重试连接，服务已恢复。

整个过程无需人工干预。当Node1重启后，会自动以Secondary身份加入集群，DRBD识别差异并增量同步，后续可手动决定是否回切。