DRBD9和LINSTOR用户指南——DRBD简介

DRBD简介

1. DRBD基础

DRBD是一种基于软件的无共享复制存储解决方案，可镜像主机之间的块设备（硬盘，分区，逻辑卷等）的内容。

DRBD镜像数据

• 实时地。当应用程序修改设备上的数据时，复制将连续进行。
• 透明地。应用程序不需要知道数据存储在多个主机上。
• 同步或异步。使用同步镜像，在所有（连接的）主机上执行写操作后，会向应用程序通知写完成情况。使用异步镜像，当本地完成写入时（通常在它们传播到其他主机之前），会通知应用程序写入完成。

1.1。内核模块

DRBD的核心功能是通过Linux内核模块实现的。具体来说，DRBD构成了虚拟块设备的驱动程序，因此DRBD恰好位于系统I / O堆栈底部的附近。因此，DRBD非常灵活且用途广泛，这使其成为适用于几乎所有应用程序增加高可用性的复制解决方案。

根据定义并根据Linux内核体系结构的要求，DRBD不了解其上方的各个层。因此，DRBD无法奇迹般地将这些特征所不具备的功能添加到上层。例如，DRBD不能自动检测文件系统损坏，也不能向文件系统（例如ext3或XFS）添加主动-主动群集功能。

图1. DRBD在Linux I / O堆栈中的位置

1.2。用户空间管理工具

DRBD带有一组与内核模块通信的管理工具，以便配置和管理DRBD资源。从顶层到最底层是：

drbdmanage

作为单独的项目提供，这是在多节点群集中协调DRBD资源的推荐方法。DRBD Manage使用一种DRBD 9资源来存储其群集范围的配置数据，并通过调用外部程序（例如lvcreate和）提供了一种快速简便的方法来执行最常需要的管理任务drbdadm。

有关更多详细信息，请参阅本文档中的DRBD管理条目。

drbdadm

DRBD-utils程序套件的高级管理工具。获得从配置文件中的所有DRBD配置参数/etc/drbd.conf，并充当一个前端为drbdsetup和drbdmeta。 drbdadm具有使用选项调用的空运行模式，该模式-d显示在不实际调用这些命令的情况下将发出哪些drbdsetup和哪些drbdmeta调用 drbdadm。

drbdsetup

配置已加载到内核的DRBD模块。drbdsetup必须在命令行上传递所有要传递的参数 。drbdadm和之间的分隔 drbdsetup允许最大的灵活性。大多数用户几乎根本不需要drbdsetup直接使用。

drbdmeta

允许创建，转储，还原和修改DRBD元数据结构。像一样 drbdsetup，大多数用户仅很少需要drbdmeta直接使用。

1.3。资源资源

在DRBD中，资源是统称，指的是特定复制数据集的所有方面。这些包括：

资源名称

这可以是任何任意的US-ASCII名称，不包含用来引用资源的空格。

卷数

任何资源都是一个复制组，该复制组由共享公用复制流的多个卷之一组成 。DRBD可确保资源中所有卷的写入保真度。卷以开头0，并且一个资源中最多可以包含65,535个卷。卷包含复制的数据集和供DRBD内部使用的一组元数据。

在该drbdadm级别上，资源中的卷可以通过资源名称和卷号寻址为。resource/volume

DRBD设备

这是由DRBD管理的虚拟块设备。它的设备主设备号为147，其从设备号按惯例从0开始编号。每个DRBD设备对应于资源中的一个卷。关联的块设备通常命名为 ，其中设备次设备号。通常还会创建包含资源名称和卷号的符号链接，如中所示 。/dev/drbdXXudev/dev/drbd/by-res/resource/vol-nr

很早以前的DRBD版本就劫持了NBD的设备主要号码43。147是 LANANA注册的 DRBD设备专业。

连接

阿连接是共享一个复制的数据集在两个主机之间的通信链路。使用DRBD 9，可以在多个主机上定义每个资源。使用当前版本，这需要在这些主机之间建立全连接（即，该资源彼此连接的每个主机）

在该drbdadm级别上，连接由资源和连接名称（后者默认为对等主机名）寻址 。resource:connection

1.4。资源角色

在DRBD中，每个资源都有一个角色，该角色可以是 Primary或Secondary。

这里的术语选择不是任意的。DRBD的创建者故意将这些角色命名为“主动”和“被动”。主要与辅助是指与存储可用性有关的概念，而主动与被动是指应用程序的可用性。在高可用性环境中，通常情况下主节点也是活动节点 ，但这绝不是必需的。

• 具有主要角色的DRBD设备可以不受限制地用于读取和写入操作。它可用于创建和安装文件系统，对块设备的原始或直接I / O等。
• 充当次要角色的DRBD设备从对等节点的设备接收所有更新，但否则将完全禁止访问。应用程序不能将其用于读取或写入访问。不允许甚至对设备进行只读访问的原因是必须保持高速缓存一致性，如果以任何方式都可以访问辅助资源，则不可能。

资源的角色可以，当然可以改变，或者通过 人工干预，通过一些自动算法的方式，通过集群管理应用程序，或自动。将资源角色从辅助角色更改为主要角色称为提升，而反向操作称为降级。

2. DRBD功能

本章讨论了各种有用的DRBD功能，并提供了有关这些功能的一些背景信息。这些功能中的某些对大多数用户而言很重要，而某些功能仅在非常特定的部署方案中才有意义。使用DRBD以及故障排除和错误恢复包含有关如何在日常操作中启用和使用这些功能的说明。

2.1。单主要模式

在单主要模式下，资源在任何给定时间仅在一个集群成员上担当主要角色。由于可以保证任何时刻只有一个群集节点可以处理数据，因此该模式可以与任何常规文件系统（ext3，ext4，XFS等）一起使用。

以单主要模式部署DRBD是高可用性（具有故障转移功能）集群的典型方法。

2.2。双主模式

在双主模式下，资源在任何给定时间在两个群集节点[ 1 ]上处于主角色。由于因此可以同时访问数据，因此该模式需要使用利用分布式锁管理器的共享群集文件系统。示例包括 GFS和OCFS2。

对于需要从两个节点进行并发数据访问的负载平衡群集，首选的方法是在双主模式下部署DRBD。需要实时迁移的虚拟化环境。默认情况下，此模式是禁用的，必须在DRBD的配置文件中显式启用。

有关为特定资源启用双主模式的信息，请参阅启用双主模式。

2.3。复制方式

DRBD支持三种不同的复制模式，允许三种复制同步度。

协议A

异步复制协议。一旦本地磁盘写入完成，并且复制包已放置在本地TCP发送缓冲区中，就认为主节点上的本地写入操作已完成。在强制故障转移的情况下，可能会发生数据丢失。故障转移后，备用节点上的数据保持一致；但是，崩溃前执行的最新更新可能会丢失。协议A最常用于长距离复制方案中。与DRBD Proxy结合使用时，它可以提供有效的灾难恢复解决方案。有关更多信息，请参见通过DRBD代理进行远程复制。

协议B

内存同步（半同步）复制协议。一旦发生本地磁盘写入，并且复制数据包到达对等节点，就认为在主节点上的本地写入操作已完成。通常，在强制故障转移的情况下不会丢失任何写操作。然而，在这两个节点上同时停电的情况下，与主要的数据存储的同时，不可逆转地销毁，完成了初级最近写可能会丢失。

协议C

同步复制协议。仅在确认本地和远程磁盘写入后，才认为在主节点上的本地写入操作已完成。结果，保证了单个节点的丢失不会导致任何数据丢失。如果所有节点（分别是其存储子系统）同时不可逆转地被破坏，则即使使用此复制协议，数据丢失也是不可避免的。

到目前为止，DRBD设置中最常用的复制协议是协议C。

复制协议的选择会影响部署的两个因素：保护和延迟。相反，吞吐量在很大程度上与所选的复制协议无关。

有关演示复制协议配置的示例资源配置，请参阅配置资源。

2.4。超过2路冗余

使用DRBD 9，可以将数据同时存储在两个以上的集群节点上。

尽管在通过堆栈进行堆叠之前已经可以做到这一点，但在DRBD 9中，（当前）最多可支持16个节点。（实际上，通过DRBD使用3路，4路或5路冗余将使其他事情成为导致停机的主要原因。）

堆叠解决方案的主要区别在于，由于仅使用了一级数据复制，因此性能损失较小。

2.5。自动推广资源

在DRBD 9之前，将使用drbdadm primary命令完成资源的升级。使用DRBD 9，auto-promote 启用该选项后，DRBD将自动将资源提升为主要角色，并且其中一个卷已装入或打开以进行写入。卸载或关闭所有卷后，资源的角色将变回辅助角色。

仅当集群状态允许时（即，如果显式drbdadm primary命令将成功），自动升级才会成功。否则，安装或打开设备的操作将与DRBD 9之前的操作失败。

2.6。多重复制传输

DRBD支持多种网络传输。到目前为止，有两种传输实现可用：TCP和RDMA。每个传输实现都是其自己的内核模块。

2.6.1。TCP传输

该drbd_transport_tcp.ko传输实现附带DRBD自身的分发文件。顾名思义，此传输实现使用TCP / IP协议在计算机之间移动数据。

DRBD的复制和同步框架套接字层支持多种低层传输：

IPv4上的TCP

这是规范的实现，并且是DRBD的默认实现。它可以在启用了IPv4的任何系统上使用。

IPv6上的TCP

当配置为使用标准TCP套接字进行复制和同步时，DRBD也可以使用IPv6作为其网络协议。尽管使用不同的寻址方案，但这在语义和性能上与IPv4等效。

SDP

SDP是用于支持RDMA的传输（如InfiniBand）的BSD样式套接字的实现。SDP是大多数发行版的OFED堆栈的一部分，但现在已被弃用。SDP使用IPv4样式的寻址方案。通过InfiniBand互连，SDP为DRBD提供了高吞吐量，低延迟的复制网络。

超级插座

SuperSocket用单个，整体式，高效且支持RDMA的套接字实现替换了堆栈的TCP / IP部分。DRBD可以使用此套接字类型进行非常低延迟的复制。SuperSockets必须在特定硬件上运行，而该硬件目前可以从单个供应商Dolphin Interconnect Solutions获得。

2.6.2。RDMA传输

或者，drbd_transport_rdma.ko可从LINBIT 获得内核模块。此传输使用动词/ RDMA API在InfiniBand HCA，支持iWARP的NIC或支持RoCE的NIC上移动数据。与BSD套接字API（由TCP / IP使用）相反，动词/ RDMA API允许在很少的CPU参与下进行数据移动。

2.6.3。结论

在高传输速率下，tcp传输的CPU负载/内存带宽可能成为限制因素。您可以使用带有适当硬件的rdma传输来获得更高的传输速率。

可以为资源的每个连接配置传输实现。有关更多详细信息，请参见配置传输实现。

2.7。高效同步

（重新）同步与设备复制不同。尽管在发生任何写入事件时都会发生复制，以主角色进行资源复制，但是同步与传入的写入是分离的。相反，它会影响整个设备。

如果由于主节点故障，辅助节点故障或复制链路中断等原因导致复制链接中断，则必须进行同步。就DRBD而言，DRBD不会以原始写入的顺序而是以线性顺序同步已修改的块，因此同步是有效的，这具有以下后果：

• 同步速度很快，因为其中发生了多个连续写操作的块仅同步了一次。
• 同步还与很少的磁盘搜寻相关联，因为块是根据磁盘上自然块布局进行同步的。
• 在同步期间，备用节点上设置的数据部分已过时，部分已更新。数据的这种状态称为 不一致。

在进行后台同步时，该服务将继续在活动节点上不间断运行。

具有不一致数据的节点通常不能被投入运行，因此希望保持节点不一致的时间段尽可能短。但是，DRBD附带了LVM集成工具，该工具可以在同步之前自动创建LVM快照。这样可确保 即使在运行同步时，对等方始终可以使用一致的数据副本。有关使用此功能的详细信息，请参阅在DRBD同步期间使用自动LVM快照。

2.7.1。可变速率同步

在可变速率同步中（默认值为8.4），DRBD会检测同步网络上的可用带宽，将其与传入的前台应用程序I / O进行比较，并基于全自动控制回路选择合适的同步速率。

请参阅可变同步速率配置，以获取有关可变速率同步的配置建议。

2.7.2。固定速率同步

在固定速率同步中，每秒传送到同步对等方的数据量（同步速率）具有可配置的静态上限。基于此限制，您可以根据以下简单公式估算预期的同步时间：

图2.同步时间

t sync是预期的同步时间。D是要同步的数据量，您不太可能对其产生任何影响（这是复制链接断开时由应用程序修改的数据量）。 R是同步速率，它是可配置的-受复制网络和I / O子系统的吞吐量限制的限制。

有关固定速率同步的配置建议，请参阅配置同步速率。

2.7.3。基于校验和的同步

通过使用数据摘要（也称为校验和），可以进一步提高DRBD同步算法的效率。当使用基于校验和的同步时，DRBD不会对标记为不同步的块执行强行覆盖，而是 在同步块之前先读取块，然后计算当前在磁盘上找到的内容的哈希值。然后，它将此哈希与从对等方的相同扇区计算出的哈希进行比较，如果哈希匹配，则将其重写。当DRBD处于断开模式时，文件系统重写具有相同内容的扇区时，这可以大大缩短同步时间。

有关同步的配置建议，请参阅配置基于校验和的同步。

2.8。暂停复制

如果配置正确，DRBD可以检测复制网络是否拥塞，并在这种情况下挂起复制。在这种模式下，主节点“拉”到辅助节点上-暂时不同步，但仍在辅助节点上保留一致的副本。当有更多带宽可用时，复制将自动恢复并进行后台同步。

暂停复制通常通过带宽可变的链接来启用，例如通过数据中心或云实例之间的共享连接进行广域复制。

有关拥塞策略和暂停复制的详细信息，请参阅配置拥塞策略和暂停复制。

2.9。在线设备验证

在线设备验证使用户能够以非常有效的方式在节点之间进行逐块数据完整性检查。

请注意，此处的有效是指有效利用网络带宽，并且验证不会以任何方式破坏冗余。在线验证仍然是一项资源密集型操作，对CPU利用率和平均负载有明显影响。

它由一个节点（验证源）按顺序计算存储在特定资源的下层存储设备上的每个块的加密摘要。然后，DRBD将该摘要传输到对等节点（验证目标），然后在该对等节点中根据受影响块的本地副本的摘要对其进行检查。如果摘要不匹配，则该块被标记为不同步，以后可能会同步。由于DRBD仅发送摘要，而不发送全部块，因此在线验证非常有效地利用了网络带宽。

该过程称为在线验证，因为它不需要在验证时未使用正在验证的DRBD资源。因此，尽管在线验证在运行时确实会带来轻微的性能损失，但在线验证不会在验证运行期间或后续同步期间引起服务中断或系统停机时间。

由本地cron守护程序管理在线验证是一种常见的用例，例如每周一次或每月运行一次。有关如何启用，调用和自动执行在线验证的信息，请参阅使用在线设备验证。

2.10。复制流量完整性检查

DRBD可以选择使用加密消息摘要算法（例如MD5，SHA-1或CRC-32C）执行端到端消息完整性检查。

这些消息摘要算法不是由DRBD提供的，而是由Linux内核加密API提供的。DRBD仅使用它们。因此，DRBD能够利用特定系统的内核配置中可用的任何消息摘要算法。

启用此功能后，DRBD会为其复制到对等方的每个数据块生成一个消息摘要，然后对等方将使用该消息摘要来验证复制数据包的完整性。如果无法根据摘要验证复制的块，则将断开连接并立即重新建立连接；否则，将重新建立连接。由于位图，典型的结果是重传。因此，DRBD复制受到保护，免受多个错误源的影响，如果不进行检查，所有这些错误源都可能在复制过程中导致数据损坏：

• 在主存储器和发送节点上的网络接口之间传输的数据上发生按位错误（“位翻转”）（TCP校验和不会将其卸载到网卡中，这在最近的实现中很常见）；
• 在从网络接口传输到接收节点上的主内存的数据中发生位翻转（相同的注意事项适用于TCP校验和卸载）；
• 由于竞争状况或网络接口固件或驱动程序中的错误而导致的任何形式的损坏；
• 节点之间的某些重组网络组件（如果未使用直接的，背对背的连接）注入的比特翻转或随机损坏。

请参阅配置复制流量完整性检查，以获取有关如何启用复制流量完整性检查的信息。

2.11。裂脑通知和自动恢复

裂脑的情况是，由于群集节点之间所有网络链接的暂时故障，并且可能由于群集管理软件的干预或人为错误，两个节点在断开连接时都切换为主要角色。这是一种潜在的有害状态，因为这意味着可能已在任一节点上对数据进行了修改，而没有将其复制到对等端。因此，在这种情况下，很可能已经创建了两个分散的数据集，无法简单地合并它们。

DRBD裂脑与集群裂脑不同，后者是由分布式集群管理应用程序（如心跳）管理的主机之间的所有连接丢失。为避免混淆，本指南使用以下约定：

• 脑裂是指上文段落中所述的DRBD脑裂。
• 所有群集连接性的丧失称为群集分区，是群集裂脑的替代术语。

当检测到大脑裂开时，DRBD允许自动通知操作员（通过电子邮件或其他方式）。有关 如何配置此功能的详细信息，请参阅“ 裂脑通知 ”。

尽管在这种情况下建议采取的措施是 手动解决裂脑问题，然后消除其根本原因，但在某些情况下，可能希望使流程自动化。DRBD有几种可用的解析算法：

• 放弃对较年轻的小学学生所做的修改。在这种模式下，当重新建立网络连接并发现裂脑时，DRBD将同时放弃在最后切换到主要角色的节点上所做的修改。
• 放弃对较旧的主数据库所做的修改。在这种模式下，DRBD将同时放弃在首先切换为主角色的节点上所做的修改。
• 放弃更改较少的主数据库上的修改。在这种模式下，DRBD将检查两个节点中哪个节点记录了较少的修改，然后将丢弃在该主机上进行的所有修改。
• 如果一位宿主没有中间变化，则可以从裂脑中恢复。在这种模式下，如果其中一个主机在裂脑期间根本没有进行任何修改，则DRBD会简单地恢复正常并宣布裂脑已解决。请注意，这是一个不太可能发生的情况。即使两个主机都仅将文件系统安装在DRBD块设备上（甚至是只读的），设备内容也通常会被修改（例如，通过文件系统日志重播），从而排除了自动恢复的可能性。

自动裂脑恢复是否可以接受在很大程度上取决于个人应用。考虑DRBD托管数据库的示例。对于Web应用程序点入数据库，使用较少更改的方法丢弃来自主机的修改可能很好。相反，自动丢弃对财务数据库所做的任何修改，而在任何裂脑事件中都需要手动恢复，可能是完全不可接受的。在启用自动裂脑恢复之前，请仔细考虑您的应用程序要求。

请参阅自动脑裂恢复策略有关配置DRBD的自动裂脑复苏策略的详细信息。

2.12。支持磁盘刷新

当诸如硬盘驱动器或RAID逻辑磁盘之类的本地块设备启用了写缓存时，对这些设备的写入将在它们到达易失性缓存后立即视为已完成。控制器制造商通常将此称为写回模式，而相反的是直写模式。如果在写回模式下控制器断电，则最后的写操作将永远不会提交到磁盘，从而可能导致数据丢失。

为了解决这个问题，DRBD利用磁盘刷新功能。磁盘刷新是一种写操作，仅在关联数据已提交到稳定（非易失性）存储时才完成，也就是说，已将其有效地写入磁盘，而不是缓存。DRBD使用磁盘刷新对其复制的数据集及其元数据进行写操作。实际上，DRBD在其认为必要的情况下会规避写缓存，例如在活动日志 更新或强制执行隐式写后写依赖关系时。即使面对电源故障，这也意味着更高的可靠性。

重要的是要了解，DRBD仅在分层支持支持它们的支持设备之上时才能使用磁盘刷新。最合理的最新内核支持大多数SCSI和SATA设备的磁盘刷新。Linux软件RAID（md）支持RAID-1的磁盘刷新，前提是所有组件设备也支持它们。设备映射器设备（LVM2，dm-raid，多路径）也是如此。

具有电池支持的写缓存（BBWC）的控制器使用电池来备份其易失性存储。在此类设备上，当断电后恢复供电时，控制器会将所有待处理的写操作从电池后备的缓存中清空到磁盘中，以确保提交给易失性缓存的所有写操作实际上都已转移到稳定的存储中。在此类设备上运行DRBD时，可以禁用磁盘刷新，从而提高DRBD的写入性能。有关详细信息，请参见禁用后备设备刷新。

2.13。修剪/丢弃支持

Trim / Discard是同一功能的两个名称：向存储系统的请求，告诉它不再使用某些数据范围[ 2 ]，并且可以回收该数据范围。
该调用起源于基于闪存的存储（SSD，FusionIO卡等），该存储无法轻松地重写扇区，而必须再次擦除和写入（新）数据（这会导致某些延迟成本）。有关更多详细信息，请参见例如。[[ https://en.wikipedia.org/wiki/Trim_%28computing%29,wikipedia页面]]。

从8.4.3开始，DRBD包括对Trim / Discard的支持。您无需配置或启用任何功能；如果DRBD检测到本地（底层）存储系统允许使用这些命令，它将透明地启用它们并通过此类请求。

效果是，例如。最近使用足够mkfs.ext4多的TB卷可以将初始同步时间缩短到几秒钟到几分钟-只是告诉DRBD（它将将该信息中继到所有连接的节点），现在可以看到大多数/所有存储如无效。

稍后连接到该资源的节点将看不到“ 修剪 / 丢弃”请求，因此将开始完全重新同步；但是，取决于内核版本和文件系统，调用fstrim可能会给出所需的结果。

即使您没有带修剪 / 丢弃支持的存储，某些虚拟块设备也会为您提供相同的功能，例如Thin LVM。

2.14。磁盘错误处理策略

如果一个硬盘驱动器发生故障，而该硬盘驱动器在其中一个节点上用作DRBD的后备块设备，则DRBD可能会将I / O错误传递到上层（通常是文件系统），也可能会掩盖来自以下位置的I / O错误：上层。

传递I / O错误

如果将DRBD配置为传递I / O错误，则在下层设备上发生的任何此类错误都将透明地传递到上层I / O层。因此，留给上层来处理此类错误（例如，这可能导致文件系统以只读方式重新安装）。此策略不能确保服务连续性，因此不建议大多数用户使用。

掩盖I / O错误

如果DRBD被配置为分离的较低级别的I / O错误，DRBD将这样做，自动地在所述第一低级别的I / O错误的发生。当DRBD通过网络从对等节点透明地获取受影响的块时，I / O错误将从上层掩盖。从那时起，DRBD被称为以无盘模式运行，并且仅在对等节点上执行所有后续的I / O操作（读写）。此模式下的性能将降低，但是服务将继续运行而不会中断，并且可以在方便的时候以有意的方式移至对等节点。

有关为DRBD 配置I / O错误处理策略的信息，请参阅配置I / O错误处理策略。

2.15。处理过时数据的策略

DRBD区分不一致和过时的 数据。不一致的数据是指不能以任何方式访问和使用的数据。最好的例子是当前正在进行的同步目标的节点上的数据。这样的节点上的数据有些过时，有些是最新的，并且无法识别为两者之一。因此，例如，如果设备拥有文件系统（通常是这种情况），则该文件系统将无法挂载，甚至无法通过自动文件系统检查。

相反，过时的数据是辅助节点上的数据是一致的，但不再与主节点同步。复制链接的任何中断（无论是临时的还是永久的）都将发生这种情况。过期，断开连接的辅助节点上的数据应该是干净的，但它反映了一段时间后对等节点的状态。为了避免服务使用过时的数据，DRBD不允许提升处于过时状态的资源。

DRBD的接口允许外部应用程序在发生网络中断时立即使辅助节点过期​​。然后，DRBD将拒绝将节​​点切换为主要角色，从而防止应用程序使用过时的数据。对于Pacemaker群集管理框架（使用与DRBD复制链接分开的通信通道），存在该功能的完整实现。但是，这些接口是通用的，任何其他群集管理应用程序都可以轻松使用它们。

每当过时的资源重新建立其复制链接时，都会自动清除其过时的标志。甲后台同步然后如下。

有关示例DRBD / Heartbeat / Pacemaker配置的信息，请参阅有关DRBD过时对等守护程序（dopd）的部分，该配置可防止意外使用过时的数据。

2.16。通过堆叠进行三向复制

在DRBD版本8.3.0及更高版本中可用；DRBD版本9.x中已弃用，因为可以在一个级别上实现更多节点。有关详细信息，请参见 定义网络连接。

使用三向复制时，DRBD将第三个节点添加到现有的2节点群集中，并将数据复制到该节点，该节点可用于备份和灾难恢复目的。这种类型的配置通常涉及通过DRBD Proxy进行远程复制。

三向复制的工作原理是，在保存生产数据的现有资源之上添加另一个堆叠的 DRBD资源，如下图所示：

图3. DRBD资源堆叠

使用异步复制（DRBD协议A）复制堆栈的资源，而生产数据通常使用同步复制（DRBD协议C）。

可以永久使用三向复制，其中使用生产集群中的数据不断更新第三个节点。或者，也可以按需使用它，其中生产集群通常与备份站点断开连接，并且定期执行站点到站点的同步，例如通过执行每夜一次的cron作业。

2.17。通过DRBD代理进行远程复制

DRBD的协议A是异步的，但是套接字输出缓冲区已满时，写入应用程序将立即阻塞（请参阅sndbuf-size手册页中的选项drbd.conf）。在这种情况下，写入应用程序必须等待，直到写入的某些数据通过可能很小的带宽网络链路耗尽为止。

平均写入带宽受网络链接的可用带宽限制。如果写入突发只能放入有限的套接字输出缓冲区中，则不能正常处理。

您可以通过DRBD代理的缓冲机制来减轻这种情况。DRBD代理会将更改后的数据从主节点上的DRBD设备放到其缓冲区中。DRBD代理的缓冲区大小可以自由配置，仅受地址空间大小和可用物理RAM的限制。

可选地，可以将DRBD代理配置为压缩和解压缩其转发的数据。DRBD数据包的压缩和解压缩可能会稍微增加延迟。但是，当网络链路的带宽是限制因素时，缩短传输时间的收益将超过压缩和解压缩的开销。

压缩和解压缩是在考虑多核SMP系统的情况下实现的，并且可以利用多个CPU核。

大多数块I / O数据压缩得很好，因此有效带宽增加，这一事实证明即使使用DRBD协议B和C，也可以使用DRBD代理。

有关配置DRBD代理的信息，请参见使用 DRBD代理。

DRBD代理是DRBD产品系列中未经开放源代码许可发布的少数几个部分之一。请联系 [email protected]或[email protected]获取评估许可证。

2.18。基于卡车的复制

基于卡车的复制（也称为磁盘传送）是一种通过将存储介质实际传送到远程站点来在远程站点中预备要复制的数据的方法。这特别适用于以下情况

• 要复制的数据总量相当大（超过数百GB）；
• 要复制的数据的预期变化率不大；
• 站点之间的可用网络带宽是有限的。

在这种情况下，如果没有基于卡车的复制，DRBD将需要非常长的初始设备同步（大约数周，数月或数年）。基于卡车的复制允许将数据种子运送到远程站点，从而大大减少了初始同步时间。有关此用例的详细信息，请参阅使用基于卡车的复制。

2.19。浮动同行

DRBD版本8.3.2和更高版本中提供了此功能。

DRBD的一个特殊使用案例是浮动对等 配置。在浮动对等方设置中，DRBD对等方不绑定到特定的命名主机（如在常规配置中一样），而是具有在多个主机之间浮动的能力。在这种配置中，DRBD通过IP地址而不是主机名来标识对等体。

有关管理浮动对等配置的详细信息，请参阅 配置DRBD在两个SAN支持的Pacemaker群集之间复制。

2.20。数据重新平衡（水平存储扩展）

如果您公司的策略表明需要三向冗余，则至少需要三台服务器来进行设置。

现在，随着存储需求的增长，您将遇到对其他服务器的需求。不必同时购买3台服务器，您可以在单个附加节点上重新平衡数据。

图4. DRBD数据重新平衡

在上图中，你可以看到在之前和之后的状态：从3个节点与每次三米25TiB的卷（净75TiB），4个节点，净100TiB。

DRBD 9使得可以在线实时迁移数据；请参阅 数据重新平衡以了解所需的确切步骤。

2.21。DRBD客户端

通过DRBD的多对等功能，添加了许多有趣的用例，例如DRBD客户端。

基本思想是DRBD 后端可以包含3个，4个或更多节点（取决于所需的冗余策略）。但是，因为DRBD 9可以连接更多的节点。然后，除了存储复制外，DRBD还可以用作存储访问协议。

在主DRBD客户端上执行的所有写请求都将传送到配备存储的所有节点。读取请求仅传送到服务器节点之一。该DRBD客户端将平均分配所有可用的服务器节点之间的读取请求。

有关配置文件的语法，请参阅永久无盘节点。如果使用drbdmanage，请--client在将资源分配给节点时使用其选项。

2.22。法定人数

为了避免大脑分裂或副本数据分散，必须配置围栏。事实证明，在实际部署中，节点防护并不流行，因为在规划或部署节点防护时经常会发生错误。

目前，一个数据集具有3个副本，可以依靠DRBD中的仲裁实现，而不是Pacemaker级别的防护。Pacemaker通过资源的主评分获得有关仲裁或仲裁丢失的信息。

DRBD的仲裁可以与任何基于Linux的服务一起使用。如果服务在遭受IO错误的那一刻终止，则仲裁丢失行为非常优雅。如果服务不会因IO错误而终止，则需要将系统配置为重新引导释放仲裁的主节点。

有关更多信息，请参见配置仲裁。

2.22.1。决胜局

仲裁仲裁功能在9.0.18及更高版本的DRBD中可用。

两个节点群集的基本问题是，在失去连接的那一刻，我们有两个分区，而它们都没有仲裁，这导致群集停止服务。可以通过向群集添加第三个无盘节点来缓解此问题，然后该节点将充当仲裁仲裁者。

有关更多信息，请参见使用无盘节点作为决胜分局。

2.23。VCS的DRBD集成

Veritas Cluster Server（或Veritas Infoscale Availabilty）是Pacemaker开源软件的商业替代产品。如果您需要将DRBD资源集成到VCS设置中，请参阅 github上drbd-utils / scripts / VCS中的自述 文件。