DRBD 全称 Distributed Replicated Block Device，即分布式复制块设备，它是 Linux 内核层面的一种软件化、无共享架构的存储复制方案。简单来说，DRBD 会把本地磁盘上的一个块设备实时镜像到另一台服务器的对应块设备上，两台机器之间通过专用网络不断同步数据块。当主节点因为硬件故障或系统崩溃而不可用时，备节点上的数据几乎是完整且最新的，配合 Pacemaker 等集群资源管理器，就能实现业务几乎无感知的故障切换。相比共享存储阵列，DRBD 不需要昂贵的 SAN 设备，两台普通服务器加一条交叉网线就能跑起来，这也是它在中小规模高可用场景中流行的原因。
DRBD 的核心原理与架构模式
理解 DRBD 的关键在于明白它工作在块设备层，而不是文件系统层。它会在内核中注册一个虚拟块设备，例如 /dev/drbd0，上层的文件系统和应用程序直接读写这个虚拟设备，DRBD 驱动负责把每一次写操作通过内部逻辑传递给本地磁盘，同时把数据块封装成报文发送给对端节点。对端节点收到数据后写入自己的底层磁盘，并根据配置的同步协议决定何时向主节点确认。
DRBD 提供三种同步协议，区别在于确认时机的不同。协议 A 是异步复制，主节点本地写完就确认，数据可能在网络中还在传输，性能最好但可能丢最新数据；协议 B 是半同步，主节点数据包发出后即确认；协议 C 是完全同步，只有对端落盘确认后主节点才向上层返回写入成功，这是生产环境最常用的选择，能保证单节点故障时数据零丢失。绝大多数数据库、业务数据的复制场景都建议使用协议 C，除非对性能要求极高且能容忍少量数据丢失。
在部署形态上，DRBD 分为单主模式和双主模式。单主模式下同一时刻只有一个节点可以挂载文件系统写入，是最安全、最常见的方式，通常与 Pacemaker 配合由集群自动切换主备角色。双主模式要求底层文件系统支持集群锁，比如 GFS2 或 OCFS2，两个节点可以同时读写同一块设备，适用于需要负载均衡的特殊场景，但配置复杂度和排障难度都会明显上升。初次接触 DRBD 建议先从单主模式入手。
双节点环境下的完整配置步骤
下面以两台 CentOS/RHEL 系服务器为例，主机名分别为 node1 和 node2，各准备一块空闲磁盘分区（例如 /dev/sdb1），并配置好主机名解析。首先在两个节点上安装 DRBD 软件包并加载内核模块：
# 两节点均执行 yum install -y drbd90-utils kmod-drbd90 modprobe drbd lsmod | grep drbd # 确认模块已加载
接下来编写全局配置文件 /etc/drbd.d/global_common.conf，这个文件定义全局参数和通用选项。需要注意 net 段中的 verify-alg 用于数据校验，cram-hmac-alg 和 shared-secret 用于节点间通信认证，生产环境务必开启认证：
global {
usage-count no;
}
common {
net {
protocol C;
cram-hmac-alg sha256;
shared-secret "MySecretKey123";
}
disk {
on-io-error detach;
resync-rate 200M;
}
}然后为复制资源单独创建一个资源文件，例如 /etc/drbd.d/r0.res。资源文件定义了资源的名字、两个节点各自使用的底层设备和监听端口。两端端口可以相同也可以不同，但必须保证防火墙放行：
resource r0 {
on node1 {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.10.11:7789;
meta-disk internal;
}
on node2 {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.10.12:7789;
meta-disk internal;
}
}配置文件写好后，将 global_common.conf 和 r0.res 原样拷贝到另一节点，保证两边的配置完全一致。接着在两个节点上初始化 DRBD 元数据并启动资源。元数据是 DRBD 记录数据块同步状态的内部结构，选择 internal 方式时它会存放在底层分区的末尾，因此分区不需要预先创建文件系统，也不需要格式化，更不要挂载：
# 两节点均执行：初始化元数据 drbdadm create-md r0 # 两节点均执行：启用资源 drbdadm up r0 # 仅在 node1 上执行：将 node1 提升为初始主节点并开始首次全量同步 drbdadm primary r0 --force # 查看同步进度，等待状态变为 UpToDate/UpToDate cat /proc/drbd drbdadm status r0
首次全量同步的时间取决于磁盘容量和复制速率设置，可以用 drbdadm status 观察进度百分比。同步完成后，只有主节点可以对 /dev/drbd0 进行格式化和挂载操作，注意这里格式化的是 drbd 设备而不是底层分区：
# 仅在 node1（主节点）执行 mkfs.xfs /dev/drbd0 mkdir -p /data mount /dev/drbd0 /data echo "test data" > /data/hello.txt
主备切换验证与 Pacemaker 集成
手动验证切换是检验配置是否正确的关键一步。在 node1 上先卸载文件系统并把角色降级为备节点，再在 node2 上执行升级和挂载操作：
# node1 上执行 umount /data drbdadm secondary r0 # node2 上执行 drbdadm primary r0 mount /dev/drbd0 /data cat /data/hello.txt # 应能看到 node1 上写入的内容
如果 node2 上能正常读到之前写入的文件，说明复制链路工作正常。生产环境中不应该靠手工执行这些命令来完成切换，而是把 DRBD 资源、文件系统和虚拟 IP 一起交给 Pacemaker 管理。Pacemaker 会监测节点健康状态，一旦主节点失联，自动在备节点上执行升级和挂载，整个过程在几十秒内完成，业务系统只需重连虚拟 IP 即可恢复服务。
与 Pacemaker 集成时有一个常见坑点需要特别注意：DRBD 的角色提升必须在文件系统挂载之前完成，因此资源之间要配置 colocation 和 order 约束，保证提升主角色、挂载文件系统、启动 IP 三个动作按正确顺序执行。另外要合理设置 fencing 策略，避免出现两个节点同时认为自己是主节点的脑裂场景，脑裂一旦发生，两端数据各自演进，后续只能人工判断保留哪一端数据，另一端的数据将被覆盖丢弃。
生产环境的调优与避坑经验
第一个建议是使用专用的同步网络。DRBD 的复制流量直接决定写入延迟，如果和数据流量、业务流量混用一张网卡，网络拥塞时数据库写入会被明显拖慢。有条件的话单独配一块千兆或万兆网卡跑同步流量，配置文件中 address 字段绑定这个专用网段的 IP 即可。条件允许时还可以做双链路冗余，配合 DRBD 的多路径配置防止单网卡故障引发降级。
第二个关注点是同步速率的平衡。首次全量同步或故障恢复后的重新同步阶段，如果 resync-rate 设置过高，会占满磁盘 IO 和网络带宽，影响线上业务；设置过低则恢复窗口拉长，风险敞口变大。可以在运行期动态调整同步参数，例如在线把同步速率临时提到 300M 加快追赶，追平后再降回来。此外开启 c-plan-ahead 相关的动态速率控制参数，让 DRBD 根据网络状况自动调节同步速度，是更省心的做法。
最后是脑裂的预防与处理。脑裂通常发生心跳网络中断但业务口正常的场景，两个节点都尝试变成主节点。预防手段包括：至少两条独立的心跳链路、配置 DRBD 的磁盘超时与 on-no-data-accessible 策略、在集群层启用 STONITH 强制隔离疑似故障节点。一旦 drbdadm status 显示 StandAlone 或 WFConnection 等异常状态，不要急于强制提升，先排查网络和对端状态，谨慎使用 drbdadm connect --discard-my-data 放弃数据较旧一端的变更，让数据较新的一端重新接管。养成定期查看 /proc/drbd 状态、定期演练故障切换的习惯，才能真正保证这套高可用方案在关键时刻靠得住。