一、drbd相关概念描述

1、drbd概述

Distributed Replicated Block Device(DRBD)是一种基于软件的，无共享，复制的存储解决方案，在服务器之间的对块设备（硬盘，分区，逻辑卷等）进行镜像。

DRBD工作在内核当中的，类似于一种驱动模块。DRBD工作的位置在文件系统的buffer cache和磁盘调度器之间，通过tcp/ip发给另外一台主机到对方的tcp/ip最终发送给对方的drbd，再由对方的drbd存储在本地对应磁盘 上，类似于一个网络RAID-1功能。

在高可用(HA)中使用DRBD功能，可以代替使用一个共享盘阵。本地(主节点)与远程主机(备节点)的数据可以保 证实时同步。当本地系统出现故障时,远程主机上还会保留有一份相同的数据,可以继续使用。

DRBD的架构如下图

2、底层设备支持

DRBD需要构建在底层设备之上，然后构建出一个块设备出来。对于用户来说，一个DRBD设备，就像是一块物理的磁盘，可以在上面内创建文件系统。DRBD所支持的底层设备有以下这些类：

一个磁盘，或者是磁盘的某一个分区；

一个soft raid 设备；

一个LVM的逻辑卷；

一个EVMS（Enterprise Volume Management System，企业卷管理系统）的卷；

其他任何的块设备。

3、DRBD复制模式

协议A：

异步复制协议。一旦本地磁盘写入已经完成，数据包已在发送队列中，则写被认为是完成的。在一个节点发生故障时，可能发生数据丢失，因为被写入到远程节点上的数据可能仍在发送队列。尽管，在故障转移节点上的数据是一致的，但没有及时更新。这通常是用于地理上分开的节点。

协议B：

内存同步（半同步）复制协议。一旦本地磁盘写入已完成且复制数据包达到了对等节点则认为写在主节点上被认为是完成的。数据丢失可能发生在参加的两个节点同时故障的情况下，因为在传输中的数据可能不会被提交到磁盘。

协议C：

同步复制协议。只有在本地和远程节点的磁盘已经确认了写操作完成，写才被认为完成。没有任何数据丢失，所以这是一个群集节点的流行模式，但I / O吞吐量依赖于网络带宽。

一般使用协议C，但选择C协议将影响流量，从而影响网络时延。为了数据可靠性，我们在生产环境使用时须慎重选项使用哪一种协议。

4、软件包介绍

       drbd共有两部分组成：内核模块和用户空间的管理工具。其中drbd内核模块代码已经整合进Linux内核2.6.33以后的版本中，因此，如果您的内核版本高于此版本的话，你只需要安装管理工具即可；否则，您需要同时安装内核模块和管理工具两个软件包，并且此两者的版本号一定要保持对应。

目前适用CentOS 5的drbd版本主要有8.0、8.2、8.3三个版本，其对应的rpm包的名字分别为drbd, drbd82和drbd83，对应的内核模块的名字分别为kmod-drbd, kmod-drbd82和kmod-drbd83。

而适用于CentOS 6的版本为8.4，其对应的rpm包为drbd和drbd-kmdl，但在实际选用时，要切记两点：

1）drbd和drbd-kmdl的版本要对应；

2）drbd-kmdl的版本要与当前系统的内容版本相对应。

二、drbd配置文件

DRBD的所有控制都是在/etc/drbd.conf中，通常情况配置文件包含两行内容：
include "/etc/drbd.d/global_common.conf";

include "/etc/drbd.d/*.res";

/etc/drbd.d/global_common.conf通常包含drbd配置的通用部分。
/etc/drbd.d/下面的res文件通常定义了drbd的资源

最简单的配置文件：

以上是最简单的一个配置文件，更复杂的参数可以根据需要逐一添加或修改。

以下是common配置段的一个实例：

注1
关于global配置段：
      如果所有配置段都在同一个drbd.conf文件中，则该配置必须放在最顶端。
常用选项：
       minor-count：从（设备）个数，取值范围1~255，默认值为32。该选项设定了允许定义的resource个数，当要定义的resource超过了此选项的设定时，需要重新载入drbd内核模块。
       dialog-refresh time：time取值0，或任一正数。默认值为1。我没理解官方对该选项的解释。很少见到此选项被启用。
       disable-ip-verification：是否禁用ip检查
       usage-count：是否参加用户统计，合法参数为yes、no或ask。根据官方示例的说法，一般只配置usage-count选项即可。

注2：
三种协议
       协议A：本地完成写入，且数据包已在发送队列中,则认为写入完成。
       在一个节点发生故障时，可能发生数据丢失。常用与物理上分开的节点。
       协议B：本地完成写入，并收到远程主机的收到数据确认后,则认为写入完成。
       在两个节点同时发生故障时，可能发生数据丢失。因为在数据传输过程中，数据未必能提交到磁盘。
       协议C：本地完成写入，并收到远程主机的写入确认后,则认为写入完成。
       没有任何数据丢失，因此这是最常用的模式。

注3
metadata有两种存储方式：internally和externally.存储方式是在每个resource配置段中指定的。
Internal metadata：
       一个resource被配置成使用internal metadata，意味着DRBD把它的metadata，和实际生产数据存储于相同的底层物理设备中。该存储方式是在设备的最后位置留出一个区域来存储metadata。
       优点：因为metadata是和实际生产数据紧密联系在一起的，如果发生了硬盘损坏，不需要管理员做额外的工作，因为metadata会随实际生产数据的丢失而丢失，同样会随着生产数据的恢复而恢复。
       缺点：如果底层设备只有一块物理硬盘（和RAID相反），这种存储方式对写操作的吞吐量有负面影响，因为应用程序的写操作请求会触发DRBD的metadata的更新。如果metadata存储于硬盘的同一块盘片上，那么，写操作会导致额外的两次磁头读写移动。
       要注意的是：如果你打算在已有数据的底层设备中使用internal metadata，需要计算并留出DRBD的metadata所占的空间大小，并采取一些特殊的操作，否则很有可能会破坏掉原有的数据！至于需要什么样的 特殊操作，可以参考DRBD的官方文档。我要说的是，最好不要这样做！
external metadata：
        该存储方式比较简单，就是把metadata存储于一个和生产数据分开的专门的设备块中。
        优点：对某些写操作，提供某些潜在的改进。
        缺点：因为metadata和生产数据是分开的，如果发生了硬盘损坏，在更换硬盘后，需要管理员进行人工干预，从其它存活的节点向刚替换的硬盘进行完全的数据同步。
        什么时候应该使用exteranl的存储方式：设备中已经存有数据，而该设备不支持扩展（如LVM），也不支持收缩（shrinking）。

注4

在2个节点的配置相同的情况下，可以简化配置文件，如本例：

配置文件中的这个选项设置的速率是永久性的，但可使用下列命令临时地改变rate的值：
       drbdsetup /dev/drbdnum syncer -r 100M
       把上述命令中的num替换成你的drbd设备的从设备号。只能在所有节点的其中一个节点上运行此命令。
       如果想重新恢复成drbd.conf配置文件中设定的速率，执行如下命令： 
              drbdadm adjust resource

官方提示：速率的设定，最好设为有效可用带宽的30%。所谓有效可用带宽，是指网络带宽和磁盘读写速度中的最小者。有两个示例：
       如果I/O子系统所能维持的读写速度为180MB/s，而千兆网络所能维持的网络吞吐速度为110MB/s，那么有效可用带宽为110MB/s，该选项的推荐值为110 x 0.3 = 33MB/s。
       如果I/O速度为80MB/s，而网络连接速度可达千兆，那么有效可用带宽为80MB/s，推荐的rate速率应该为80 x 0.3 = 24MB/s

al- extents：该选项用来设定hot area（即active set）的块数，取值范围是7~3843，默认为127，每个块标志4M大小的底层存储（即底层设备）。DRBD会自动检测host area，如果主节点意外地从集群中断开，当该节点重新加入集群时，hot area所覆盖的区域必须被重新同步。hot area的每次变化，实际上都是对metadata区域的写操作，因此，该选项的值越大，重新同步的时间越长，但需要更新的meta-data也越少。
  而用户手册的另外一部分提到，al-extents调整的是Activity Log的大小。如果使用DRBD设备的应用程序的写操作比较密集，那么，一般建议使用较大的Activity Log（active set），否则metadata频繁的更新操作会影响到写操作的性能。建议值：3389。

verify-alg：该选项指定一个用 于在线校验的算法，内核一般都会支持md5、sha1和crc32c校验算法。在线校验默认关闭，必须在此选项设定参数，以明确启用在线设备校验。 DRBD支持在线设备校验，它以一种高效的方式对不同节点的数据进行一致性校验。在线校验会影响CPU负载和使用，但影响比较轻微。drbd 8.2.5及以后版本支持此功能。
  一旦启用了该功能，你就可以使用下列命令进行一个在线校验： 
  drbdadm verify resource

该命令对指定的resource进行检验，如果检测到有数据块没有同步，它会标记这些块，并往内核日志中写入一条信息。这个过程不会影响正在使用该设备的程序。
如果检测到未同步的块，当检验结束后，你就可以如下命令重新同步它们：
drbdadm disconnect resource
drbdadm connetc resource

可以安排一个cron任务来自动执行在线校验，如：
42 0 * * 0 root /sbin/drbdadm verify resource

如果开启了所有资源的在线检验，可以使用如下命令：
42 0 * * 0 root /sbin/drbdadm verify all

csums- alg：该选项指定一个校验算法，用来标志数据块。如果不启用该选项，resync会从source发送所有的数据块到destination；而如果启 用了此选项，那么resync将只交换那些校验值不同的数据块，当网络带宽有限时，此选项非常有用。而且，在重启一个崩溃的primary节点时，该选项 会降低CPU带宽的占用。

注8
net配置段的常用的选项有：
       sndbuf-size：该选项用来调节TCP send buffer的大小，drbd 8.2.7以前的版本，默认值为0，意味着自动调节大小；新版本的drbd的默认值为128KiB。高吞吐量的网络（例如专用的千兆网卡，或负载均衡中绑 定的连接）中，增加到512K比较合适，或者可以更高，但是最好不要超过2M。
       timeout：该选项设定一个时间值，单位为0.1秒。如果搭档节点没有在此时间内发来应答包，那么就认为搭档节点已经死亡，因此将断开这次TCP/IP连接。默认值为60，即6秒。该选项的值必须小于connect-int和ping-int的值。
       connect-int：如果无法立即连接上远程DRBD设备，系统将断续尝试连接。该选项设定的就是两次尝试间隔时间。单位为秒，默认值为10秒。
       ping-int：该选项设定一个时间值，单位为秒。如果连接到远程DRBD设备的TCP/IP的空闲时间超过此值，系统将生成一个keep-alive包来检测对等节点是否还存活。默认值为10秒。
       ping-timeout：该选项设定一个时间值，单位是0.1秒。如果对等端没有在此时间内应答keep-alive包，它将被认为已经死亡。默认值是500ms。
       max-buffers：该选项设定一个由drbd分配的最大请求数，单位是页面大小（PAGE_SIZE），大多数系统中，页面大小为4KB。这些buffer用来存储那些即将写入磁盘的数据。最小值为32（即128KB）。这个值大一点好。
       max-epoch-size：该选项设定了两次write barriers之间最大的数据块数。如果选项的值小于10，将影响系统性能。大一点好。

用户手册的另外一部分也提到了max-buffers和max-epoch-size，跟drbd.conf部分的解释稍有不同：drbd.conf的帮助 文档中说，max-buffers设定的是最大请求数，max-epoch-size设定的是最高的数据块数；而这部分的帮助文档说，这两个选项影响的是 secondary节点写操作的性能，max-buffers设定的是最大的buffers数，这些buffers是drbd系统是为即将写入磁盘的数据 而分配的；max-epoch-size设定的是两次write barrier之间所允许的最大请求数。
       多数情况下，这两个选项应该并行地设置，而且两个选项的值应该保持一致。两个选项的默认值都是2048，在大多数合理的高性能硬件RAID控制器中，把它们设定为8000比较好。
        两个部分的解释结合起来看，max-buffers设定的是最大的数据块数，max-epoch-size设定的是所能请求的最大块数。

ko- count：该选项设定一个值，把该选项设定的值 乘以 timeout设定的值，得到一个数字N，如果secondary节点没有在此时间内完成单次写请求，它将从集群中被移除（即，primary node进入StandAlong模式）。取值范围0~200，默认值为0，即禁用该功能。
allow-two-primaries：这个是drbd8.0及以后版本才支持的新特性，允许一个集群中有两个primary node。该模式需要特定文件系统的支撑，目前只有OCFS2和GFS可以，传统的ext3、ext4、xfs等都不行！
cram-hmac-alg：该选项可以用来指定HMAC算法来启用对等节点授权。drbd强烈建议启用对等节点授权机制。可以指定/proc/crypto文件中识别的任一算法。必须在此指定算法，以明确启用对等节点授权机制。
shared-secret：该选项用来设定在对待节点授权中使用的密码，最长64个字符。
data-integrity-alg：该选项设定内核支持的一个算法，用于网络上的用户数据的一致性校验。通常的数据一致性校验，由TCP/IP头中所包含的16位校验和来进行，而该选项可以使用内核所支持的任一算法。该功能默认关闭。

另外，还有after-sb-0pri, after-sb-1pri, after-sb-2pri这三个选项，split brian有关。

参考：http://www.drbd.org/users-guide-emb/re-drbdconf.html

三、drbd角色及工作模式

1、角色、模式和数据同步协议

角色
在drbd构造的集群中，资源具有角色的概念，分别为primary和secondary。
所有设为primary的资源将不受限制进行读写操作。可以创建文件系统，可以使用裸设备,甚至直接io。所有设为secondary的设备中不能挂载，不能读写

模式
drbd也有drbd mode：单主模型（主从），双主模型(drbd只有在8.0以后的版本才支持双主模型)
在单主模型下drbd可以使用任意的文件系统
单在双主模型下只能使用集群文件系统，常用的开源的集群文件系统有:ocfs2和gfs2

数据同步协议

drbd有三种数据同步模式:同步，异步，半同步
异步：指的是当数据写到磁盘上，并且复制的数据已经被放到我们的tcp缓冲区并等待发送以后，就认为写入完成
半同步：指的是数据已经写到磁盘上，并且这些数据已经发送到对方内存缓冲区，对方的tcp已经收到数据，并宣布写入
同步：指的是主节点已写入，从节点磁盘也写入
drbd 的复制模型是靠protocol关键字来定义的：protocol A表示异步；protocol B表示半同步；protocol C表示同步，默认为protocol C。在同步模式下只有主、从节点上两块磁盘同时损害才会导致数据丢失。在半同步模式下只有主节点宕机，同时从节点异常停电才会导致数据丢失。
注意:drbd的主不会监控从的状态所以有可能会造成数据重传

2、metadata

DRBD将数据的各种信息块保存在一个专用的区域里，这些metadata包括了
a，DRBD设备的大小
b，产生的标识
c，活动日志
d，快速同步的位图
metadata的存储方式有内部和外部两种方式，使用哪种配置都是在资源配置中定义的
内部meta data
内部metadata存放在同一块硬盘或分区的最后的位置上
优点：metadata和数据是紧密联系在一起的，如果硬盘损坏，metadata同样就没有了，同样在恢复的时候，metadata也会一起被恢复回来
缺点：metadata和数据在同一块硬盘上，对于写操作的吞吐量会带来负面的影响，因为应用程序的写请求会触发metadata的更新，这样写操作就会造成两次额外的磁头读写移动。
外部meta data
外部的metadata存放在和数据磁盘分开的独立的块设备上
优点：对于一些写操作可以对一些潜在的行为提供一些改进
缺点：metadata和数据不是联系在一起的，所以如果数据盘出现故障，在更换新盘的时候就需要认为的干预操作来进行现有node对心硬盘的同步了
如果硬盘上有数据，并且硬盘或者分区不支持扩展，或者现有的文件系统不支持shrinking，那就必须使用外部metadata这种方式了。
可以通过下面的命令来计算metadata需要占用的扇区数
3、split brain脑裂
split brain实际上是指在某种情况下，造成drbd的两个节点断开连接，都以primary的身份来运行。当drbd某primary节点连接对方节点准备 发送信息的时候如果发现对方也是primary状态，那么会立刻自行断开连接，并认定当前已经发生split brain了，这时候他会在系统日志中记录以下信息：“Split-Brain detected,dropping connection!”当发生split brain之后，如果查看连接状态，其中至少会有一个是StandAlone状态，另外一个可能也是StandAlone（如果是同时发现split brain状态），也有可能是WFConnection的状态。
如果我们在配置文件中配置了自动解决split brain（好像linbit不推荐这样做），drbd会自行解决split brain问题，可通过如下策略进行配置。
Discarding modifications made on the “younger” primary。在这种模式下，当网络重新建立连接并且发现了裂脑，DRBD会丢弃最后切换到主节点上的主机所修改的数据。
Discarding modifications made on the “older” primary. 在这种模式下，当网络重新建立连接并且发现了裂脑，DRBD丢弃首先切换到主节点上的主机后所修改的数据。
Discarding modifications on the primary with fewer changes.在这种模式下，当网络重新建立连接并且发现了裂脑，DRBD会比较两台主机之间修改的数据量，并丢弃修改数据量较少的主机上的所有数据。
Graceful recovery from split brain if one host has had no intermediate changes.在这种模式下，如果其中一个主机在脑裂期间并没有数据修改，DRBD会自动重新进行数据同步，并宣布脑裂问题已解决。(这种情况几乎不可 能存在)
注意：自动裂脑自动修复能不能被接受取决于个人应用。考虑 建立一个DRBD的例子库。在“丢弃修改比较少的主节点的修改”兴许对web应用好过数据库应用。与此相反，财务的数据库则是对于任何修改的丢失都是不能 容忍的，这就需要不管在什么情况下都需要手工修复裂脑问题。因此需要在启用裂脑自动修复前考虑你的应用情况。

如果没有配置 split brain自动解决方案，我们可以手动解决。首先我们必须要确定哪一边应该作为解决问题后的primary，一旦确定好这一点，那么我们同时也就确定接受 丢失在split brain之后另外一个节点上面所做的所有数据变更了。当这些确定下来后，我们就可以通过以下操作来恢复了：
1、首先在确定要作为secondary的节点上面切换成secondary并放弃该资源的数据：

2、在要作为primary的节点重新连接secondary（如果这个节点当前的连接状态为WFConnection的话，可以省略）

3、当作完这些动作之后，从新的primary到secondary的re-synchnorisation会自动开始。

本文转自 jerry1111111 51CTO博客，原文链接：http://blog.51cto.com/jerry12356/1856239，如需转载请自行联系原作者