共计 5339 个字符，预计需要花费 14 分钟才能阅读完成。
Distributed Replicated Block Device(DRBD)是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。其核心功能通过 Linux 的内核实现，比文件系统更加靠近操作系统内核及 IO 栈。DRBD 是由内核模块和相关脚本而构成，用以构建高可用性的集群。其实现方式是通过网络来镜像整个设备。你可以把它看作是一种网络 RAID。它允许用户在远程机器上建立一个本地块设备的实时镜像。
一、DRBD 镜像特性及其工作原理
1、特性
实时性：当应用对磁盘的数据进行修改时，复制立即发生。
透明性：应用程序的数据存储在镜像设备上是独立和透明的，数据可存储在不同的服务器上。
同步镜像和异步镜像：
a、同步镜像，当本地发申请进行写操作进行时，同步写到两台服务器上。
b、异步镜像，当本地写申请已经完成对本地的写操作时，开始对对应的服务器进行写操作。
2、原理图
file system->buffer cache ->drbd->disk scheduler->disk drivers
DRBD 原理图
二、DRBD 基础特性
1、资源
DRBD 主要是对磁盘资源的管控，因此在 DRBD 模块中，资源是所有可复制移动存储设备的总称。
资源名：
资源名可以指定除了空格外 us-ascii 中的任意字符。
DRBD 设备：
DRBD 的虚拟块设备。它有一个主设备号为 147 的设备，默认的它的次要号码编从 0 开始。
相关的块设备需命名为 / dev/ drbdm，其中 M 是设备的次要号码。
磁盘配置：
DRBD 内部应用需要本地数据副本，元数据。
网络配置：
各个对等接点间需要进行数据通信。2、资源角色
DRBD 角色：primary<->secondary
主：在主 DRBD 设备中可以进行不受限制的读和写的操作。
他可用来创建和挂载文件系统、初始化或者是直接 I/O 的快设备，等等。
备：
接收所有来自对等节点的更新，不能被应用也不能被读写访问。主要目的是保持缓冲及数据一致性。
人工干预和管理程序的自动聚类算法都可以改变资源的角色。资源可以由被变换为主，以及主到备。1
3、特性
支持复制传输数据完整性验证 (验证算法：MD5、SHA-1、CRC-32C)
此特性针对在复制过程中由于网络传输原因导致的数据不一致。DRBD 对每个
要复制的块生成一个校验和 (摘要信息)，用来对 peer 端数据进行完整性校验，如果接收到的
块的校验和与 source 端的校验和不一致，将会要求重传。
resource <resource>
net {
data-integrity-alg <algorithm>;
}
…
}
支持在线设备验证
如果我们不在传输过程中对数据进行校验，我们仍然可以采用在线设备验证的方
式，原理同上，我们可以采用定时任务周期性的对数据进行验证。
默认情况下在线设备验证是未启用的，可以在配置文件 /etc/drbd.conf 添加。
resource <resource>
net {
verify-alg <algorithm>;
}
…
}
验证命令：drbdadm verify <resource>
磁盘 IO 错误处理策略
磁盘出现 IO 错误时候，我们应该采用何种策略呢？
DRBD 提供三种策略，分别是：detach、pass_on、call-local-io-error。
detach
这是默认和推荐的选项。如果在节点上发生底层的磁盘 I/O 错误，它会将设备
运行在 diskless 无盘模式下。所有的对节点的读写将会从对端节点进行，这种情况下虽然性能有所下降，
但是仍然可以提供服务，很明显在高可用的情况下，这个策略使我们的首选。
pass_on
drbd 会将 I/O 错误报告到上层。在主节点上，它会将其报告给挂载的文件系统，
但是在此节点上就往往忽略（因此此节点上没有可以报告的上层）
local-io-error
调用本地磁盘 I/O 处理程序中定义的命令。这就需要有相应有让 local-io-error
调用的资源处理程序处理错误的命令。这就给管理员留有足够自由的权力使用命令或者是脚
本调用 local-io-error 处理 I/O 错误。
resource <resource> {
disk {
on-io-error <strategy>;
…
}
…
}
过期数据处理策略
过期数据不是不一致性数据，只是说 secondary 不再与 priamry 同步数据了，secondary 相当于是
一个 snapshot，这时候如果发生切换，那么可想而知，数据的一致性就会出现问题，我们需要通
过某些策略来防止这种情况的发生：当出现过期数据的时候，drbd 的连接状态将会由 connect 变为
Wfconnection, 这时候 Pacemaker 不会允许过期数据的节点提升为 primary
暂停复制
对于一些网络状态不好的情况，如果我们采用协议 C 进行复制，那么数据复制延时将会很严重，
这时候我们可以采用暂停复制的策略，这样当网络状况不好的时候，primary 端将会暂停复制，
primary 和 secondary 将会处于链式的不同步状态，当带宽变为可用的时候，复制将会继续进行。
同步速率配置
可以根据网络带宽或网络资源状况配置同步速率以及使用临时速率，可变速率等。
同步速率设置的超过网络的最大可用带宽也是没有任何意义的。
请注意，同步的速率是 bytes 字节，而不是 bits/s。
resource <resource>
disk {
sync-rate 40M;
…
}
…
}
根据经验同步速率比较合理的是可用带宽的 30%。
计算公式: MIN(I/ O 子系统，网络 I /O)*0.3
假定一个 I/O 子系统能支持 180MB/s 的吞吐量，而千兆网络可支持 110MB/s，
此时网络带宽会成为瓶颈，可以计算出, 同步速率：110*0.3=33MB/s
假定一个 I/O 子系统能支持 80MB/s 的吞吐量，而千兆网络可支持 110MB/s，
此时磁盘 I / O 会成为瓶颈，可以计算出, 同步速率：80*0.3=24MB/s
脑裂通知和自动恢复
split brain 实际上是指在某种情况下，造成 drbd 的两个节点断开连接，都以 primary 的身份来运行。当 drbd 某 primary 节点连接对方节点准备发送信息的时候如果发现对方也是 primary 状态，那么会立刻自行断开连接，并认定当前已经发生 split brain 了，这时候他会在系统日志中记录以下信息：“Split-Brain detected,dropping connection!”当发生 split brain 之后，如果查看连接状态，其中至少会有一个是 StandAlone 状态，另外一个可能也是 StandAlone（如果是同时发现 split brain 状态），也有可能是 WFConnection 的状态。
自动处理：
a、Discarding modifications made on the younger primary
— 后切换成 primary 角色的节点数据将会被丢弃
b、Discarding modifications made on the older primary
— 先切换成 primary 角色的节点数据将会被丢弃
c、Discarding modifications on the primary with fewer changes
––哪个节点更改的数据少就丢弃
d、Graceful recovery from split brain if one host has had no intermediate changes
— 如果有节点根本没有更新数据，就直接恢复
drbd 脑裂主要在 net 配置，有以下关键字：
after-sb-0pri：裂脑已经被探测到，但是现在没有节点处于主角色，对于这个选项，drbd 有以下关键字：
disconnect:
不需要自动恢复，仅仅是调用裂脑处理程序的脚本（如果配置了），断开连接并出在断开模式。
discard-younger-primary:
放弃和回滚最后成为主的上面所做的修改。
discard-least-changes:
放弃和回滚，变动比较少的主机上的修改。
discard-zero-changes:
如果任何节点都没有发生任何变化，仅仅申请在一个节点上做出继续修改即可。
after-sb-1pri：裂脑已经被探测到，现有有一个节点处于主角色，对于这个选项，drbd 有以下关键字：
disconnect:
和 after-sb-0pri 一样，调用裂脑处理程序的脚本（如果配置了），断开连接并出在断开模式。
consensus:
和 after-sb-0pri 中同样的修复策略。如果利用这些策略裂脑危害能选择，那就能自动解决。否则，同样断开指定的动作。
call-pri-lost-after-sb:
和 after-sb-0pri 中同样的修复策略。如果利用这些策略裂脑危害能选择，就在受危害的节点上调用
pri-lost-after-sb 程序。这个程序必须确认在 handlers 中配置，并考虑到从集群中移除该节点。
discard-secondary:
不管哪个主机只要处于次角色，都是裂脑的危害者。
after-sb-2pri：在两个节点都处于主角色时，裂脑被发现。次选项使用和 after-sb-1pri 同样的关键字，丢弃次节点并达成共识。
配置示例：
resource <resource> {
handlers {
split-brain “/usr/lib/drbd/notify-split-brain.sh root” //<handler> 可能是目前系统中一个可执行的文件。
… //e.g. split-brain “/usr/lib/drbd/notify-split-brain.sh root”;
} // 如上通过电子邮件的方式发送到指定的地址。
net {
after-sb-0pri discard-zero-changes; // 脑裂的相关自动修复策略
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
…
}
…
手动处理
首先在确定要作为 secondary 的节点上面切换成 secondary 并放弃该资源的数据
drbdadm secondary <resource>
drbdadm connect –discard-my-data <resource>
在要作为 primary 的节点重新连接 secondary（如果这个节点当前的连接状态为 WFConnection 的话，可以省略）
drbdadm connect <resource>
当作完这些动作之后，从新的 primary 到 secondary 的 re-synchnorisation 会自动开始。
三、DRBD 的复制模式及复制协议
1、复制模式
单主模式:
在单主模式下，任何资源在任何特定的时间，集群中只存��一个主节点。正是因为这样在集群中
只能有一个节点可以随时操作数据，这种模式可用在任何的文件系统上（EXT3、EXT4、XFS 等等）。
双主模式:
在双主模式下，任何资源在任何特定的时间，集群中都存在两个主节点。犹豫双方数据存在并发
的可能性，这种模式需要一个共享的集群文件系统，利用分布式的锁机制进行管理，如 GFS 和
OCFS2。部署双主模式时，DRBD 是负载均衡的集群，这就需要从两个并发的主节点中选取一个首选的
访问数据。这种模式默认是禁用的，如果要是用的话必须在配置文件中进行声明。(DRBD8.0 之后支持)
2、复制协议
协议 A：
数据一旦写入磁盘并发送到网络中就认为完成了写入操作。
在一个节点发生故障时，可能发生远程节点上的数据可能仍在发送队列导致数据丢失。
协议 B：
收到接收确认就认为完成了写入操作。
数据丢失可能发生在参加的两个节点同时故障的情况下。
协议 C：
收到写入确认就认为完成了写入操作。无数据丢失，主流配置，I/O 吞吐量依赖于网络带宽。
Linux 高可用（HA）集群之 DRBD 详解 http://www.linuxidc.com/Linux/2013-08/89035.htm
DRBD 中文应用指南 PDF http://www.linuxidc.com/Linux/2013-08/89034.htm
CentOS 6.3 下 DRBD 安装配置笔记 http://www.linuxidc.com/Linux/2013-06/85600.htm
基于 DRBD+Corosync 实现高可用 MySQL http://www.linuxidc.com/Linux/2013-05/84471.htm
CentOS 6.4 下 DRBD 安装配置 http://www.linuxidc.com/Linux/2013-09/90536.htm
DRBD 的详细介绍：请点这里
DRBD 的下载地址：请点这里
本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-11/124759.htm
