1.背景

因之前研究Aws RDS 的HA设计，了解到了DRDB, 紧接着cloud-native里又见到LINSTOR，所以才有了本文

DRBD 本质上是一种基于软件的、无共享（Shared-nothing）的存储复制解决方案。它通过网络在不同的物理服务器之间镜像块设备（如硬盘、分区、逻辑卷等），被业界形象地称为“网络 RAID-1”。然而，这种简化的类比掩盖了其内部极其复杂的工程实现，包括内核空间的 I/O 拦截、精密的元数据管理、脑裂（Split-brain）检测算法以及对不同网络延迟条件的适应性协议。从架构演进的角度来看，DRBD 已经从早期单一的双节点高可用集群组件，演变为通过 LINSTOR 编排层支持的大规模软件定义存储（SDS）底座，能够无缝集成于 Kubernetes、OpenStack 和 Proxmox VE 等云原生环境。

本文将通过对内核源码机制、协议交互流程及生产环境实践数据的综合分析，揭示 DRBD 如何在保证强一致性（Strong Consistency）的同时，平衡性能与可用性的矛盾，并深入探讨其与 Ceph 等分布式文件系统的本质差异。

2. 背景与技术演进历程

2.1 20世纪90年代末的存储困境

要理解 DRBD 的设计初衷，必须回溯到 20 世纪 90 年代末期的 IT 基础设施环境。彼时，企业级存储的高可用性几乎完全依赖于昂贵的专有硬件解决方案。

昂贵的共享存储：高可用性集群通常需要连接到共享的存储区域网络（SAN）或双控制器磁盘阵列。这些设备不仅采购成本高昂，且往往锁定于特定供应商（Vendor Lock-in），对于许多中小企业或新兴互联网公司而言，构成了巨大的财务壁垒。
单点故障的物理悖论：虽然 RAID 技术解决了磁盘级别的单点故障，但存储阵列本身（背板、控制器、电源）往往成为整个集群的单点故障（SPOF）。如果阵列失效，连接到该存储的所有计算节点都将丢失数据访问能力 1。
距离限制：传统的共享 SCSI 或早期的光纤通道（FC）技术对物理距离有严格限制，难以实现跨机房或跨园区的容灾。

2.2 DRBD 的诞生与设计哲学

针对上述痛点，Philipp Reisner 和 Lars Ellenberg 于 1999 年构思并开始开发 DRBD 3。其核心设计哲学是彻底摒弃对共享硬件的依赖，转向**“无共享架构”（Shared-Nothing Architecture）**。在这一架构下，每个节点使用独立的本地存储设备（即“通用硬件”），通过标准的 TCP/IP 网络将数据实时复制到对端节点。这种设计不仅大幅降低了构建 HA 集群的成本，还消除了共享磁盘带来的锁竞争和物理单点故障风险。

LINBIT 公司随后成立，成为 DRBD 开发的主要商业支持力量，推动了 DRBD 进入 Linux 主线内核（自 Linux 2.6.33 起），确立了其作为 Linux 平台标准存储复制技术的地位 2。

2.3 版本演进：从 HA 组件到云原生存储

DRBD 的技术迭代清晰地反映了 Linux 存储需求的变迁轨迹：

版本阶段	核心特征	架构定位	主要应用场景
DRBD 0.7 - 8.3	双主（Dual Primary）引入，强一致性同步	传统 HA 集群组件	配合 Heartbeat/Corosync 构建双机热备数据库、NFS 服务
DRBD 8.4	性能优化，支持更灵活的同步协议，引入 Proxy	异地容灾解决方案	跨数据中心复制，高带宽低延迟环境优化
DRBD 9.0+	多路复制（32节点），自动提升，Quorum 仲裁	软件定义存储（SDS）	云环境、虚拟化后端、超融合架构（HCI）
LINSTOR 时代	控制平面与数据平面分离，容器化集成	Kubernetes 存储编排	云原生应用的持久化存储卷管理 1

3. DRDB的目标

DRBD 的核心价值在于解决数据在物理节点间的一致性复制与业务连续性问题。这一宏观目标下，包含着多个层面的具体技术挑战：

3.1 跨节点的物理数据冗余

在单机环境中，硬件 RAID 卡或软件 RAID（mdadm）解决了磁盘介质损坏的问题。但在节点级别（整个服务器宕机、主板烧毁、甚至机房断电），本地 RAID 无法提供任何保护。DRBD 通过网络将数据镜像到另一台完全独立的物理服务器，确保即使主节点发生毁灭性物理故障，数据依然在备节点的磁盘上完整存在，且立即可用。这解决了“数据生存性”的问题 6。

3.2 块级别的应用透明性与通用性

不同于应用层复制（如 MySQL Replication）或文件系统层复制（如 GlusterFS），DRBD 工作在内核的通用块层（Generic Block Layer）。

解决的问题：它不需要上层应用进行任何修改。无论是 Ext4、XFS、Btrfs 文件系统，还是 LVM 卷，甚至是直接操作裸设备的数据库（如 Oracle ASM），都可以直接运行在 DRBD 之上。它为所有不支持原生复制的遗留应用（Legacy Applications）提供了通用的 HA 能力。这种“对上层透明”的特性是 DRBD 能够广泛应用于各种场景的关键 3。

3.3 数据一致性与网络延迟的物理权衡

在分布式系统中，CAP 定理（Consistency, Availability, Partition tolerance）指出了数据一致性与可用性之间的权衡。DRBD 的设计核心在于解决不同业务场景下对数据零丢失（RPO=0）与写入性能之间的矛盾。通过提供精细控制的复制协议，DRBD 允许管理员在“绝对一致性”（等待网络确认）和“高性能”（异步发送）之间根据物理网络条件进行选择 8。

3.4 脑裂（Split-Brain）的预防与恢复

在无共享集群中，网络分区可能导致两个节点同时认为自己是主节点并修改数据，从而产生数据分叉。DRBD 必须解决如何检测这种状态、如何通过仲裁（Quorum）防止其发生，以及一旦发生后如何安全合并数据的难题。

4. 架构原理与内核实现机制

DRBD 的技术实现深度依赖于 Linux 内核的模块化设计。深入理解其工作原理，需要剖析其在内核 I/O 栈中的精确位置、BIO（Block I/O）拦截机制、数据平面的流向以及元数据管理策略。

4.1 内核模块与 I/O 栈拦截机制

DRBD 以 Linux 内核模块（drbd.ko）的形式运行，其主要设备编号（Major Number）为 147。在 Linux I/O 栈的层级结构中，DRBD 位于文件系统（File System）之下，物理磁盘驱动（Physical Disk Driver）之上，充当了一个虚拟块设备层。

4.1.1 虚拟设备与 BIO 结构

DRBD 向操作系统呈现一个虚拟的块设备（例如 /dev/drbd0）。当上层的文件系统或应用程序向该设备发出读写请求时，内核会生成 bio 结构体（Block I/O）。

拦截点：DRBD 注册了自己的 make_request_fn（在旧版内核）或利用 submit_bio 机制（在新版内核）来接管发往该虚拟设备的 BIO 请求 10。
克隆与分发：当一个写请求（Write BIO）到达时，DRBD 内核驱动会执行关键的“克隆”操作。它将原始 BIO 数据复制，一份通过本地 I/O 栈提交给底层的后备设备（Backing Device，如 /dev/sda1），另一份则被封装进 DRBD 的网络协议包中，通过 TCP/IP 套接字发送给对端节点 1。

这种处于 I/O 栈底层的设计使得 DRBD 极其灵活，因为它根本不关心存储的具体内容是文件系统的元数据还是数据库的索引，它只关心块（Block）的变动。

4.2 复制协议与数据流控制

DRBD 提供了三种核心复制模式（Protocol A, B, C），这三种模式决定了 BIO 请求何时被视为“完成”，从而定义了系统的一致性级别和性能特征。

4.2.1 协议 C（Protocol C）：同步复制（Synchronous）

这是高可用集群中最常用的模式，也是 DRBD 的默认推荐模式，用于构建强一致性系统。

写入流程：
- 主节点（Primary）接收写入请求。
- 主节点同时向本地磁盘发起写入，并将数据包发送给备节点（Secondary）。
- 备节点接收数据，写入自身磁盘，并向主节点发送确认包（Ack）。
- 主节点只有在收到本地磁盘的完成信号且收到备节点的确认包后，才向应用层返回“写入成功”。
物理意义：这实际上是一个跨网络的“两阶段提交”变体。它确保在任何情况下（包括主节点突然掉电），只要应用收到了写入成功的信号，数据就已经安全地物理存储在两个节点的磁盘上。
性能代价：写入延迟（Latency） = max(本地磁盘延迟, 远程磁盘延迟) + 网络往返时间（RTT）。因此，协议 C 强烈依赖于低延迟网络（如万兆以太网或 InfiniBand），通常仅用于同机房或同园区的短距离复制（距离 < 50km）8。

4.2.2 协议 A（Protocol A）：异步复制（Asynchronous）

写入流程：一旦数据被写入本地磁盘并放入本地 TCP 发送缓冲区（Send Buffer），DRBD 即向应用返回成功，不等待数据真正离开网卡或到达对端。
应用场景：适用于长距离、高延迟的异地容灾（Disaster Recovery）。
风险与局限：如果主节点在数据尚未发送到网络前崩溃，备节点的数据将落后于主节点。如果此时强制备节点接管服务，将导致少量数据丢失（虽然应用认为已写入）。这要求备节点在接管时进行数据回滚或强制同步 8。

4.2.3 协议 B（Protocol B）：半同步复制（Memory Synchronous）

写入流程：数据写入本地磁盘且数据包已到达对端节点（进入对端接收缓冲区）后，即视为完成。它不等待对端实际刷入磁盘。
中间态：提供比协议 A 更高的数据安全性（防止主节点掉电丢失），但无法防止双节点同时掉电导致的数据丢失。这是一种较少使用的中间态协议 9。

4.3 元数据管理与故障恢复机制

DRBD 的健壮性不仅体现在正常复制中，更体现在节点故障后的快速恢复能力上。这依赖于其精密的元数据结构。

4.3.1 位图（Bitmap）与增量同步

DRBD 将磁盘划分为一个个小的同步单元（通常为 4KB），并使用内存中的 Bitmap 来记录每个块的同步状态。

断连处理：如果主备节点断开连接（例如网络故障），主节点会进入“单机模式”继续写入，并将所有发生变更的块在 Bitmap 中标记为“Out-of-sync”（脏位）。
恢复机制：当连接恢复时，DRBD 不需要全盘重新复制（Full Resync），而是交换 Bitmap，仅同步断连期间发生变化的数据块。这极大地缩短了恢复时间（Resync Time），对于 TB 级甚至 PB 级的存储尤为关键 15。

4.3.2 活动日志（Activity Log, AL）

Activity Log 是 DRBD 性能优化与一致性保证的关键机制。

问题背景：如果在写入过程中主节点突然断电，内存中的 Bitmap 可能还没来得及更新到磁盘元数据区。系统重启后，DRBD 无法确知哪些块处于“正在写入但未完成”的状态，传统做法是必须进行全盘校验（Checksum Verify），这可能耗时数小时。
解决方案：AL 是一块位于元数据区的预写环形缓冲区日志。在向数据区写入任何数据之前，DRBD 必须先在 AL 中记录该区域（Extents，通常 4MB 大小）为“Active”。这是一种类似数据库 WAL（Write-Ahead Logging）的机制。
快速恢复：如果主节点崩溃重启，DRBD 只需要重新同步 AL 中记录的那些“活跃”区域，而不是整个磁盘。这使得崩溃后的同步时间从数小时缩短到几秒钟。AL 的大小（extents 数量）是一个可调参数，需要在写入性能（减少元数据更新频率）和恢复速度之间权衡 15。

4.4 脑裂（Split-Brain）与 Quorum 仲裁

脑裂是高可用集群的噩梦。当心跳网络中断，两个节点都认为对方已死，并分别提升为主节点（Primary）接收写入，导致数据分叉。

4.4.1 传统的各种策略

早期的 DRBD 版本依赖于管理员手动干预或简单的策略（如“丢弃较少变更的节点数据”）。这在生产环境中风险极高，可能导致数据逻辑损坏。

4.4.2 DRBD 9 的 Quorum 机制

DRBD 9 引入了 Quorum（法定人数）机制，这是现代分布式系统的一致性标准。

原理：只有当一个节点能与集群中“多数派”（Majority）节点通信时，它才被允许成为 Primary 并进行写入。
Tiebreaker：在双节点集群中（1 vs 1），无法形成多数派。因此，DRBD 引入了无盘仲裁节点（Diskless Tiebreaker Node）。这是一个不存储数据的轻量级 DRBD 实例，仅用于投票。
隔离机制：如果网络中断，拥有仲裁票数的节点侧继续服务，而被隔离的少数派节点会自动降级为 Secondary 或挂起 I/O（Suspend I/O），从而在物理层面防止了数据分叉的产生。配合 Pacemaker 的 Fencing（隔离）机制，可以进一步通过关闭端口或重启节点来确保安全 15。

5. 软件定义存储生态：LINSTOR 的崛起

随着容器化和云原生的普及，传统的手动编辑 /etc/drbd.conf 文件来管理存储卷的方式已无法适应数千个动态卷的需求。LINBIT 开发了 LINSTOR，作为 DRBD 的控制平面和编排器，彻底改变了 DRBD 的使用方式，使其成为真正的软件定义存储（SDS）。

5.1 LINSTOR 架构解析

LINSTOR 采用了经典的 Controller-Satellite 架构，实现了控制平面与数据平面的解耦：

LINSTOR Controller：集群的“大脑”，负责存储配置、调度决策（例如根据空闲空间和负载情况决定将卷创建在哪些节点上）、管理卷的生命周期。它维护着集群状态的数据库，并对外提供 REST API 和 CLI 接口。
LINSTOR Satellite：运行在每个存储节点上的“代理人”。它接收 Controller 的指令，直接调用底层的 drbdadm、lvm、zfs 或 nvme 命令来创建物理卷和配置 DRBD 资源。值得注意的是，数据路径（Data Path）并不经过 Satellite，而是直接通过内核态的 DRBD 模块传输，因此控制平面的故障不会影响数据读写 5。

5.2 Kubernetes 与云原生集成

LINSTOR 通过 CSI（Container Storage Interface）驱动实现了与 Kubernetes 的深度集成。

自动化配置：当 K8s 用户创建一个 PersistentVolumeClaim (PVC) 时，LINSTOR CSI 插件会拦截请求，通知 Controller。Controller 自动在合适的节点上划分 LVM 卷，配置 DRBD 复制，并将生成的设备挂载到 Pod 所在的节点。
数据本地性（Data Locality）：LINSTOR 能够智能地将 Pod 调度到有数据副本的节点上，从而实现本地读取性能。如果 Pod 漂移到了没有数据的节点，LINSTOR 会自动创建一个“无盘客户端（Diskless Client）”，通过网络访问数据，或者在后台自动迁移数据副本到新节点，实现“数据跟随应用” 22。

6. 典型应用场景与实践案例

DRBD 的通用性和灵活性使其应用场景极其广泛，覆盖了从传统 IT 到前沿云原生的各个领域。

6.1 传统高可用（HA）数据库

这是 DRBD 最经典、最成熟的应用场景。对于 MySQL、PostgreSQL、Oracle 等传统关系型数据库，DRBD 提供了一种不依赖数据库自身复制机制的物理层 HA 方案。

架构优势：相比于 MySQL 的半同步复制，DRBD 保证了文件系统级别的完全一致性。即使数据库引擎崩坏，底层数据块依然同步。配合 Pacemaker/Corosync 集群管理工具，可以实现自动故障检测、虚拟 IP（VIP）漂移和数据库进程重启。
实践：在主节点故障时，Pacemaker 检测到心跳丢失，通过 STONITH 设备（如 IPMI）强制关闭主节点电源（防止脑裂），然后在备节点上提升 DRBD 为 Primary，挂载文件系统，并启动 MySQL 服务。整个过程通常在 30 秒至 1 分钟内完成，实现 RPO=0，RTO<1min 25。

6.2 虚拟化与超融合架构（HCI）

在 OpenStack 或 Proxmox VE 环境中，DRBD 被用作虚拟机镜像（VM Images）的后端存储。

Proxmox 集成：Proxmox 原生支持 LINSTOR/DRBD。用户可以在两台或多台服务器上构建共享存储池。当虚拟机进行实时迁移（Live Migration）时，由于两端都能访问到 DRBD 设备（一端本地访问，一端通过网络），迁移过程极其平滑且无需数据拷贝。这使得中小企业无需购买昂贵的 SAN 存储即可搭建高可用虚拟化集群 28。

6.3 Kubernetes 有状态应用

对于运行在 Kubernetes 上的有状态应用（StatefulSets），LINSTOR + DRBD 提供了一种高性能的块存储方案。

性能敏感型应用：相比于基于文件系统的存储（如 NFS）或路径复杂的分布式存储（如 Ceph RBD），DRBD 在 I/O 路径上更短，内核开销极低。基准测试显示，在 NVMe 环境下，DRBD 的 IOPS 和延迟表现通常优于 Ceph，特别适合 Redis、MongoDB、Cassandra 等对 I/O 性能敏感的容器化数据库 30。

6.4 跨数据中心异地容灾

利用 DRBD Proxy（LINBIT 的专有商业插件）和协议 A，企业可以实现跨城市甚至跨大洲的数据异地备份。

机制：DRBD Proxy 作为一个用户空间进程，接管内核的数据流。它利用大内存缓冲和数据压缩算法（如 LZ4, zstd），优化了在高延迟、低带宽链路上的复制效率。即使网络中断数小时，Proxy 的缓冲也能暂存数据，待网络恢复后自动追平，确保生产中心不受网络波动影响 4。

7. 性能分析与竞品对比

7.1 性能特性与调优

DRBD 的性能并非固定不变，而是高度依赖于硬件环境和配置调优。

吞吐量（Throughput）：理论上，DRBD 的吞吐量受限于本地磁盘写入速度和网络带宽的最小值。在现代全闪存（NVMe）和 25GbE/100GbE 网络环境下，DRBD 内核模块本身引入的 CPU 开销极低（通常小于 3%）。通过调整 max-buffers 和 max-epoch-size 等参数，可以充分填满网络管道 7。
延迟（Latency）：这是同步复制（协议 C）的主要关注点。每次写入都需要经过网络往返。在同机房网络下（RTT < 0.2ms），写入延迟增加微乎其微。但在高性能 NVMe 场景下，内核 TCP/IP 协议栈的上下文切换可能成为瓶颈。为此，LINBIT 正在积极开发基于 RDMA（InfiniBand/RoCE）的传输层，以实现零拷贝和内核旁路传输，进一步降低延迟 13。

7.2 DRBD 与 Ceph 的深度对比

DRBD 和 Ceph 是 Linux 生态中最主要的两个开源存储方案，但它们的设计理念截然不同，适用于不同的维度。

特性	DRBD (w/ LINSTOR)	Ceph (RBD)
基础架构	类似于网络 RAID-1（全镜像）	基于对象的分布式存储（CRUSH 算法）
数据分布	全副本模式，通常 2-3 个副本	数据切片（Striping）并分散到整个集群
扩展性	适合中小规模集群（2-32 节点），单卷扩展性受限	极强，可线性扩展至数千节点，PB/EB 级容量
IO 路径	极短。内核模块直接处理，类似本地磁盘	较长。涉及客户端计算 CRUSH、连接 OSD、OSD 内部处理等
性能表现	极高。适合高 IOPS、低延迟应用（数据库）	中等。适合大吞吐量场景，单流延迟较高
资源消耗	低。内核态运行，CPU/内存占用极少	高。OSD 进程消耗大量 CPU 和内存
修复速度	极快（基于 Bitmap 的增量同步）	较慢（涉及全集群的数据再平衡 Backfill）
适用场景	数据库、高性能块存储、超融合架构（HCI）	大规模对象存储、云平台通用后端、冷数据归档

核心洞察：DRBD 在小规模、高性能需求的场景下（如仅有 3-10 个节点的超融合 K8s 集群）通常优于 Ceph。Ceph 虽然扩展性无敌，但在小集群中显得过于沉重且维护复杂，且其写入延迟（Write Latency）通常高于 DRBD。反之，如果需要构建 PB 级的数据湖，Ceph 则是更好的选择 15。

8. 局限性与技术边界 (Limits)

尽管 DRBD 在特定领域表现卓越，但它并非万能药。作为架构师，必须清晰认识到其技术边界和局限性。

8.1 扩展性限制（Scalability Limits）

网状连接的复杂性：DRBD 9 虽然支持多达 32 个节点，但它是基于全网状（Full Mesh）或部分网状连接的。每增加一个副本，主节点就需要多建立一条 TCP 连接。对于成千上万个卷的集群，这种连接数的增长是不可忽视的开销。
单卷性能瓶颈：DRBD 的写入性能受限于集群中最慢的那个副本磁盘和网络链路。不像 Ceph 可以通过增加 OSD 数量来线性增加单个大卷的并发写入带宽，DRBD 的单卷吞吐量很难超过单机硬件的极限 36。

8.2 文件系统的排他性限制

DRBD 提供的是块设备，这带来了文件系统层面的限制。

非集群文件系统不可并发读写：初学者最常见的错误是在主备两个节点上同时挂载标准的 Ext4 或 XFS 文件系统并尝试写入。这会瞬间导致文件系统元数据损坏，数据永久丢失。
解决方案：DRBD 在“主-主”（Primary-Primary）模式下，必须配合集群文件系统（如 OCFS2, GFS2）使用，这引入了分布式锁管理器（DLM），大大增加了架构的复杂性和运维难度。因此，大多数生产环境依然推荐使用主备（Active-Passive）模式 3。

8.3 物理延迟的限制

同步复制（协议 C）受到光速的物理限制。如果主备节点距离超过 50 公里，网络 RTT 将显著增加写入延迟（通常超过 1-2ms），这会导致数据库等对延迟敏感的应用 TPS 急剧下降。这在物理上限制了强一致性高可用架构的地理覆盖范围 13。

8.4 纠删码（Erasure Coding）支持的缺失

目前 DRBD 主要依赖全副本镜像（Replication）。相比于纠删码（Erasure Coding, EC），全副本极其浪费存储空间。

成本对比：要实现 3 副本的可靠性，DRBD 需要 300% 的存储空间（利用率 33%）。而 Ceph 使用纠删码（如 4+2 方案）可以达到 66% 的利用率。
现状：虽然 LINBIT 路线图中有 EC 的计划，且已有实验性支持，但目前生产环境的主流依然是全镜像。这使得在海量数据存储场景下，DRBD 的单位存储成本显著高于支持 EC 的分布式存储系统 37。

8.5 管理复杂度

如果不使用 LINSTOR，手动管理 DRBD 9 的多节点配置极其复杂。.res 文件的编写、IP 地址的分配、端口的管理、脑裂后的手动 drbdadm connect --discard-my-data 操作，都对运维人员的技能提出了极高要求。

9. 结论

DRBD 作为一项久经考验的技术，通过在 Linux 内核层实现高效的块级复制，成功解决了通用硬件上的数据高可用这一核心问题。它的演进历程——从简单的双机 HA 组件到由 LINSTOR 驱动的云原生存储平台——展示了其强大的生命力和适应性。

对于需要极低延迟、高 IOPS 数据库存储、或在中小规模（3-20 节点）超融合架构中寻求轻量级、高性能存储方案的用户而言，DRBD（配合 LINSTOR）往往是优于 Ceph 的最佳选择。然而，对于 PB 级海量数据归档、对象存储需求或需要跨越广域网的超大规模分布式存储，用户则需审慎评估其扩展性限制和副本存储成本。

总体而言，DRBD 不仅是 Linux 高可用生态的基石，更是现代私有云、Kubernetes 持久化存储和边缘计算场景中不可或缺的高性能存储构建模块。

深度技术附录

A. 关键配置参数解析

参数类别	参数名称	解释与调优建议
网络	protocol	A/B/C。绝大多数 HA 场景选 C；异地容灾选 A。
网络	max-buffers	限制 DRBD 分配给写请求的最大缓冲区数量。在 10GbE 网络下，建议从默认的 2048 增加到 8000-16000 以提升吞吐量。
网络	sndbuf-size	TCP 发送缓冲区大小。对于高带宽延迟乘积（BDP）的网络，需设置为 2MiB 或更高以填满管道 7。
磁盘	disk-flushes	控制 DRBD 是否在该设备支持的情况下使用磁盘刷写（Disk Flushes/Barriers）。为了数据安全默认为 yes，但在带电池保护的 RAID 卡上可设为 no 以提升性能。
磁盘	al-extents	活动日志的区域数量。默认 1237。增加此值（如 6433）可减少元数据更新频率，提升写入性能，但会线性增加崩溃后的同步时间。需根据业务对恢复时间的要求进行权衡 17。
处理程序	fence-peer	定义发生脑裂时的隔离脚本。配合 Pacemaker 使用时，通常设置为 crm-fence-peer.sh。

B. 常见管理命令速查

任务	命令示例	说明
查看状态	drbdadm status	显示资源的角色（Primary/Secondary）、连接状态（Connected/StandAlone）和同步进度。
初次启动	drbdadm up <res>	加载配置，附加磁盘，建立网络连接。
提升为主	drbdadm primary <res>	将资源角色提升为主，允许挂载和写入。
脑裂恢复	drbdadm disconnect <res> drbdadm connect --discard-my-data <res>	在数据不重要或确认过时的节点上执行，放弃本地数据，重新同步主节点数据。
LINSTOR	linstor resource-group spawn <rg> <size>	通过 LINSTOR 控制器在集群中自动创建一个指定大小的新卷。

Works cited

DRBD - LINBIT, accessed on November 28, 2025, [https://linbit.com/drbd/]
Data Replication Across Geo Clusters via DRBD | SUSE Documentation, accessed on November 28, 2025, [https://documentation.suse.com/sbp/high-availability/pdf/SBP-DRBD_en.pdf]
DRBD - Wikipedia, accessed on November 28, 2025, [https://en.wikipedia.org/wiki/DRBD]
What is DRBD? - LINBIT, accessed on November 28, 2025, [https://linbit.com/faq-questions/what-is-drbd/]
LINSTOR - LINBIT, accessed on November 28, 2025, [https://linbit.com/linstor/]
Linux- HOST HA / DRBD overview - IBM, accessed on November 28, 2025, [https://www.ibm.com/docs/en/netezza-appliance/1.0.0?topic=system-linux-host-ha-drbd-overview]
DRBD 9.0 en - LINBIT, accessed on November 28, 2025, [https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/]
DRBD 8.4 en - LINBIT, accessed on November 28, 2025, [https://linbit.com/drbd-user-guide/users-guide-drbd-8-4/]
Introduction to DRBD 8.x - Globo.Tech, accessed on November 28, 2025, [https://www.globo.tech/learning-center/introduction-to-drbd/]
searcing for the function calls submit_bio - linux - Stack Overflow, accessed on November 28, 2025, [https://stackoverflow.com/questions/18559393/searcing-for-the-function-calls-submit-bio]
Linux kernel module for block device redirect freezes in make_request on submit_bio/submit_bio_wait - Reddit, accessed on November 28, 2025, [https://www.reddit.com/r/kernel/comments/18ohfhb/linux_kernel_module_for_block_device_redirect/]
A block layer introduction part 1: the bio layer - LWN.net, accessed on November 28, 2025, [https://lwn.net/Articles/736534/]
The Impact of Network Latency on Write Performance When Using DRBD - LINBIT, accessed on November 28, 2025, [https://linbit.com/blog/the-impact-of-network-latency-on-write-performance-when-using-drbd/]
replication - DRBD - Protocol A slower than B and C - Server Fault, accessed on November 28, 2025, [https://serverfault.com/questions/916148/drbd-protocol-a-slower-than-b-and-c]
DRBD Deep Dive. When we talk about building cloud… | by Tech Internals Conf - Medium, accessed on November 28, 2025, [https://medium.com/@TechInternals/drbd-deep-dive-fd1ec54130dd]
An explanation of DRBD Protocol C - Stack Overflow, accessed on November 28, 2025, [https://stackoverflow.com/questions/45998076/an-explanation-of-drbd-protocol-c]
drbdsetup - Configure the DRBD kernel module - Ubuntu Manpage, accessed on November 28, 2025, [https://manpages.ubuntu.com/manpages/focal//man8/drbdsetup-9.0.8.html]
Using the DRBD Quorum Feature as an Alternative to Fencing in a Pacemaker Cluster, accessed on November 28, 2025, [https://linbit.com/blog/using-the-drbd-quorum-feature-as-an-alternative-to-fencing-in-a-pacemaker-cluster/]
A New Solution For An Old Problem: DRBD Quorum Solves Split-Brain - LINBIT, accessed on November 28, 2025, [https://linbit.com/blog/a-new-solution-for-an-old-problem-drbd-quorum-solves-split-brain/]
linstor - Incus documentation - Linux Containers, accessed on November 28, 2025, [https://linuxcontainers.org/incus/docs/main/reference/storage_linstor/]
LINBIT/linstor-server: High Performance Software-Defined Block Storage for container, cloud and virtualisation. Fully integrated with Docker, Kubernetes, Openstack, Proxmox etc. - GitHub, accessed on November 28, 2025, [https://github.com/LINBIT/linstor-server]
Kubernetes at the edge using LINBIT SDS for persistent storage | CNCF, accessed on November 28, 2025, [https://www.cncf.io/blog/2024/11/28/kubernetes-at-the-edge-using-linbit-sds-for-persistent-storage/]
Creating ReadWriteMany Persistent Volumes in Kubernetes by using LINSTOR - LINBIT, accessed on November 28, 2025, [https://linbit.com/blog/creating-readwritemany-persistent-volumes-in-kubernetes-by-using-linstor/]
Using LINSTOR in Kubernetes to Create & Manage Persistent Storage for KubeVirt VMs, accessed on November 28, 2025, [https://linbit.com/blog/using-linstor-in-kubernetes-to-create-manage-persistent-storage-for-kubevirt-vms/]
Deploying a highly available MySQL 5.6 cluster with DRBD on Compute Engine, accessed on November 28, 2025, [https://docs.cloud.google.com/compute/docs/instances/mysql/deploying-highly-available-mysql-cluster-with-drbd-on-compute-engine]
Active-Passive Cluster for Near HA Using Pacemaker, DRBD, Corosync and MySQL, accessed on November 28, 2025, [https://houseofbrick.com/blog/active-passive-cluster-for-near-ha-using-pacemaker-drbd-corosync-and-mysql/]
An Overview of MySQL Database High Availability - Severalnines, accessed on November 28, 2025, [https://severalnines.com/blog/overview-mysql-database-high-availability/]
2 Node Cluster HA DRBD or CEPH? - Proxmox Support Forum, accessed on November 28, 2025, [https://forum.proxmox.com/threads/2-node-cluster-ha-drbd-or-ceph.102938/]
DRBD or Ceph Storage on a Two Node Proxmox HA Cluster?, accessed on November 28, 2025, [https://forum.proxmox.com/threads/drbd-or-ceph-storage-on-a-two-node-proxmox-ha-cluster.18155/]
Use-case for DRBD? : r/kubernetes - Reddit, accessed on November 28, 2025, [https://www.reddit.com/r/kubernetes/comments/1o7zbml/usecase_for_drbd/]
Comparing LINSTOR & Ceph Storage Clusters - LINBIT, accessed on November 28, 2025, [https://linbit.com/blog/how-does-linstor-compare-to-ceph/]
Linstor, Ceph and Vitastor performance on Proxmox 8 - joeplaa.com Blog, accessed on November 28, 2025, [https://blog.joeplaa.com/linstor-ceph-and-vitastor-performance-on-proxmox-8/]
DRBD-reactor over Pacemaker - LINBIT, accessed on November 28, 2025, [https://linbit.com/blog/drbd-reactor-over-pacemaker/]
Independent Performance Testing of DRBD by E4 - LINBIT, accessed on November 28, 2025, [https://linbit.com/blog/independent-performance-testing-of-drbd-by-e4/]
[DRBD-user] 300% latency difference between protocol A and B with NVMe, accessed on November 28, 2025, [https://lists.linbit.com/pipermail/drbd-user/2020-November/025747.html]
DRBD's Hardware & Environment Requirements - LINBIT, accessed on November 28, 2025, [https://linbit.com/blog/drbd-hardware-environment-requirements/]
DRBD erasure coding explained (2019) - YouTube, accessed on November 28, 2025, [https://www.youtube.com/watch?v=mFdzrsitu8A]
[ClusterLabs] Removing DRBD w/out Data Loss?, accessed on November 28, 2025, [https://lists.clusterlabs.org/pipermail/users/2020-September/027661.html]