drbd理论

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）。若是发生故障的节点恢复工做，它就会成为新的从节点，并且必须使本身的内容与主节点的内容保持同步。固然，这些操做不会干扰到后台的服务。

 

 

单主模式

在单主模式下,任何资源在任何特定的时间,集群中只存在一个主节点。正是由于这样在集群中只能有一个节点能够随时操做数据,这种模式可用在任何的文件系统上(EXT三、EXT四、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的一方干脆就自我重启,以完全释放有可能还占用着的那些共享资源。