DRBD详细解说
一、DRBD介绍
DRBD（Distributed ReplicatedBlock Device）是一种基于软件的，无共享，分布式块设备复制的存储解决方案，在服务器之间的对块设备（硬盘，分区，逻辑卷等）进行镜像。也就是说当某一个应用程序完成写操作后，它提交的数据不仅仅会保存在本地块设备上，DRBD也会将这份数据复制一份，通过网络传输到另一个节点的块设备上，这样，两个节点上的块设备上的数据将会保存一致，这就是镜像功能。
DRBD是由内核模块和相关脚本而构成，用以构建高可用性的集群，其实现方式是通过网络来镜像整个设备。它允许用户在远程机器上建立一个本地块设备的实时镜像，与心跳连接结合使用，可以把它看作是一种网络RAID，它允许用户在远程机器上建立一个本地块设备的实时镜像。
DRBD工作在内核当中，类似于一种驱动模块。DRBD工作的位置在文件系统的buffer cache和磁盘调度器之间，通过tcp/ip发给另外一台主机到对方的tcp/ip最终发送给对方的drbd，再由对方的drbd存储在本地对应磁盘 上，类似于一个网络RAID-1功能。在高可用(HA)中使用DRBD功能，可以代替使用一个共享盘阵。本地(主节点)与远程主机(备节点)的数据可以保 证实时同步。当本地系统出现故障时,远程主机上还会保留有一份相同的数据,可以继续使用。
二、DRDB的工作原理
DRBD是linux的内核的存储层中的一个分布式存储系统，可用使用DRBD在两台Linux服务器之间共享块设备，共享文件系统和数据。类似于一个网络RAID-1的功能，
其工作原理的架构图如下：
DRBD底层设备支持
DRBD需要构建在底层设备之上，然后构建出一个块设备出来。对于用户来说，一个DRBD设备，就像是一块物理的磁盘，可以在上面内创建文件系统。
DRBD所支持的底层设备有以下这些类：
1）一个磁盘，或者是磁盘的某一个分区；
2）一个soft raid 设备；
3）一个LVM的逻辑卷；
4）一个EVMS（Enterprise Volume Management System，企业卷管理系统）的卷；
5）其他任何的块设备。
DRBD工作原理
DRBD是一种块设备,可以被用于高可用(HA)之中.它类似于一个网络RAID-1功能.当你将数据写入本地 文件系统时,数据还将会被发送到网络中另一台主机上.以相同的形式记录在一个文件系统中。 本地(主节点)与远程主机(备节点)的数据可以保证实时同步.当本地系统出现故障时,远程主机上还会 保留有一份相同的数据,可以继续使用.在高可用(HA)中使用DRBD功能,可以代替使用一个共享盘阵.因为数据同时存在于本地主机和远程主机上,切换时,远程主机只要使用它上面的那份备份数据,就可以继续进行服务了。
DRBD是如何工作的（工作机制）
(DRBD Primary)负责接收数据，把数据写到本地磁盘并发送给另一台主机(DRBD Secondary)，另一个主机再将数据存到自己的磁盘中。目前，DRBD每次只允许对一个节点进行读写访问，但这对于通常的故障切换高可用集群来说已经足够用了。以后的版本将支持两个节点进行读写存取。
DRBD协议说明
1）数据一旦写入磁盘并发送到网络中就认为完成了写入操作。
2）收到接收确认就认为完成了写入操作。
3）收到写入确认就认为完成了写入操作。
DRBD与HA的关系
一个DRBD系统由两个节点构成，与HA集群类似，也有主节点和备用节点之分，在带有主要设备的节点上，应用程序和操作系统可以运行和访问DRBD设备（/dev/drbd*）。在主节点写入的数据通过DRBD设备存储到主节点的磁盘设备中，同时，这个数据也会自动发送到备用节点对应的DRBD设备，最终写入备用节点的磁盘设备上，在备用节点上，DRBD只是将数据从DRBD设备写入到备用节点的磁盘中。现在大部分的高可用性集群都会使用共享存储，而DRBD也可以作为一个共享存储设备，使用DRBD不需要太多的硬件的投资。因为它在TCP/IP网络中运行，所以，利用DRBD作为共享存储设备，要节约很多成本，因为价格要比专用的存储网络便宜很多；其性能与稳定性方面也不错
三、DRBD的特性（基本功能）
分布式复制块设备（DRBD技术）是一种基于软件的，无共享，复制的存储解决方案，在服务器之间的对块设备（硬盘，分区，逻辑卷等）进行镜像。
DRBD镜像数据的特性：
1）实时性：当某个应用程序完成对数据的修改时，复制功能立即发生
2）透明性：应用程序的数据存储在镜像块设备上是独立透明的，他们的数据在两个节点上都保存一份，因此，无论哪一台服务器宕机，都不会影响应用程序读取数据的操作，所以说是透明的。
3）同步镜像和异步镜像：同步镜像表示当应用程序提交本地的写操作后，数据后会同步写到两个节点上去；异步镜像表示当应用程序提交写操作后，只有当本地的节点上完成写操作后，另一个节点才可以完成写操作。
四、DRBD的用户空间管理工具
为了能够配置和管理drbd的资源，drbd提供了一些管理工具与内核模块进行通信：
1）drbdadm：高级的DRBD程序管理套件工具。它从配置文件/etc/drbd.conf中获取所有配置参数。drbdadm为drbdsetup和drbdmeta两个命令充当程序的前端应用，执行drbdadm实际是执行的drbdsetup和drbdeta两个命令。
2）drbdsetup：drbdsetup可以让用户配置已经加载在内核中运行的DRBD模块，它是底层的DRBD程序管理套件工具。使用该命令时，所有的配置参数都需要直接在命令行中定义，虽然命令很灵活，但是大大的降低了命令的简单易用性，因此很多的用户很少使用drbdsetup。
3）drbdmeta：drbdmeta允许用户创建、转储、还原和修改drbd的元数据结构。这个命令也是用户极少用到。
五、DRBD的模式
DRBD有2中模式，一种是DRBD的主从模式，另一种是DRBD的双主模式
1）DRBD的主从模式
这种模式下，其中一个节点作为主节点，另一个节点作为从节点。其中主节点可以执行读、写操作；从节点不可以挂载文件系统，因此，也不可以执行读写操作。在这种模式下，资源在任何时间只能存储在主节点上。这种模式可用在任何的文件系统上（EXT3、EXT4、XFS等等）。默认这种模式下，一旦主节点发生故障，从节点需要手工将资源进行转移，且主节点变成从节点和从节点变成主节点需要手动进行切换。不能自动进行转移，因此比较麻烦。为了解决手动将资源和节点进行转移，可以将DRBD做成高可用集群的资源代理（RA），这样一旦其中的一个节点宕机，资源会自动转移到另一个节点，从而保证服务的连续性。
2）DRBD的双主模式
这是DRBD8.0之后的新特性。在双主模式下，任何资源在任何特定的时间都存在两个主节点。这种模式需要一个共享的集群文件系统，利用分布式的锁机制进行管理，如GFS和OCFS2。部署双主模式时，DRBD可以是负载均衡的集群，这就需要从两个并发的主节点中选取一个首选的访问数据。这种模式默认是禁用的，如果要是用的话必须在配置文件中进行声明。
六、DRBD的同步协议
DRBD的复制功能就是将应用程序提交的数据一份保存在本地节点，一份复制传输保存在另一个节点上。但是DRBD需要对传输的数据进行确认以便保证另一个节点的写操作完成，就需要用到DRBD的同步协议，DRBD同步协议有三种：
1）协议A：异步复制协议
一旦本地磁盘写入已经完成，数据包已在发送队列中，则写被认为是完成的。在一个节点发生故障时，可能发生数据丢失，因为被写入到远程节点上的数据可能仍在发送队列。尽管，在故障转移节点上的数据是一致的，但没有及时更新。这通常是用于地理上分开的节点。
数据在本地完成写操作且数据已经发送到TCP/IP协议栈的队列中，则认为写操作完成。如果本地节点的写操作完成，此时本地节点发生故障，而数据还处在TCP/IP队列中，则数据不会发送到对端节点上。因此，两个节点的数据将不会保持一致。这种协议虽然高效，但是并不能保证数据的可靠性。
2）协议B：内存同步（半同步）复制协议
一旦本地磁盘写入已完成且复制数据包达到了对等节点则认为写在主节点上被认为是完成的。数据丢失可能发生在参加的两个节点同时故障的情况下，因为在传输中的数据可能不会被提交到磁盘
数据在本地完成写操作且数据已到达对端节点则认为写操作完成。如果两个节点同时发生故障，即使数据到达对端节点，这种方式同样也会导致在对端节点和本地节点的数据不一致现象，也不具有可靠性。
3）协议C：同步复制协议
只有在本地和远程节点的磁盘已经确认了写操作完成，写才被认为完成。没有任何数据丢失，所以这是一个群集节点的流行模式，但I / O吞吐量依赖于网络带宽。只有当本地节点的磁盘和对端节点的磁盘都完成了写操作，才认为写操作完成。这是集群流行的一种方式，应用也是最多的，这种方式虽然不高效，但是最可靠。
以上三种协议中，一般使用协议C，但选择C协议将影响流量，从而影响网络时延。为了数据可靠性，在生产环境使用时须慎重选项使用哪一种协议。
七、DRBD的资源
在DRBD中，资源是所有可复制移动存储设备的总称，它包括：
1）资源名称：资源名称可以是除了空白字符以外的任意ASCII码字符
2）DRBD设备：DRBD的虚拟块设备。在双方节点上，DRBD设备的设备文件命名方式；一般为/dev/drbdN，其主设备号147，N是次设备号
3）磁盘配置：DRBD内部应用需要本地数据副本，元数据。在双方节点上，为各自提供的存储设备。
4）网络配置：双方数据同步时所使用的网络属性；
八、DRBD的配置说明
----------全局配置项（global）----------
基本上我们可以做的也就是配置usage-count是yes还是no了，usage-count参数其实只是为了让linbit公司收集目前drbd的使用情况。当drbd在安装和升级的时候会通过http协议发送信息到linbit公司的服务器上面。
----------公共配置项（common）----------
这里的common，指的是drbd所管理的多个资源之间的common。配置项里面主要是配置drbd的所有resource可以设置为相同的参数项，比如protocol，syncer等等。
----------DRBD设备----------
DRBD的虚拟块设备。它有一个主设备号为147的设备，默认的它的次要号码编从0开始。在一组主机上,drbd的设备的设备名称为/dev/drbdN，这个N通常和他的次设备号一致。
资源配置项（resource）
resource 项中配置的是drbd所管理的所有资源，包括节点的ip信息，底层存储设备名称，设备大小，meta信息存放方式，drbd对外提供的设备名等等。每一个 resource中都需要配置在每一个节点的信息，而不是单独本节点的信息。并且资源名只能使用纯ascii码而且不能使用空白字符用于表示资源名称。实 际上，在drbd的整个集群中，每一个节点上面的drbd.conf文件需要是完全一致的。另外，resource还有很多其他的内部配置项：
1）net：网络配置相关的内容，可以设置是否允许双主节点（allow-two-primaries）等。
2）startup：启动时候的相关设置，比如设置启动后谁作为primary（或者两者都是primary：become-primary-on both）
3）syncer： 同步相关的设置。可以设置“重新”同步（re-synchronization）速度（rate）设置，也可以设置是否在线校验节点之间的数据一致性 （verify-alg 检测算法有md5，sha1以及crc32等）。数据校验可能是一个比较重要的事情，在打开在线校验功能后，我们可以通过相关命令（drbdadm verify resource_name）来启动在线校验。在校验过程中，drbd会记录下节点之间不一致的block，但是不会阻塞任何行为，即使是在该不一致的 block上面的io请求。当不一致的block发生后，drbd就需要有re-synchronization动作，而syncer里面设置的rate 项，主要就是用于re-synchronization的时候，因为如果有大量不一致的数据的时候，我们不可能将所有带宽都分配给drbd做re- synchronization，这样会影响对外提提供服务。rate的设置和还需要考虑IO能力的影响。如果我们会有一个千兆网络出口，但是我们的磁盘 IO能力每秒只有50M，那么实际的处理能力就只有50M，一般来说，设置网络IO能力和磁盘IO能力中最小者的30%的带宽给re- synchronization是比较合适的（官方说明）。另外，drbd还提供了一个临时的rate更改命令，可以临时性的更改syncer的rate 值：
4）drbdsetup /dev/drbd0 syncer -r 100M
这样就临时的设置了re-synchronization的速度为100M。不过在re-synchronization结束之后，需要通过 drbdadm adjust resource_name 来让drbd按照配置中的rate来工作。
----------角色----------
在drbd构造的集群中，资源具有角色的概念，分别为primary和secondary。
所有设为primary的资源将不受限制进行读写操作。可以创建文件系统，可以使用裸设备,甚至直接io。所有设为secondary的设备中不能挂载，不能读写。
----------数据同步协议----------
drbd有三种数据同步模式:同步，异步，半同步
1）异步：指的是当数据写到磁盘上，并且复制的数据已经被放到我们的tcp缓冲区并等待发送以后，就认为写入完成
2）半同步：指的是数据已经写到磁盘上，并且这些数据已经发送到对方内存缓冲区，对方的tcp已经收到数据，并宣布写入
3）同步：指的是主节点已写入，从节点磁盘也写入
drbd 的复制模型是靠protocol关键字来定义的：
protocol A表示异步；
protocol B表示半同步；
protocol C表示同步，
默认为protocol C。在同步模式下只有主、从节点上两块磁盘同时损害才会导致数据丢失。在半同步模式下只有主节点宕机，同时从节点异常停电才会导致数据丢失。
注意:drbd的主不会监控从的状态所以有可能会造成数据重传
-----------------------------------metadata----------------------------------
DRBD将数据的各种信息块保存在一个专用的区域里，这些metadata包括了
1）DRBD设备的大小
2）产生的标识
3）活动日志
4）快速同步的位图
metadata的存储方式有内部和外部两种方式，使用哪种配置都是在资源配置中定义的
内部meta data
内部metadata存放在同一块硬盘或分区的最后的位置上
优点：metadata和数据是紧密联系在一起的，如果硬盘损坏，metadata同样就没有了，同样在恢复的时候，metadata也会一起被恢复回来
缺点：metadata和数据在同一块硬盘上，对于写操作的吞吐量会带来负面的影响，因为应用程序的写请求会触发metadata的更新，这样写操作就会造成两次额外的磁头读写移动。
外部meta data
外部的metadata存放在和数据磁盘分开的独立的块设备上
优点：对于一些写操作可以对一些潜在的行为提供一些改进
缺点：metadata和数据不是联系在一起的，所以如果数据盘出现故障，在更换新盘的时候就需要认为的干预操作来进行现有node对心硬盘的同步了
如果硬盘上有数据，并且硬盘或者分区不支持扩展，或者现有的文件系统不支持shrinking，那就必须使用外部metadata这种方式了。
可以通过下面的命令来计算metadata需要占用的扇区数
---------------------------------------------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问题，可通过如下策略进行配置。
1）Discarding modifications made on the “younger” primary。在这种模式下，当网络重新建立连接并且发现了裂脑，DRBD会丢弃最后切换到主节点上的主机所修改的数据。
2）Discarding modifications made on the “older” primary. 在这种模式下，当网络重新建立连接并且发现了裂脑，DRBD丢弃首先切换到主节点上的主机后所修改的数据。
3）Discarding modifications on the primary with fewer changes.在这种模式下，当网络重新建立连接并且发现了裂脑，DRBD会比较两台主机之间修改的数据量，并丢弃修改数据量较少的主机上的所有数据。
4）Graceful recovery from split brain if one host has had no intermediate changes.在这种模式下，如果其中一个主机在脑裂期间并没有数据修改，DRBD会自动重新进行数据同步，并宣布脑裂问题已解决。(这种情况几乎不可 能存在)
特别注意：
自动裂脑自动修复能不能被接受取决于个人应用。考虑 建立一个DRBD的例子库。在“丢弃修改比较少的主节点的修改”兴许对web应用好过数据库应用。与此相反，财务的数据库则是对于任何修改的丢失都是不能 容忍的，这就需要不管在什么情况下都需要手工修复裂脑问题。因此需要在启用裂脑自动修复前考虑你的应用情况。如果没有配置 split brain自动解决方案，我们可以手动解决。首先我们必须要确定哪一边应该作为解决问题后的primary，一旦确定好这一点，那么我们同时也就确定接受丢失在split brain之后另外一个节点上面所做的所有数据变更了。当这些确定下来后，就可以通过以下操作来恢复了：
1）首先在确定要作为secondary的节点上面切换成secondary并放弃该资源的数据：
drbdadm secondary resource_name
drbdadm — –discard-my-data connect resource_name
2）在要作为primary的节点重新连接secondary（如果这个节点当前的连接状态为WFConnection的话，可以省略）
drbdadm connect resource_name
当作完这些动作之后，从新的primary到secondary的re-synchnorisation会自动开始。
九、DRBD的配置文件说明
DRBD的主配置文件为/etc/drbd.conf；为了管理的便捷性，目前通常会将配置文件分成多个部分，且都保存至/etc/drbd.d目录中，主配置文件中仅使用"include"指令将这些配置文件片断整合起来。通常，/etc/drbd.d目录中的配置文件为global_common.conf和所有以.res结尾的文件。其中global_common.conf中主要定义global段和common段，而每一个.res的文件用于定义一个资源。
在配置文件中，global段仅能出现一次，且如果所有的配置信息都保存至同一个配置文件中而不分开为多个文件的话，global段必须位于配置文件的最开始处。目前global段中可以定义的参数仅有minor-count, dialog-refresh, disable-ip-verification和usage-count。
common段则用于定义被每一个资源默认继承的参数，可以在资源定义中使用的参数都可以在common段中定义。实际应用中，common段并非必须，但建议将多个资源共享的参数定义为common段中的参数以降低配置文件的复杂度。
resource段则用于定义DRBD资源，每个资源通常定义在一个单独的位于/etc/drbd.d目录中的以.res结尾的文件中。资源在定义时必须为其命名，名字可以由非空白的ASCII字符组成。每一个资源段的定义中至少要包含两个host子段，以定义此资源关联至的节点，其它参数均可以从common段或DRBD的默认中进行继承而无须定义。