DRBD 网络版 RAID 1 详解
关于 DRBD 作为“网络 RAID 1”架构的声明性分析报告
1.0 DRBD (Distributed Replicated Block Device) 作为“网络 RAID 1”的架构
1.1 定义“Shared-Nothing”（无共享）复制模型
DRBD (Distributed Replicated Block Device) 是一种为 Linux 平台设计的软件定义的存储解决方案。其核心架构基于“shared-nothing”（无共享）原则。在此模型中，高可用性 (HA) 集群中的每个节点都拥有其本地、独立的存储子系统（例如本地磁盘或 SAN LUN）。节点之间不存在对同一物理存储的并发访问。
DRBD 的功能是在这些独立的存储子系统之上创建一个逻辑的、复制的块设备。对于操作系统和上层应用（如文件系统或数据库），这个逻辑设备（例如 /dev/drbd0）表现为单个本地块设备。然而，在后台，DRBD 驱动程序会拦截所有写入此设备的 I/O 请求，并通过 TCP/IP 网络将其复制到一个或多个对等节点上的相应存储中。
1.2 “网络 RAID 1”类比在技术文档中的验证
“网络 RAID 1”这一表述常被用作 DRBD 功能的高度概括。这一类比在相关的技术文档中得到了证实。例如，与 Linux 内核相关的文档明确指出：“简单来说，您可以将其视为一个网络 RAID 1” 1。
此后，这一术语在各种技术词汇表中被采纳和标准化。例如，SUSE Linux Enterprise High Availability 扩展的文档在定义相关术语时，也明确将 DRBD 描述为“网络 RAID-1” 3。
对这个类比的解构如下：
RAID 1：此部分描述了该技术的核心功能，即镜像 (Mirroring)。与传统的硬件 RAID 1 控制器在同一系统内将数据写入两块本地磁盘类似，DRBD 将数据写入两个网络连接的节点。
网络：此部分描述了复制的传输介质。与本地系统总线不同，DRBD 使用标准的 TCP/IP 网络作为其数据复制的通道。
1.3 类比的局限性与新故障域的引入
虽然“网络 RAID 1”是一个在功能上十分贴切的类比，但技术文档中使用的“简单来说”(simplistically) 1 一词也暗示了其局限性。这种简化隐藏了因架构扩展而引入的根本性复杂性。
传统的、本地的硬件 RAID 1 控制器运行在一个单一的、确定性的故障域内（即服务器机箱）。其面临的故障模式（例如磁盘故障、控制器故障）是局部的。相比之下，DRBD 通过将镜像扩展到网络上，引入了一组全新的、非确定性的分布式系统故障模式。
其中最关键且最具破坏性的故障模式是网络分区 (Network Partition)。在这种情况下，集群节点本身并未崩溃，但它们之间用于 DRBD 复制和集群心跳的通信链路被切断。每个节点都可能保持活动状态，但无法感知对等节点的状态。
这种本地 RAID 1 控制器永远不会遇到的情况，正是“网络 RAID 1”架构的独特风险。它直接导致了“脑裂”(Split-Brain) 场景的可能性，即两个节点都错误地认为自己是唯一活动的主节点，并开始接受独立的写入操作，从而导致数据分歧和灾难性的数据损坏。
因此，“网络 RAID 1”这个类比在定义其功能时是准确的，但其局限性（即网络分区这一新故障域）恰恰是必须部署额外的高可用性组件（如 fencing 和集群管理器）的根本原因。
2.0 架构的分离：内核级驱动与用户态管理
2.1 内核基础：机制而非策略
DRBD 的核心功能——即拦截、复制和管理块 I/O——是作为 Linux 内核驱动程序实现的。技术文档在讨论相关组件（如连接跟踪系统）时，会引用 DRBD 的“in-kernel”（内核内置）状态 3。
这种内核级实现是 DRBD 高性能和透明性的关键来源。当一个应用程序向 DRBD 设备（例如 /dev/drbd0）写入数据时，它并不知道其 I/O 正在被同步复制到远程节点。内核驱动程序在 I/O 栈的底层处理了所有复杂的复制逻辑。这个内核驱动是复制的引擎，它提供了实现复制的机制。
2.2 用户态控制平面：drbd-utils 的角色
尽管内核驱动提供了复制的能力，但它本身在没有配置和指令的情况下是惰性的。这就是用户态实用工具（User-Space Utilities）发挥作用的地方。在 Debian 及其衍生发行版中，drbd-utils 软件包被明确定义为：“用于 Linux 的 TCP/IP RAID 1（用户实用程序）” 6。
这证实了一个关键的架构点：内核中包含的驱动（机制）必须由 drbd-utils 软件包提供的用户态工具（策略与控制）来管理。drbd-utils 提供了 drbdadm 等命令行工具，它们是 DRBD 的控制平面，负责执行以下关键功能：
元数据创建：在底层物理块设备上初始化 DRBD 元数据，定义复制关系。
资源配置：解析配置文件（通常是 .res 文件），定义对等节点、网络参数、磁盘设备和复制协议。
生命周期管理：控制 DRBD 资源的启动和停止，包括 attach（附加到底层设备）、detach（分离）、connect（连接对等方）和 disconnect（断开连接）。
状态转换：手动或（在集群管理器协调下）自动在 Primary（主）和 Secondary（从）角色之间切换。只有 Primary 节点才能挂载文件系统并接受读写 I/O。
监控与同步：查询复制状态、同步进度和连接健康状况（例如，通过 drbdadm status）。
2.3 UNIX 哲学及其架构后果
这种内核空间与用户空间的分离是深思熟虑的设计选择，完全符合经典的 UNIX 和 Linux 哲学：在内核中提供机制，在用户空间中提供策略。
因此，“DRBD 是 Debian 内核提供的功能”这一理解，从技术上讲是正确的，因为复制机制（驱动程序）随内核一起分发。然而，这在实践中是不完整的。没有 drbd-utils 提供的策略和控制工具，该内核功能无法被激活、配置或使用。
这种分离并非缺陷，而是 DRBD 能够作为灵活组件集成到更大事物中的关键促成因素。正因为 DRBD 的状态（尤其是 Primary/Secondary 角色）可以从用户空间进行控制，所以它才能被一个更高层次的自动化流程所编排。
这就直接引出了对集群资源管理器 (CRM)（如 Pacemaker）的需求。Pacemaker 通过其 DRBD 资源代理（Resource Agent），调用 drbd-utils 提供的 drbdadm 命令，在发生故障切换时自动执行状态转换（例如，将幸存节点 promote 为 Primary）。如果 DRBD 的控制逻辑被硬编码在内核中，这种灵活的、策略驱动的集群集成将是不可能的。
3.0 可靠性关键分析（I）：数据一致性 (RPO)
3.1 复制协议：同步与异步的定义
DRBD 提供了多种复制协议，允许管理员根据其特定的延迟和一致性要求进行权衡。LINBIT 的技术文档 8 定义了两种主要的复制模式：
异步复制（Protocol A）：在此模式下，当数据本地写入完成后，应用程序的写操作即被通知完成。数据复制到对等节点的操作在后台进行。这种模式适用于高延迟、长距离的广域网 (WAN) 复制，例如跨数据中心的灾难恢复 (DR) 场景 9。它的优势是低的应用写延迟，但代价是恢复点目标 (RPO) 大于零。如果主节点在数据完全传输到远程节点之前发生故障，尚未传输的数据将会丢失。
同步复制（Protocol C）：在此模式下，写操作必须在所有（连接的）主机上都完成（即数据已写入本地磁盘和远程对等节点的磁盘）之后，应用程序才会收到写完成的确认 8。
3.2 Protocol C：实现 RPO≈0 的机制
对于要求高可靠性和零数据丢失的高可用性 (HA) 集群，Protocol C 是标准配置。选择 Protocol C 是实现 RPO≈0（恢复点目标约等于零）的技术机制。
其工作流程如下：
应用程序在 Primary 节点上发出一个写 I/O 请求。
DRBD 内核驱动程序拦截该请求。
DRBD 将数据写入本地磁盘。
同时，DRBD 通过网络将数据块发送到 Secondary 节点。
Secondary 节点接收数据并将其写入其本地磁盘。
Secondary 节点向 Primary 节点发送一个“写入完成”的确认。
只有在收到 Secondary 节点的确认并且本地写入也已完成后，Primary 节点的 DRBD 驱动程序才会向应用程序报告“写入完成”。
这种跨集群的原子写操作确保了在 Primary 节点发生灾难性故障（例如，电源故障、内核崩溃）的瞬间，Secondary 节点保证拥有一个与 Primary 节点完全一致的数据副本，直至最后一个被应用程序确认的写操作。这就是 RPO=0 的定义。
3.3 同步复制的固有权衡
Protocol C 提供的零数据丢失保证并非没有代价。它代表了一个基础的架构权衡：用性能换取一致性。
通过选择 Protocol C 8，系统管理员有意地将网络延迟和远程磁盘 I/O 延迟注入到了应用程序的写 I/O 路径中。一个写操作的总延迟预算现在变为：
$应用写延迟 = 本地磁盘 I/O 延迟 + 网络往返时间 (RTT) + 远程磁盘 I/O 延迟$
这意味着应用程序的写性能与其复制网络的性能被直接耦合。任何网络抖动、拥塞或远程磁盘的性能瓶颈，都会立即且直接地表现为应用程序性能的下降（即高 I/O-wait）。
这就是为什么 Protocol C 绝大多数被用于低延迟、高带宽的专用网络中（例如，同一数据中心或同一可用区内的背靠背连接）。在延迟不可避免地很高的跨数据中心链路上 9，Protocol C 会导致应用程序性能严重下降，使其变得不切实际，此时必须使用 Protocol A 并接受 RPO>0 的事实。
4.0 可靠性关键分析（II）：脑裂预防与 Fencing
4.1 定义脑裂 (Split-Brain) 场景
如前所述，“网络 RAID 1”架构面临的最大威胁是网络分区，这会导致“脑裂”。IBM 的技术文档在讨论 DRBD 时明确指出了这种错误状态：“当两个 IBM Netezza 主机上的数据镜像因同步禁用期间的独立更改而不同时，就会发生脑裂” 10。
脑裂是一个灾难性的数据完整性故障。其发生级联如下：
集群由 ha1 (Primary) 和 ha2 (Secondary) 组成，使用 Protocol C 同步。
ha1 和 ha2 之间的复制网络发生故障（例如，交换机故障或心跳线缆断开）。
两个节点都保持“存活”状态。
ha2 节点（通过 Heartbeat 或 Corosync）检测到与 ha1 的通信丢失。由于无法区分是 ha1 崩溃还是网络分区，一个配置不当的集群管理器可能会错误地假定 ha1 已经失败。
集群管理器触发故障切换，将 ha2 提升 (promote) 为新的 Primary。
此时，ha1 和 ha2 都处于 Primary 角色。它们都认为自己是集群的唯一主控，并且都开始接受新的、独立的写入请求。
数据集合在两个节点上开始向不同的方向演进，导致数据分歧。当网络最终恢复时，DRBD 会检测到这种不一致性，但无法自动合并两个冲突的数据历史。
4.2 Fencing (STONITH) 的绝对必要性
Fencing（隔离）是防止脑裂发生的唯一可靠机制。Fencing，也称为 STONITH（“Shoot The Other Node In The Head”的缩写），是一种确定性地将一个节点从集群中移除的能力 11。
ClusterLabs（Pacemaker 项目的维护者）的官方文档以最强烈的措辞强调了 Fencing 的必要性：
“为什么 Fencing 是必要的？Fencing 保护您的数据免受……‘脑裂’故障场景的影响” 13。
“如果没有 Fencing，集群无法从某些故障条件（例如无响应的节点）中安全恢复” 12。
“IO Fencing/STONITH 是促成这一目标 [数据完整性] 的主要组成部分” 14。
Fencing 的目标是确保在任何时候，集群中绝对只有一个节点可以访问和写入数据。这通常通过两种方式实现：
电源 Fencing：通过一个智能电源切换单元 (PDU) 或带外管理控制器（如 iDRAC, iLO, IMM），幸存节点可以向无响应的节点发送一个硬性的“断电”或“重启”命令 11。
Fabric Fencing：通过断开该节点访问资源所需的能力（例如，在交换机上禁用其网络端口或光纤通道端口）11。
4.3 Fencing 作为故障模式的转换机制
“非常可靠”这一结论的成立，其核心支柱就是 Fencing。Fencing 是使分布式系统（如 DRBD 集群）能够安全运行的核心机制。
其背后的逻辑是故障模式的转换：
网络分区是一种非确定性的故障。幸存节点（例如 ha2）面对的是一个“未知”状态——它不知道 ha1 是崩溃了，还是仅仅在网络上无法访问。
任何分布式系统都不能基于“未知”状态做出安全的决策。如果 ha2 猜测 ha1 已经崩溃并接管，而 ha1 实际上仍在运行，脑裂就会发生。
Fencing 是一种将非确定性的“未知”状态转换为确定性的“崩溃”状态的强制行为。
在 Pacemaker 管理的集群中，故障切换逻辑被严格执行：ha2 在被提升为 Primary 之前，必须首先成功执行对 ha1 的 Fencing（STONITH）操作。ha2 必须从 Fencing 设备（例如 PDU）那里收到一个明确的、成功的确认（“ha1 现已断电”）。
只有在 Fencing 确认之后，ha2 才能安全地提升为 Primary，因为它现在确定 ha1 不可能再进行任何 I/O 操作。
因此，DRBD 集群的可靠性不是通过防止节点故障来实现的，而是通过强制执行一个受控的、确定性的故障（STONITH 射击）来防止一个不受控的、灾难性的数据完整性故障（脑裂）。
4.4 脑裂的解决 vs. 预防（Quorum 与策略）
Fencing 是最强大的预防机制。此外，还存在其他预防和解决（即事后恢复）机制。
DRBD Quorum：在具有两个以上节点的拓扑中（或使用磁盘作为仲裁设备的双节点），DRBD 可以配置为使用 Quorum 机制。一个节点只有在能够与大多数集群成员（或仲裁设备）通信时，才能保持或提升为 Primary 角色。如果发生网络分区，任何无法达到 Quorum 的分区都会自动将其 DRBD 资源降级为 Secondary，从而防止脑裂。这是一种有效的、不依赖于 STONITH 的预防机制。
自动解决策略：在没有 Fencing 或 Quorum 的情况下，如果脑裂已经发生，DRBD 提供了多种自动解决策略。这些策略必须由专家预先配置，因为它们本质上是在自动选择要丢弃哪些数据。
Microsoft 为在 Azure 上运行的高可用性 NFS 提供的技术文档 15 展示了一个具体的 DRBD 配置，该配置定义了这些复杂的脑裂解决策略：
net {
after-sb-0pri discard-younger-primary;
after-sb-1pri discard-secondary;
after-sb-2pri call-pri-lost-after-sb;
...
}
handlers {
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
pri-lost-after-sb "...; reboot -f";
...
}
此配置 15 清楚地表明：
管理员必须预先决定在不同脑裂场景下（0个 Primary，1个 Primary，或2个 Secondary）采取哪种数据丢弃策略。
例如，discard-younger-primary 意味着当两个 Primary 节点重新连接时，系统将自动丢弃那个较晚提升为 Primary 的节点在此期间所做的所有数据更改。
在其他情况下，策略可能是调用一个脚本来发送通知（notify-split-brain.sh），或者在极端情况下，强制重启（reboot -f）。
这种配置的复杂性，以及不同技术供应商之间的哲学差异，突显了“可靠性”的配置依赖性。Microsoft 的文档 15 提供了复杂的自动化恢复路径，这可能优先考虑服务可用性 (RTO)。相比之下，IBM 在其 Netezza 实施中的文档 10 采取了相反的方法：“DRBD 包含自动纠正机制，但 Netezza 实施禁用了它们。需要人工干预以确保数据完整性。” 这种方法优先考虑一致性和数据安全，而不是自动恢复。
4.5 表：DRBD 脑裂自动解决策略（基于
15
为了提供在技术文档中发现的具体证据，下表分析了 Microsoft HA NFS 解决方案 15 中引用的关键脑裂解决策略：
5.0 实现自动故障切换：编排与服务可用性 (RTO)
5.1 超越复制：集群资源管理器 (CRM) 的角色
DRBD 本身只提供数据块复制。它确保了数据在节点间的一致性（RPO）。然而，DRBD 自身不包含任何用于监控服务健康或执行自动故障切换的逻辑。
如果一个运行 DRBD Primary 角色的节点发生故障，DRBD 的默认行为是“安全但停机”。Secondary 节点将保持 Secondary 角色，数据是安全的、一致的，但服务是不可用的。
实现“自动接管”（即最小化停机时间，或称恢复时间目标 RTO）是集群资源管理器 (CRM)（如 Pacemaker）或其前身 (Heartbeat) 的职责。
在所有审查的技术文档中，DRBD 总是被描述为完整 HA 解决方案中的一个组件，而不是一个独立的解决方案：
IBM 16 的一份白皮书标题为：“评估 DB2 UDB for Linux 与 DRBD 和 Heartbeat：一个低成本的开放式 Linux 高可用性解决方案”。
Microsoft 15 为 SAP 应用提供的 HA 指南详细说明了“使用 DRBD 和 Pacemaker 的高可用性 NFS 存储”。
IBM 10 在其 Netezza 文档中建议：“建议允许 DRBD 管理由 Heartbeat 控制，以避免脑裂问题”。
ClusterLabs 18 的文档明确指出：“使用 Pacemaker 和 DRBD 的双节点（或多节点）主动/被动集群在许多情况下都是一种经济高效的高可用性解决方案”。
这些证据一致表明，DRBD 的可靠性必须在与 Pacemaker/Corosync 等集群编排工具结合的背景下进行评估。
5.2 故障切换流程：一个有序的编排过程
“自动接管”不是一个单一的动作，而是一个由 CRM（如 Pacemaker）严格编排的、有序的流程。Pacemaker 通过一个专为 DRBD 设计的 OCF 资源代理 13 来管理 DRBD 资源。DRBD 通常被配置为可提升的（promotable）资源（在早期文档中称为“主/从”或 "master/slave" 资源 18）。
一个典型的、配置正确的自动故障切换流程如下：
监控 (Monitor)：Pacemaker（通过其底层的 Corosync 消息层）持续监控所有集群节点的健康状况。当 ha1 (Primary) 节点停止发送心跳时，集群检测到该节点发生故障。
隔离 (Isolate)：集群的第一反应不是启动服务，而是隔离故障节点。Pacemaker 立即执行针对 ha1 的 Fencing (STONITH) 代理。这是防止脑裂的绝对必要步骤 12。
提升 (Promote)：只有在 Fencing 代理返回“成功”（即确认 ha1 已被射击并断电）后，Pacemaker 才会继续。它现在指示幸存节点 ha2 上的 DRBD 资源代理将 ha2 的角色提升为 Primary。
启动服务 (Start Services)：一旦 DRBD 报告 Primary 角色已激活，Pacemaker 就会按照预定义的依赖关系和顺序启动服务：
a. 挂载文件系统：Pacemaker 启动文件系统资源，将其挂载在现在可写的 /dev/drbd0 设备上。
b. 启动应用：Pacemaker 启动依赖于该文件系统的应用程序（例如 DB2 数据库实例或 SAP NFS 服务器）。
c. 分配 IP：Pacemaker 启动虚拟 IP (VIP) 地址资源，将服务流量引导至 ha2。
这个流程清楚地表明，“自动接管”不是 DRBD 的一个功能，而是一个由 Pacemaker 编排的复杂过程，该过程使用 DRBD 作为其可复制、可提升的存储基础。
6.0 结论：DRBD 可靠性的已验证框架
6.1 调查结果综合
基于对来自 IBM、Microsoft、ClusterLabs 和其他技术来源的权威技术文档的分析，本报告对 DRBD 架构的初步结论进行了验证和详细阐述：
“DRBD 属于 Linux 内核”：此表述基本正确。一个高性能的 DRBD 驱动程序（机制）被包含在 Linux 主线内核中，并随 Debian 等发行版一起分发。
“因此就是 Debian 内核提供的功能”：此表述在技术上正确，但具有误导性。虽然 Debian 内核提供了该驱动，但它必须辅以 drbd-utils 用户态软件包 6 才能进行配置、管理和实际使用（策略与控制）。
“非常可靠”：此表述是有条件正确的。本报告的分析证实，DRBD 的高可靠性不是其固有属性，而是正确配置和完整部署的高可用性架构的一个涌现属性。
6.2 DRBD 可靠性的三大支柱
本报告的证据证实，DRBD 的高可靠性依赖于三个不可或缺的技术支柱：
数据一致性 (RPO≈0)：通过 DRBD 内核驱动程序提供的同步复制（Protocol C） 8 来实现。这确保了零数据丢失，但代价是增加了应用程序的写延迟。
数据完整性（脑裂预防）：必须通过强制性的、非可选的节点 Fencing (STONITH) 机制 12 或在特定拓扑中正确配置的 DRBD Quorum 来实现。这是在网络分区期间保护数据免遭损坏的唯一可靠方法。
服务可用性 (RTO)：通过集群资源管理器（如 Pacemaker） 18 来实现。它负责自动化故障检测、隔离（Fencing）以及有序的服务故障切换（DRBD 提升、文件系统挂载、应用启动）。
6.3 最终声明性陈述
基于对 IBM 10、Microsoft 15 和 ClusterLabs 11 等机构技术文档的分析，本报告得出结论：DRBD 是一个成熟的、高性能的块级复制组件。当且仅当它按照高可用性最佳实践进行部署时——即作为 Pacemaker 集群中受管的可提升资源，配置为 Protocol C 同步复制，并由强制性的 STONITH 机制提供保护——它才能作为高可靠性、自动化 HA 解决方案的基础存储层。
Works cited
Diff - dcc7cd011220d7425a265c9bbf04c5731dacec1b^2..dcc7cd011220d7425a265c9bbf04c5731dacec1b - kernel/common - Git at Google - Android GoogleSource, accessed November 14, 2025,
Diff - f7072e00f0868ff5184d29706905c4a9eca3608e^2..f7072e00f0868ff5184d29706905c4a9eca3608e - kernel/msm - Git at Google - Android GoogleSource, accessed November 14, 2025,
Administration Guide - SUSE Linux Enterprise High Availability 12 SP5, accessed November 14, 2025,
SUSE Linux Enterprise High Availability Extension 11 SP2 - linuxtechint - WordPress.com, accessed November 14, 2025,
Administration Guide | SLE HA 15 SP7 - SUSE Documentation, accessed November 14, 2025,
Debian -- Software Packages in "trixie", accessed November 14, 2025,
Debian -- Source Packages in "sid", accessed November 14, 2025,
DRBD 9.0 en - LINBIT, accessed November 14, 2025,
Quick DR & HA through new x-replicas-on-different feature - LINSTOR - LINBIT Community, accessed November 14, 2025,
DRBD administration - IBM, accessed November 14, 2025,
8. Fencing — Pacemaker Explained - ClusterLabs, accessed November 14, 2025,
Pacemaker Explained - ClusterLabs, accessed November 14, 2025,
Configuration Explained - ClusterLabs, accessed November 14, 2025,
[Pacemaker] trying to set up sbd stonith, accessed November 14, 2025,
High availability for NFS on Azure VMs on SLES | Microsoft Learn, accessed November 14, 2025,
DB2 Universal Database (DB2 UDB) for Linux with DRBD and Heartbeat: A Low Cost Open Linux High Availability Solution - IBM, accessed November 14, 2025,
High availability solutions on Microsoft Azure by SLES for SAP Applications, accessed November 14, 2025,
Pacemaker Administration - ClusterLabs, accessed November 14, 2025,
Pacemaker Explained - ClusterLabs, accessed November 14, 2025,
Clusters from Scratch - Apache, DRBD and GFS2 - ClusterLabs, accessed November 14, 2025,