DRBD理论
DRBD(Distributed Replicated Block Device),DRBD 号称是 “网络 RAID”,开源软件,由
LINBIT 公司开发。
DRBD工作原理：
DRBD是一种块设备,可以被用于高可用(HA)之中.他有内核模块和相关程序而组成,通过网络通信来同步镜像整个设备，它类似于一个网络(磁盘阵列)RAID-1功能。
当你将数据写入本地 文件系统时（DRBD Primary）,数据还将会被发送到网络中另一台主机上（DRBD Secondary）.以相同的形式记录在一个文件系统中。本地(主节点)与远程主机(备节点)的数据可以保证实时同步.当本地系统出现故障时,远程主机上还会保留有一份相同的数据,可以继续使用.在高可用(HA)中使用DRBD功能,可以代替使用一个共享盘阵。
因为数据同时存在于本地主机和远程主机上,切换时,远程主机只要使用它上面的那份备份数据,就可以继续进行服务了。
每个设备（drbd 提供了不止一个设备）都有一个状态，可能是‘主’状态或‘从’状态。在主节点上，应用程序应能运行和访问drbd设备（/dev/drbd*）。每次写入都会发往本地磁盘设备和从节点设备中。从节点只能简单地把数据写入它的磁盘设备上。 读取数据通常在本地进行。 如果主节点发生故障，心跳（heartbeat或corosync）将会把从节点转换到主状态，并启动其上的应用程序。（如果您将它和无日志FS 一起使用，则需要运行fsck）。如果发生故障的节点恢复工作，它就会成为新的从节点，而且必须使自己的内容与主节点的内容保持同步。当然，这些操作不会干扰到后台的服务。
单主模式
在单主模式下,任何资源在任何特定的时间,集群中只存在一个主节点。正是因为这样在集群中只能有一个节点可以随时操作数据,这种模式可用在任何的文件系统上(EXT3、EXT4、XFS
等等)。部署 DRBD 单主节点模式可保证集群的高可用性(fail-over 遇故障转移的能力)
双主模式
这是 DRBD8.0 之后的新特性。
在双主模式下,任何资源在任何特定的时间,集群中都存在两个主节点。犹豫双方数据存在并发的可能性,这种模式需要一个共享的集群文件系统,利用分布式的锁机制进行管理,如 GFS 和
OCFS2。
部署双主模式时,DRBD 是负载均衡的集群,这就需要从两个并发的主节点中选取一个首选的访问数据。这种模式默认是禁用的,如果要是用的话必须在配置文件中进行声明。
复制模式
(1) 协议 A 异步复制本地写成功后立即返回，数据放在发送buffer中，可能丢失
一旦本地磁盘写入已经完成,数据包已在发送队列中,则写被认为是完成的 。在一个
节点发生故障时,可能发生数据丢失,因为被写入到远程节点上的数据可能仍在发送队列。尽管,
在故障转移节点上的数据是一致的,但没有及时更新。这通常是用于地理上分开的节点。
(2) 协议 B 半同步复制本地写成功并将数据发送到对方后立即返回，如果双机掉电，数据可能丢失
一旦本地磁盘写入已完成且复制数据包达到了对等节点则认为写在主节点上被认为是
完成的。数据丢失可能发生在参加的两个节点同时故障的情况下,因为在飞行中的数据可能不会
被提交到磁盘。
(3) 协议 C 同步复制本地和对方写成功确认后返回。如果双机掉电或磁盘同时损坏，则数据可能丢失
只有在本地和远程节点的磁盘已经确认了写操作完成,写才被认为完成。没有任何数
据丢失,所以这是一个群集节点的流行模式,但 I/O 吞吐量依赖于网络带宽。
简言之:
A 数据一旦写入磁盘并发送到网络中就认为完成了写入操作。
B 收到接收确认就认为完成了写入操作。
C 收到写入确认就认为完成了写入操作。
就目前而言应用最多和应用最广泛的为协议 C。但选择C协议将影响流量，从而影响网络时延。为了数据可靠性，我们在生产环境中还是用C协议。
工作原理图：
DRBD是linux的内核的存储层中的一个分布式存储系统，可用使用DRBD在两台Linux服务器之间共享块设备，共享文件系统和数据
简单说一下DRBD主要功能，DRBD 负责接收数据，把数据写到本地磁盘，然后通过网络将同样的数据发送给另一个主机，另一个主机再将数据存到自己的磁盘中。
DRBD 配置工具
drbdadm：高级管理工具，管理/etc/drbd.conf，向drbdsetup和drbdmeta发送指令。
drbdsetup：配置装载进kernel的DRBD模块，平时很少直接用。
drbdmeta：管理META数据结构，平时很少直接用。
·
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的默认中进行继承而无须定义。
解决脑裂(split brain)问题:
在“双机热备”高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。由于相互 失去了联系,都以为是对方出了故障,2个节点上的HA软件像“裂脑人”一样,“本能”地争抢“共享资源”、争起“应用服务”,就会发生严重后果:或者共享资源被瓜分、2边“服务”都起不来了;或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏 (常见如数据库轮询着的联机日志出错)。
对付HA系统“裂脑”的对策大概有以下几条:
1)添加冗余的心跳线,例如双线条线。尽量减少“裂脑”发生机会。
2)启用磁盘锁。正在服务一方锁住共享磁盘,“裂脑”发生时,让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题,如果占用共享盘的一 方不主动“解锁”,另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃,就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于 是有人在HA中设计了“智能”锁。即,正在服务的一方只在发现心跳线全部断开(察觉不到对端)时才启用磁盘锁。平时就不上锁了。
3)设置仲裁机制。例如设置参考IP(如网关IP),当心跳线完全断开时,2个节点都各自ping一下 参
考IP,不通则表明断点就出在本端,不仅“心跳”、还兼对外“服务”的本端网络链路断了,即使启动(或继续)应用服务也没有用了,那就主动放弃竞争,让 能够ping通参考IP的一端去起服务。更保险一些,ping不通参考IP的一方干脆就自我重启,以彻底释放有可能还占用着的那些共享资源。