论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2013-02-19 11:39 |只看该作者 |倒序浏览

DRBD技术特点

在这里列举了DRBD的所有技术特点，也正是因为它有这些特点，因此在生产环境中应用比较广泛，也正是有这些特点DRBD也得到了进一步的发展。在了解和使用DRBD技术之前有必要认识它的技术特点。

2.1. 单主模式

单主模式，在一个集群内一个资源在任何给定的时间内仅有一个primary角色，由于这种模式保证了在任何一个时刻只能有一个集群节点来操作数据，因此这种模式能够使用任何常规的文件系统(例如 ext3、ext4、XFS等)

部署在单主模式下DRBD实际上是一种常规的HA结构，即具有故障转移功能的高可用集群方式。

2.2. 双主模式

在双主模式下，对于一个资源，在任何给定的时刻该集群都有两个primary节点，换句话说DRBD的两个节点此时都为primary角色。

由于使用了双主节点，那么并发访问也就成为了可能，因此这种模式需要使用共享集群文件系统，以便使用分布式锁管理器(DLM)，例如GFS和OCFS2系统。

对于使用负载均衡的集群来说，部署双主模式是首先的方法，采用负载均衡的集群能够在这个两个DRBD节点上提供并发数据访问。这种模式在默认情况下是禁用的，因此要想使用这种模式那么就必须在DRBD的配置文件中明确的启用这种模式。

参考“双主模式”部分，以便在指定的资源中启用双主模式。

2.3. 复制数据传输模式

DRBD支持3个绝然不同的复制模式，允许使用3个不同程度的同步复制，换句话说就是DRBD提供了3种不同级别的复制协议。

 协议 A，异步(Asynchronous)复制协议。在这种复制方式中，在本地写操作完成之后，并且发往对点的复制数据包已经进入本地TCP发送缓存后，那么本地写操作在primary节点上的操作被认为是完成了。在这种模式下，如果出现故障转移，那么数据可能将会丢失，处于备用节点的数据在故障转移之后数据始终没有改变，那么最近更新、主节点崩溃之前的数据将会被丢失。

协议A最常使用在远距离复制的环境中，在使用这种方式时会和DRBD代理组合使用，主要用于搭建灾难恢复的有效解决方案，参考“使用DRBD代理实现远距离复制”。

 协议 B，内存同步(semi-synchronous)复制协议。在这种协议下，当本地磁盘写操作完成，并且复制数据已经到达了对点，那么本地写操作就认为在primary节点上的写操作被认为是写完成。通常在这种方式下，如果出现故障转移时不会有数据丢，然而万一两个节点同时出现掉电，存放在内存中的数据没有及时的写入磁盘，那么这将会使得primary节点存储的数据将会出现不可挽回的破会，最近在primary节点上写入的数据可能将会被丢失。

 协议 C，同步(Synchronous)复制协议。仅在本地和远程磁盘写操作已经确认被写入，本地写操作在primary节点上的写操作才被认为是写完成。因此，在这个数据复制模式中，单个节点损坏是不会丢失数据的。如果两个节点(或者是它们的存储子系统)同时发生了不可挽回的损坏，那么在这种复制协议下数据将会被丢失。

      到目前为止，在DRBD技术最常用的复制协议就是协议C。

选择部署哪一种复制协议将会影响两个因素：数据保护和反应时间。相比之下吞吐量在很大程度上不依赖于所选择的协议。

2.4. 多种传输复制数据的协议

DRBD的复制和同步结构中支持多种套接字，也就是说在底层的传输协议上支持多种传输协议：

 IPv4上的TCP 协议：这是最常用的执行方式，并且也是DRBD默认的方式，可以用在任何使用IPv4的系统上；

 IPv6上的TCP协议：对于复制和同步，在配置为标准的TCP套接字时，DRBD也可以使用IPv6网络协议，在语义和性能上相当于IPv4，只是使用了不同的地址格式；

 SDP协议：这种方式是BSD格式的套接字，用于兼容RDMA(Remote Direct Memory Access)方式，例如 InfiniBand。

 DDP作为OFED堆栈的一部分对于大多数当前的发布版本来说都是有效的。SDP使用了IPv4格式的IP地址。采用InfiniBand互相连接，SDP将会为DRBD提供一个高吞吐、低延时的复制网络。

 SuperSockets协议：这种方式使用单一的、高效的和具有兼容RDMA(Remote Direct Memory Access)的集成电路，它替代了TCP/IP堆栈部分。DRBD使用这种类型的套接字在复制中延时将非常低，SuperSockets必须运行在特定的硬件上，当前唯一的提供商就是Dolphin互联网解决方案(Dolphin Interconnect Solutions)。

2.5. 有效地同步策略

同步、重新同步完全不同于设备复制，复制发生在任何向处于primary角色资源的写事件；而同步发生在primary节点和secondary节点之间，因此从这一点看来产生写入的时间和阶段都不同，但是总体上来说，它却会影响整个设备。如果复制连接由于某种原因(可能是primary失败，也可能是secondary节点失败，或者是复制连接的失败)被中断，那么同步就是必须的了。从这个意义上将同步是高效的，但是DRBD不会按照顺序它们被原始写入的顺序同步修改的块，而是按照线性顺序。因此可能会带来以下结果：

 由于几个连续写操作的块在同步时仅是一次性的写入同步，因此数据写入速度非常迅速；

 由于块同步会依据原本磁盘上块的分布，因此与同步伴随的也会有很少的磁盘寻址；

 在同步中，处于备用节点上的存储的数据可能部分数据已经过期，或者可能有些数据已经更新，这种状态称为状态不一致；

处于同步的DRBD，活动节点上提供的服务不会被中断，因为同步会在后台进行。

尽管如此，但是数据不一致的节点通常不能够投入使用，然而，当DRBD与LVM集成的使用中，那么在同步之前将会自动的创建LVM快照，这种方式确保了DRBD对点有效数据的拷贝。

2.5.1. 可变的同步速率

在可变的同步速率中，这也是默认的方式，DRBD会检测用于同步网络的有效的带宽，然后将其和进入前台应用程序输入/输出的流量做比较，然后再在这个基于完全控制回路中选择一个适当的同步速率。

在“可变同步速率的配置”部分，讲述了关于可变速率同步的配置建议。

2.5.2. 锁定同步速率

在锁定同步速率的方式下，每秒钟运送到同步对点的数据量，也就是同步速率，可以设置为一个具体的值，或者说是设置了一个静态上限。通过这个限制值，那么就可以计算出给定运送数据数量的时间值：

         tsync=D/R

在这个公式中：

 tsync表示希望(或者是必须)使用同步的时间；

 D表示需要同步数据的总量，这个数量是不可改变的，因为它代表着应用程序修改数据的总量，这是没法控制的；

 R 表示同步的速率，在有效的带宽范围和I/O子系统内这是一个可以支配的值，换句话说就是这个值将会受到同步网络带宽和I/O子系统因素的影响；

因此，在指定同步速率时，可以借助这个公式，在这个公式中只有D在一定条件下是固定不变的，而tsync和R将会成反比，即：

            D=tsync*R

正是因为这个关系，那么在设置R的时候要考虑到需要使用的tsync就可以了。

2.5.3. 基于校验和的复制

对于DRBD的同步算法使用数据摘要(也就是常说的校验和)会一步增强同步数据的性能。

在使用基于校验和的同步中，DRBD在同步数据之前会读取磁盘上是的数据块，并且会对在当前磁盘上找到的内容计算哈希值，然后会比较这个哈希值，就是说一台计算机的哈希值与对点计算机上同一个扇区的哈希值比较，如果哈希值匹配，那么将会忽略重新写入数据，而不是蛮力的强制全部同步。。

在DRBD的disconnected模式下，重新写入一个扇区的内容时，这种方式可以显著的缩短同步数据所使用的时间。

2.6. 延时同步复制数据

在复制链路发生拥挤时，如果DRBD配置适当，那么在这种情况下DRBD会暂停复制。在这种模式中，primary点会“抢”在secondary节点之前——换句话说就是会临时出现暂时不同步，但是仍将会在secondary节点上留下一个一致的拷贝。当带宽适当时，复制将会自动重新开始，复制也将会在后台进行。

暂时不同步的典型情景是出现在使用可变带宽的情况下，例如通过共享连接实现的数据中心或者云存储。

2.7. 在线设备验证

在线设备验证能够使得用户在两个节点之间以一种高效的方式进行块对快的完整性检测。注意，这里说的高效指的是高效的使用网络带宽，并且这种校验不会以任何方式破坏冗余。在线验证是一个资源密集型操作，它会很明显的影响CPU使用率。

2.8. 复制流量的完整性检测

DRBD可以选择使用加密消息摘要算法，例如MD5、SHA-1或者CRC-32C，执行端到端的数据完整性检测。这些消息摘要加密算法不是DRBD提供的，而是有Linux内核加密API提供，DRBD仅仅是调用使用它们。因此DRBD能够使用linux内核提供的任何有效的摘要算法。

如果启用了这个功能，那么DRBD会对每一个被复制到对点的数据块都产生一个消息摘要，对点会使用这个消息摘要校验复制的数据包。如果被复制的数据块不能够被正确的验证，那么它将会请求对点重新发送复制数据块。

这种方式保护了出错的源数据，如果出现没有被检测到的出错数据包，那么在复制进程中将会出现“腐化”的数据：

 位错误("位翻转"

发生在发送数据的节点主存(也就是内存)和网络接口(也就是网卡)之间，这种错误通常数据没有通过校验和检查就被发到网卡；

 位错误("位翻转"

同样会发生在接收数据对点的网卡到内存之间，同样是由于TCP校验和丢弃；

 由于竞争或者是网卡固件及驱动的缺陷等任何形式造成的数据不完整问题；

 在两个节点之间由于网络组建进行的数据重组产生的位错误或者是注入了无用的数据，如果是使用了直接连接，也就是背靠背的连接，那么则不会有这种情况产生；

图解：

2.9. 脑裂通知和自动恢复

脑裂产生于以下情况：由于集群节点之间的网络连接临时失败，造成这个失败的原因可能是集群管理软件或者是人为的干涉。发生脑裂之后，节点之间变为无连接，两个节点都会切换为primary。这是一种潜在有害状态，由于在这种状态下，无论对哪一个节点上的数据修改不能够被复制到对点，这样的结果是两个节点将会产生“分歧”，而且不能够合并。

当DRBD检测到脑裂发生时，DRBD允许设置自动发送脑裂通知(通过电子邮件或者其它方法)。发生了脑裂情况，推荐使用手工恢复脑裂情况，然而为了从根本上解决问题，在某些情况下使用自动处理DRBD脑裂情况也是必要的。解决DRBD脑裂造成的数据不一致有以下4个模式：

 丢弃对较新的Primary节点上的修改：在这种模式下当网络连接重新建立后并且发现了脑裂，DRBD将会抛弃在自动切换到primary角色资源上运行期间的所有数据修改；

 丢弃对较老的Primary节点上的修改：在这种模式下，DRBD将会首先丢弃最先切换为primary角色资源上运行期间修改的数据；

 丢弃对较少的Primary节点上的修改：在这种模式下，DRBD将会检测两个节的修改记录，对于修改记录较少的点将会被丢弃；

 在发生脑裂后如果一个节点没有任何更变，那么可以从另一节点完美恢复：在这种模式下，如果其中一个节点在脑裂期间没进行过修改，那么DRBD将会简单的优美的恢复数据并且声明脑裂已经解决。注意，这种情况是相当不太可能的。

是否能够使用自动脑裂恢复，在很大程度上依赖于具体的应用。现在考虑一个例子，在DRBD上运行一个数据库，如果这是一个Web应用访问的数据库，那么对于丢弃较少修改是可以的，与之相比，如果它是一个运行在金融业务下的数据库，那么无论是在什么事件下产生的脑裂，都必须通过手动恢复。因此，在启用自动恢复脑裂之前要仔细考虑应用程序的需要。

2.10. 支持磁盘刷新

在本地块设备(例如硬盘驱动器或者是RAID逻辑磁盘)启用了磁盘写缓存时，在达到易失缓存的限制时系统负责将缓存的的数据全部写入驱动器。控制制造商称之为回写模式(write-back mode)，与该模式相对的为直接写入模式(write-through mode)，就是用户写入的数据不会进入易失存储缓存，而是直接写入磁盘。如果突然的掉电发生在回写模式下，那么这意味着可能会导致数据(为什么说是可能，因为可能掉电的瞬间没有数据在易失存储缓存中存在)，就是说在回写模式中，由于存储在易失存储缓存中的数据因为没有及时的写入磁盘而丢失数据。

为了避免这种情况的发生，DRBD使用了磁盘刷新(disk flush)。磁盘刷新是一个写操作，就是说，它可以有效的将数据写入到磁盘，而不是缓存，DRBD为写操作使用了磁盘刷新，包括数据复制和数据的元数据。事实上，DRBD在它认为有必要的环境中回避了使用写缓存这个机制，例如在活动日志更新或者对于不明确实施写入缓存在写入磁盘依赖的情况下。这意味着面对电源的失败又增加了一个额外的可靠性保护。

重要的是理解DRBD能够使用磁盘刷新(这里需要明确一下，仅当它们的上层，有就是后台设备支持磁盘刷新)，对于大多数SCSI和STAT磁盘启动器大多数内核都适当的支持磁盘刷新，Linux软RAID(md)为RAID-1所有组成RAID-1的磁盘驱动器也支持了磁盘刷新，同样对于映射设备(例如 LVM2, dm-raid及多路径)也支持了磁盘刷新机制。

电池支持写缓存(BBWC)的控制器使用了电池支持易失存储器，在这种设备上，当掉电之后恢复供电时，刷新控制器会刷新所有在电池支的持缓存中等待写入磁盘的数据，这样就确保了所有提交到了易失存储上的数据能够被确实传输到稳定的存储器上，也就是这里说的磁盘设备上。当运行在DRBD设备上层的驱动器能够接受禁用磁盘刷新，那么为了提供DRBD的写性能可能会禁用磁盘刷新。

2.11. 磁盘错误处理策略

如果DRBD节点上的后端块设备(也就是主机上的磁盘)失败，那么DRBD可以将错误传递到上层(通常也就是操作系统层面)，也可以屏蔽上层的I/O错误。

下面来了解一下这两种策略：

 传递I/O错误：DRBD被配置为传递I/O错误，如果任何在低级设备上发生的此类错误那么都将会被传递到上层的I/O层。在这种方式下，错误将会由上层处理，这种方式很有可能会导致文件系统将其挂载为只读系统。使用这个策略不保证服务能够继续提供，因此对于大多数用户来说也不推荐使用这种策略。

 屏蔽I/O错误：DRBD配置为分离底层I/O错误。如果在底层发生第一个低级的I/O错误，DRBD将会分离底层I/O错误。在发生I/O错误错误而被屏蔽时，DRBD将会“透明”(就是说用户或者说用户应用程序不会感觉到错误的存在)的通过网络从对点的块设备操作数据。从发生故障被屏蔽错误时起，DRBD将会运行在无盘模式下，并且所有的I/O子请求操作、读和写，都将会在对点的磁盘上，在这种模式下性能会受到影响，但是服务不会中断，在方便的时候可以将Primary切换到对点。

2.12. 处理过期数据的策略

DRBD需要区分数据不一致(inconsistent)和过期数据(outdated data)。

不一致的数据是不能够被访问的，并且也不能够以任何的方式使用这种数据。在这样的节点上，部分数据已经过时，而部分数据为新更新的数据，或者是无法确定是过期数据或者是新数据。这种情况的数据比较常见的就是处于当前正在进行数据同步的节点，例如：

[root@s69 ~]# cat /proc/drbd
version: 8.2.1 (api:86/proto:86-87)
GIT-hash: 318925802fc2638479ad090b73d7af45503dd184 build by root@s69, 2012-04-20 01:50:18
0: cs:SyncSource st

rimary/Secondary ds:UpToDate/Inconsistent C r---
ns:80896 nr:0 dw:0 dr:80896 al:0 bm:4 lo:0 pe:0 ua:0 ap:0
      [>...................] sync'ed:  0.1% (1907055/1907134)M
      finish: 53:26:36 speed: 10,112 (10,112) K/sec
      resync: used:0/31 hits:5051 misses:5 starving:0 dirty:0 changed:5
      act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0
[root@s69 ~]#

在这种情况下，设备上的文件系统不能被挂载，甚至不能进行自动文件系统检测。

相比之下过期数据是指处于secondary节点的数据是一致的，但是不再和primary节点同步了。这种情况将可能发生在任何复制链路中，有可能是暂时的，也有可能是永久的。一个过期的、被断开的secondary节点上的数据被认为是干净的数据，但是它反映了该节点在某一时刻的状态，为了避免服务使用过期数据，因此DRBD不允许提升一个处于过期数据状态的资源为Primary角色。

DRBD有一个允许外部应用程序在网络一发生中断之后就使得secondary节点数据过时的接口，因此DRBD将会拒绝将该节点切换为Primary节点，阻止了应用程序使用过期数据，这个接口是一个通用接口，其它集群管理应用程序可以很容易的使用它。当一个过期的资源重新建立其复制连接时，那么它的过期标志将自动清除。

2.13. 三路复制

首先需要说明的是从8.3.0开始提供了这个功能，换句话说就是8.3.0之前的版本不提供这个功能。

在使用DRBD的3路复制技术时，DRBD将会在一个已经存在的两个节点的集群上添加第3个节点，并且将数据复制到这个节点上，实现3路复制，也就是做一个备份节点，换句话说，第3个节点就是用来实现备份和用于灾难恢复的目的。这个类型的配置一般来说要使用“使用DRBD代理实现远距离复制”技术。

图解：

从图中可以看到，三路复制的技术是在已经存在的DRBD资源顶层再加出一层，就是说在原有的基础之上再添加一个堆叠的DRBD资源，以便让它来保存环境中的生产数据。

也就是说，在3路复制中由以前的两层结构变为现在的三层结构。

在堆叠资源的复制中使用了异步复制方式(就是DRBD的A协议)，而在生产数据复制中却使用的是同步复制方式(也就是C协议)。

对于3路复制中生产数据和备份节点数据同步有两种选择：

 持久同步：在这种方式中，3路复制将会持久不断的被复制，第3个节点将会持久不断的从生产集群节点上同步更新数据，以便及时的将生成环境中的数据备份到备用服务器上；

 定时同步：3路复制的另一个选择，那就是临时复制，换句话说就是经要求复制，在这种情况下，生成环境中的集群和备份节点一般处于断开状态，按照一定的规律进行同步生产环境的数据，例如可以通过运行定时任务来完成同步(就是通过crontab来完成)；

2.14. 使用DRBD代理实现远距离复制

首先需要说明的是从8.2.7开始提供了这个功能，换句话说就是8.2.7之前的版本不提供这个功能。

DRBD的协议A是一个异步传输协议，但是写应用程序在套接字输出缓存满了那么就将会被阻塞了，发生这种情况后，写应用程序将不得不等待直到某些数据尽可能的通过“窄”带宽(这种情况一般属于不稳定网络，例如共享级别的网络设施)

通常情况下(这里指的是在内部局域网环境下)，网络带宽有效的使用受到写带宽的限制(这里指的是向磁盘写入的速度)，而远程复制则相反，写的速度(这里指的是平均值)受到了网络连接中有效的带宽限制。如果数据适合有限的套接字输出缓存，那么写并发能够被文雅的处理。可以通过DRBD的缓存代理机制能够减轻这种情况，DRBD代理将会把从primary节点的接受到改变的数据放置在它的缓存中。

DRBD代理缓存大小可以自由配置，仅受到地址空间大小和有效物理内存的限制。另外还有一个可选的功能，在DRBD代理中可以配置压缩和解压缩传输中的数据，压缩和解压缩DRBD的数据包可能稍微会增加延时，然而在带宽连接成为限制因素时，压缩和解压缩用去的时间与未使用压缩解压缩相比在总体性能上却有了增益。

在多核SMP系统中要使用压缩和解压缩，它能使用多个CPU内核。实际上如果是CPU资源不紧张的情况下，无论网络状况如何使用压缩和解压缩机制总是没错的，远程复制至少可以节约带宽。

实际上，对于大多数大的是I/O数据块进行压缩是非常正确的，为此有效的减少对带宽的使用，也就是增加了网络带宽，在情况好的时候甚至可以使用DRBD的协议B和C。

需要说明的一点是DRBD代理仅是DRBD产品家族的一个部分，并没有以开源的license形式提供。如果需要那么可以联系sales@linbit.com 或者 sales_us@linbit.com，就是说要收费。

2.15. 基于“运送”的复制

基于“运送”的复制，也就是众所周知的磁盘“运送”(这种方法在使用RAID-1时很容易实现)，就是说在送往远程节点装置的磁盘上已经预置了要同步的数据，将存储数据的介质本身运送到远程节点，这种方法适合的环境为：

 需要复制的数据量相当大(可能大于几百个G)；

 被复制的数据变化量较小；

 两个节点间的网络带宽有限；

在这些环境中，即使遇到其中的一条，那么DRBD将会需要一个很长的初始化设备同步过程(可能需要几天或者几个星期，如果真的需要几个星期，那么甚至就失去了备份的意义)，基于运送的同步，允许用户将数据“种子”预置在远程装置上，这样便会彻底降低了初始化同步数据的时间。

2.16. 浮动对点

首先需要说明的是从8.3.2开始提供了这个功能，换句话说就是8.3.2之前的版本不提供这个功能。

在特殊的情况下，需要将DRBD的对点配置为浮动对点，在浮动对点设置中，DRBD不再将对点指定为一个特定的主机名称(而常规的配置中使用的是主机名称)，取而代之是使用了浮动IP地址，在这种配置中，DRBD通过IP地址来标识对点，而不是使用主机名称。