DRBD 与 Ceph 的技术原理、可靠性机制及架构差异分析报告
DRBD 与 Ceph 的技术原理、可靠性机制及架构差异分析报告
一、 DRBD (分布式复制块设备) 框架
1.1 核心定义与操作模型
DRBD (Distributed Replicated Block Device) 是一种为 Linux 平台设计的分布式复制存储系统 1。其实现为 Linux 内核驱动模块 2，通过 IP 网络在多个主机之间镜像（mirror）块设备 4。DRBD 能够复制任何类型的块设备，包括整个硬盘、分区、RAID 逻辑设备或 LVM 逻辑卷 4。
从架构上看，DRBD 采用“无共享”（shared-nothing）设计 6。它通常被概念化为“网络 RAID-1” 6，旨在作为高可用性 (HA) 集群的构建块，并可作为传统共享存储的“直接替代品”（drop-in replacement）6。
对于上层应用程序而言，复制过程是透明的 1。系统会提供一个虚拟块设备（例如 /dev/drbdX）2，应用程序可以像使用本地磁盘一样对其进行操作，例如在其上创建文件系统或供数据库用作裸设备。
1.2 数据工作流与集群集成
DRBD 在其标准的“单主模式”（single-primary mode）10 下运行时，集群中的一个节点扮演“主”（Primary）角色，而另一个节点扮演“从”（Secondary）角色 11。
主节点的 DRBD 设备可以无限制地用于读写操作 11。其数据工作流如下：
写入操作：应用程序的写请求被 DRBD 内核驱动拦截。驱动程序将数据写入本地的后备块设备，并同时通过网络将数据发送给对等节点 2。系统何时向应用程序返回“写入完成”的确认，取决于所选的复制协议（例如，同步模式要求本地和远程均写入完成）2。
读取操作：读取请求通常是最高效的，因为它们直接由本地存储提供服务，不会产生网络流量 2。
从节点（Secondary）的设备会接收来自主节点的所有数据更新，但除此之外，它完全禁止应用程序的访问（包括读或写）11。
DRBD 本身只负责数据复制，它是一个高可用性的“构建块”6，并不提供自动故障检测或服务切换。它被设计为与集群资源管理器 (CRM)（如 Pacemaker）12 以及 Corosync 集群通信层 5 协同工作。在主节点发生故障时，由 Pacemaker 这样的外部 CRM 负责仲裁，将从节点的 DRBD 设备提升（promote）为新
的主节点，然后挂载文件系统并启动相关服务 15。
二、 开发背景、历史与架构演进
2.1 作者身份与商业支持
DRBD 最初由 Philipp Reisner 和 Lars Ellenberg 共同撰写和主要维护 1。该项目的开发、商业支持、咨询和培训服务由项目赞助商 LINBIT HA-Solutions GmbH (维也纳) 和 LINBIT USA LLC (俄勒冈) 提供 1。项目的核心作者也发表了多篇关于 DRBD 设计的技术论文，涵盖复制语义、快速同步等方面 10。
2.2 纳入 Linux 内核主流
DRBD 在作为外部补丁存在多年后，其代码质量和稳定性得到了 Linux 内核社区的认可。DRBD 最终被合并到 Linux 内核主线，并作为标准组件随 Linux 2.6.33 版本发布 9。该内核版本于 2010 年 2 月 24 日发布 17，相关合并记录显示在 2009 年 12 月左右 DRBD 已被合入 7。
这一里程碑事件意义重大。在此之前，使用 DRBD 需要运行非标准的、打过补丁的内核 7，这在企业环境中是一个巨大的部署和支持障碍。被纳入内核主线标志着 DRBD 成为 Linux 平台公认的、成熟的组件，为 SUSE 9 和 Red Hat 18 等主要企业发行版对其的集和支持铺平了道路。
2.3 架构演进：DRBD 9 与 LINSTOR
DRBD 的定位随时间发生了演进。虽然它传统上用于双节点 HA 集群 2，但从 DRBD 9 版本开始，其架构得到了显著扩展。DRBD 9 引入了新功能，包括“超过两路的冗余”（more than two-way redundancy）10，允许将数据同时复制到一个以上的对等节点（例如 3、4 或 5 个节点）2。
这一演进使 DRBD 能够用于构建更大规模的软件定义存储 (SDS) 池 2。在这种新架构中，DRBD 充当 LINSTOR 系统中的核心复制引擎 1。LINSTOR 是一个开源配置管理系统，它使用 DRBD 在节点集群之间进行数据复制，为 Kubernetes、OpenStack 和 Proxmox 等云平台提供持久化块存储 21。
三、 可靠性、一致性与数据完整性机制
3.1 复制协议分析 (RPO)
DRBD 提供了（至少）三种复制模式，用于在数据保护（RPO，恢复点目标）和应用程序延迟之间进行权衡 9。
Protocol A (异步模式)：此为异步复制协议 9。应用程序的写操作在数据写入本地磁盘后立即收到完成确认，数据复制在后台进行 10。此模式下应用程序延迟最低，但如果主节点在数据发送到对端前发生灾难性故障，可能会丢失最近的写入（RPO > 0）。它通常用于高延迟的广域网或跨地域灾备场景 9。
Protocol B (半同步模式)：此模式（在 9 中提到的“三种模式”之一）在写入延迟和数据保护之间取得了平衡。写操作在本地磁盘写入完成并且数据包已到达对端节点内存（即 TCP 发送缓冲区）后，向应用程序返回确认。
Protocol C (同步模式)：此为完全同步的复制协议，也是默认选项 5。写操作必须在本地磁盘和远程对等节点磁盘均确认写入完成后，才向应用程序返回完成信号 2。此模式提供了最高的数据保护级别，可确保在单个节点故障时不会丢失任何数据 (RPO ≈ 0) 11。它适用于低延迟网络（如同一数据中心）的 HA 集群 9。
3.2 一致性与恢复：位图机制
当节点断开连接（例如网络故障）时，DRBD 必须确保在连接恢复后数据能恢复一致。DRBD 使用“快速同步位图”（quick sync bitmap）来高效地处理这一过程 24。
在断开连接期间，主节点会继续服务写入，并使用位图来跟踪哪些数据块（脏块）被修改过 24。当连接重新建立时，节点会交换并比较彼此的位图。DRBD 随后会启动后台的增量 resync（重新同步）24，仅复制在断开期间被修改过的脏块，而非整个设备的全部数据。
这种“高效同步”（efficient synchronization）10 机制（在 DRBD 的早期技术论文中被称为“快速重新同步” 10）至关重要。它极大地缩短了恢复一致性所需的时间，从而降低了 RTO（恢复时间目标），并减少了重新同步时对系统性能的影响。
3.3 脑裂 (Split-Brain) 检测与 Fencing (STONITH)
“脑裂”是 HA 集群中一种危险的状态。当节点间的通信网络中断时，集群可能分裂成两个独立的部分，如果两个节点都错误地认为对方已死锁，并都将自己提升为“主”角色，脑裂就发生了。
DRBD 具备检测脑裂的能力。当网络连接恢复时，DRBD 节点在握手时会发现双方都曾处于“主”状态。此时，DRBD 会立即断开复制连接，并报告“Split-Brain detected”错误，以此作为一种防止数据进一步损坏的“保险丝” 5。
然而，DRBD 本身无法安全地自动解决脑裂；它依赖于外部策略 10。正确防止脑裂导致数据不一致（双写）的机制是 Fencing（隔离）11。Fencing 是一种将行为异常的节点从集群中强制移除的机制 25。
在 Pacemaker 集群中，Fencing 通常通过 STONITH (Shoot The Other Node In The Head) 实现 26。STONITH 是一种“节点级别隔离” 25，它使用带外机制（如 IPMI、DRAC 等管理卡或 SBD 13）在提升新主节点之前，先强行将故障节点断电或重启 26。在任何寻求数据完整性的 HA DRBD 部署中，STONITH 都是一个强制性的、不可或缺的组件 11。
3.4 双主模式与集群文件系统
DRBD 也支持“双主模式”（Dual-Primary mode），即集群中的两个节点同时处于“主”角色，都可以对块设备进行读写 1。
但是，绝对不能在 DRBD 双主设备上使用标准（本地）文件系统（如 ext4 或 XFS）15。本地文件系统假设它对块设备具有独占访问权，其元数据缓存在本地内存中。在双主模式下，一个节点的写入（和元数据更改）会绕过另一个节点的文件系统缓存，导致缓存不一致，并最终导致文件系统严重损坏。
因此，DRBD 双主模式必须与“集群感知文件系统”（cluster-aware filesystem）配合使用，例如 GFS2 (Global File System 2) 或 OCFS2 (Oracle Cluster File System 2) 1。这些文件系统内置了对“分布式锁管理器”（DLM）的支持 1，该机制用于在所有节点之间协调对文件系统元数据的并发访问，从而确保一致性。
四、 DRBD 与 Ceph 的核心架构差异
4.1 根本性差异：复制与分布
DRBD 和 Ceph 之间的差异是根本性的，源于它们截然不同的设计哲学：
DRBD (复制)： 如前所述，DRBD 是一个块设备复制系统 2。其核心模型是创建一个一对一或一对多的块级镜像。它以“卷”（或 DRBD 资源）为中心，在节点间创建完整的、字节一致的副本，类似于“网络 RAID-1” 8。
Ceph (分布)： Ceph 是一个统一的分布式存储系统 30。它的基础是一个名为 RADOS (Reliable Autonomic Distributed Object Store) 的分布式对象存储层 30。Ceph 不创建 1:1 的设备镜像；相反，它将数据（无论是块、文件还是对象）分解为“对象”，并使用 CRUSH 算法将这些对象分布（stripe 和 replicate）到集群中所有 OSD (Object Storage Daemons) 的池中 22。
4.2 架构对比矩阵
为了系统地阐明这些差异，以下矩阵对比了两种技术的关键维度：
4.3 Ceph 架构组件 (RADOS, CRUSH, OSD)
Ceph 的可扩展性源于其独特的去中心化架构：
RADOS：如前所述，RADOS 是 Ceph 的基础 32。它是一个可靠的、自治的对象存储，由 OSD、MON 和 MGR 等守护进程组成 30。
OSD (Object Storage Daemon)：OSD 是负责在物理磁盘上实际存储数据、处理 I/O 请求、管理数据复制和恢复的守护进程 43。
MON (Monitor)：MON 维护着集群的“主副本”状态，即“Cluster Map” 33。它不存储数据，但对集群的整体一致性至关重要。
CRUSH (Controlled Replication Under Scalable Hashing)：CRUSH 是 Ceph 的核心数据放置算法 36。与 DRBD 的静态点对点配置不同，Ceph 客户端和 OSD 使用 CRUSH 算法和 Cluster Map 计算出任何给定数据对象应该存储在哪个 OSD 上 37。这种设计消除了中心化的元数据查找瓶颈，实现了大规模的水平扩展和在集群变更（如添加/移除 OSD）时最小化数据迁移 36。
Peering (对等)：Ceph 通过“Peering”过程在 OSD 之间维护一致性。对于一个 PG（Placement Group，一组对象的集合），负责它的 OSD 集合（Acting Set）中的主 OSD 会协调 Peering 过程，确保所有副本 OSD 对 PG 中的对象状态和元数据达成一致 30。
五、 DRBD、CephFS 与“集群文件系统”的关系
5.1 DRBD 与 GFS2/OCFS2 的关系
如 3.4 节所述，DRBD 不是一个集群文件系统。它是一个底层的块复制层 6。当 DRBD 以单主（Active/Passive）模式运行时，可以在其上使用任何标准本地文件系统（如 ext4, XFS）15。但是，当 DRBD 以双主（Active/Active）模式运行时，它必须与一个真正的集群文件系统（如 GFS2 或 OCFS2）结合使用 10。在这种架构中，DRBD 负责提供“共享块”的假象，而 GFS2/OCFS2 及其 DLM 1 负责在上层提供分布式锁，以协调并发访问和维护文件系统的一致性。
5.2 CephFS 架构
CephFS 是一个原生的分布式文件系统 32。它与“DRBD + GFS2”的堆叠模型完全不同。CephFS 直接构建在 RADOS 对象存储层之上 30。它使用一组专用的 MDS (Metadata Server) 守护进程来管理文件系统的命名空间（目录树）和元数据（如文件权限、时间戳）30。而文件的数据内容本身则被切分为对象，直接存储在 RADOS 集群中 46。
六、 选型指南：适用场景分析
6.1 首选 DRBD 的典型条件
DRBD（及其 LINSTOR 生态）是在以下条件下的理想选择：
小规模高可用 (HA)：当需求是为 2 到 3 个节点提供高可用的块存储时，DRBD 是成熟且高效的选择 3。
低延迟的传统应用：DRBD 非常适合为 I/O 敏感的传统应用（如数据库、持久化消息队列、虚拟机根磁盘）提供服务。其简单的内核级复制路径通常能提供比复杂分布式系统更低的写延迟 22。
严格的 RPO=0 需求：在低延迟网络上，使用 Protocol C 可以实现 RPO≈0 的强同步复制 11。
运维简易性：DRBD 及其“网络 RAID-1”模型更易于理解和管理。在灾难性故障中，其数据恢复路径更简单（数据完整地存在于单个后备设备上）22。
6.2 首选 Ceph 的典型条件
Ceph 是面向大规模、多功能存储的解决方案，适用于以下场景：
大规模扩展性：当需要一个可以水平扩展到 PB 级容量或数千个节点的存储系统时，Ceph 基于 CRUSH 的架构是其核心优势 30。
统一存储需求：当需要一个平台同时提供对象存储 (S3/RGW)、块存储 (RBD) 和文件存储 (CephFS) 时，Ceph 的统一架构 31 可以避免存储孤岛。
灵活的数据保护：Ceph 允许在存储池级别灵活选择数据保护策略，例如使用 3 副本实现高可用性，或使用纠删码 (EC) 41 在保证弹性的同时大幅节约存储空间。
云平台与超融合 (HCI)：Ceph 是 OpenStack 51、Kubernetes 和 Proxmox 49 等云平台与 HCI 环境的理想后端存储。
高并发读取/吞吐量：Ceph 非常适合并发访问（例如虚拟机镜像库或 Web 场）或读多写少的场景 22。
值得注意的是，Ceph 并不适合用于双节点集群，其架构（尤其是 MON 仲裁）至少需要 3 个节点才能实现高可用 35。
七、 额外技术细节
7.1 DRBD 堆叠资源 (Stacked Resources)
DRBD 支持“堆叠资源”（Stacked Resources）的概念 12。这允许在一个已有的 DRBD 设备上再创建一个 DRBD 资源。这种技术常用于实现级联复制，例如：在两个本地节点之间使用 Protocol C（同步）实现 HA，然后将主节点的 DRBD 设备“堆叠”一个使用 Protocol A（异步）的 DRBD 资源，将其复制到远程的灾备中心，实现同城 HA 与异地容灾的组合 5。
7.2 DRBD 9 多节点连接
DRBD 9 及其后续版本支持多节点连接 2。这意味着一个 DRBD 资源可以同时在多个节点（例如 3 个或更多）之间建立点对点的复制连接，形成网状或星状拓扑。这为构建更具弹性的软件定义存储池（如 LINSTOR 所管理的）提供了基础 21。
八、 结论
本报告基于权威技术文档对 DRBD 和 Ceph 进行了深入分析。结论如下：
DRBD 是一个成熟、高性能的 Linux 块复制组件 6。它作为内核驱动运行，最适合用于小规模（特别是双节点）的高可用性 (HA) 解决方案 3。其核心优势在于能够为传统应用（如数据库）提供低延迟、强一致性 (RPO≈0) 的“网络 RAID-1” 6。DRBD 不是一个独立的 HA 方案，它必须与 Pacemaker 等集群管理器集成，并且强制要求配置 STONITH/Fencing 机制以确保数据完整性 13。
Ceph 是一个复杂的、统一的分布式存储系统 30。它基于 RADOS 对象存储 32 和 CRUSH 放置算法 36，专为大规模水平扩展（PB 级）而设计。Ceph 的核心优势在于其“自治”特性和能够从单一集群提供对象 (S3)、块 (RBD) 和文件 (CephFS) 三种服务 30。它适用于云平台、超融合基础架构和海量数据存储，并提供灵活的数据保护选项（复制或纠删码）41。
这两种技术并非（通常不是）直接竞争对手 22。DRBD 解决了小规模、低延迟、强一致性的 HA 块存储问题。Ceph 解决了大规模、高吞吐量、统一接口的分布式存储问题。技术选型应严格基于部署规模、延迟/吞吐量需求、数据模型以及运维复杂度来决定。
Works cited
DRBD - Wikipedia, accessed November 14, 2025,
DRBD - LINBIT, accessed November 14, 2025,
High Availability DRBD on RHEL 8 - Ach.Chusnul Chikam - Medium, accessed November 14, 2025,
Distributed Replicated Block Device (DRBD) - Ubuntu Server documentation, accessed November 14, 2025,
DRBD | Administration Guide | SLE HA 15 SP7 - SUSE Documentation, accessed November 14, 2025,
Distributed Replicated Block Device - DRBD - The Linux Kernel documentation, accessed November 14, 2025,
DRBD merged into Linux kernel 2.6.33 - Hacker News, accessed November 14, 2025,
GFS2 Shared-Disk Cluster Filesystem over a Pacemaker 2 nodes cluster using DRBD - GitHub, accessed November 14, 2025,
Data Replication Across Geo Clusters via DRBD | SUSE Documentation, accessed November 14, 2025,
DRBD 9.0 en - LINBIT, accessed November 14, 2025,
DRBD 8.4 en - LINBIT, accessed November 14, 2025,
DRBD 9.0 cn - LINBIT, accessed November 14, 2025,
Highly Available NFS Storage with DRBD and Pacemaker | SLE HA 15 SP7, accessed November 14, 2025,
Highly Available NFS Exports with DRBD & Pacemaker - LINBIT, accessed November 14, 2025,
Two node HA filesystem : r/linuxadmin - Reddit, accessed November 14, 2025,
User Guide DRBD 9 PDF - Scribd, accessed November 14, 2025,
Linux_2_6_33 - Linux Kernel Newbies, accessed November 14, 2025,
Is DRBD available in Red Hat Enterprise Linux 6?, accessed November 14, 2025,
Linux kernel for Apalis, Colibri and Verdin modules - Toradex's Git, accessed November 14, 2025,
User Guides and Product Documentation - LINBIT, accessed November 14, 2025,
LINSTOR User Guide - LINBIT, accessed November 14, 2025,
Comparing LINSTOR & Ceph Storage Clusters - LINBIT, accessed November 14, 2025,
DRBD merged with kernel 2.6.33 - Kev009.com, accessed November 14, 2025,
Replication mode Protocol C in LinBit DRBD - Stack Overflow, accessed November 14, 2025,
Fencing and STONITH | Administration Guide | SLE HA 15 SP7 - SUSE Documentation, accessed November 14, 2025,
Fencing and STONITH | Administration Guide | SLE HA 12 SP5 - SUSE Documentation, accessed November 14, 2025,
Highly Available NFS Storage with DRBD and Pacemaker | SLE HA 15 SP7, accessed November 14, 2025,
Chapter 9. Convert Cluster to Active/Active - ClusterLabs, accessed November 14, 2025,
9. Convert Storage to Active/Active — Clusters from Scratch - ClusterLabs, accessed November 14, 2025,
Architecture - Ceph Documentation, accessed November 14, 2025,
DRBD vs. IBM Storage Ceph Comparison - SourceForge, accessed November 14, 2025,
Ceph.io — Technology, accessed November 14, 2025,
Ceph Storage Cluster - Ceph Documentation, accessed November 14, 2025,
RADOS: A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters - Ceph.io, accessed November 14, 2025,
DRBD/LINSTOR vs Ceph vs StarWind VSAN: Proxmox HCI Performance Comparison, accessed November 14, 2025,
CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data | Carlos Maltzahn, accessed November 14, 2025,
crushtool – CRUSH map manipulation tool - Ceph Documentation, accessed November 14, 2025,
CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data - IEEE Xplore, accessed November 14, 2025,
CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data Abstract 1 Introduction - Ceph, accessed November 14, 2025,
IBM Storage Ceph Concepts and Architecture Guide, accessed November 14, 2025,
Architecture Guide | Red Hat Ceph Storage | 4, accessed November 14, 2025,
Speed of Light Media Replaces Ceph with DRBD for Its Cloud Needs - LINBIT, accessed November 14, 2025,
OSD — Ceph Documentation, accessed November 14, 2025,
IBM Storage Ceph Concepts and Architecture Guide, accessed November 14, 2025,
Peering - Ceph Documentation, accessed November 14, 2025,
Ceph File System - Ceph Documentation, accessed November 14, 2025,
ceph-mds -- ceph metadata server daemon, accessed November 14, 2025,
Intro to Ceph - Ceph Documentation, accessed November 14, 2025,
2 Node Cluster HA DRBD or CEPH? - Proxmox Support Forum, accessed November 14, 2025,
Compare DRBD vs. IBM Storage Ceph in 2025 - Slashdot, accessed November 14, 2025,
Red Hat Enterprise Linux Cluster, High Availability, and GFS Deployment Recommended Practices, accessed November 14, 2025,