DRBD和Heartbeat这两个用于实现高可用的组合,折腾了有一周了，从开始的新鲜到配置成功的兴奋再到遇到问题的苦闷最后还是在其中一点点的被纠结着，似懂非懂中迷茫着，似乎从小到大没有一件事能做得明白的，稀里糊涂得就奔着三十去了。下面就把这一周里遇到的疑惑，抖露抖露，大家也给点力，说说你们的理解。

DRBD是个什么东西――Distributed Replicated Block Device，这4个英文单词说的很明白，BD说明要实现这个功能首先要是块设备，我们常用的磁盘就是块设备，R就是通过复制来保证两个块设备上的数据一致，通过网络（TCP/IP）传输，所以又被称为网络版的RAID1，D体现在数据同时被存放到主与备这两种角色的主机上，每个主机都是独立的，没有共享的部分，被称为share-nothing，MySQL都是share-nothing的东西（话说，我们的MySQL Cluster），和其相对的就是share-everything，Oracle的高可用策略，共享存储，想做RAID几您随便，再想想我们的DRBD又是网络又是一会你现身了一会我又消失了一顿折腾，再一不小心变成SB（Splite Brain）了,突然感觉到还是人家花钱的东西好呀。DRBD中有好些个名词，需要我们好好去品味，下面这些是通过实际操作和文档学习个人的一些理解，可能有些不完全正确，请大家理性的分辨。

virtual block device ― 对应配置drbd.conf中的device的配置/dev/drbdN(N从0开始到147止)，其实，这就是一个指向真是设备的路径名称。

lower-level device  ― 这个就是真实的物理设备，就是drbd.conf中disk对应的行。

resource ― DRBD把配置的块设备称为自己的资源，它可以配置多个资源，Heartbeat中也有资源这个概念，DRBD被看作其中的一种资源。

metadata ― 记录着DRBD相关的一些信息，就像MySQL中INFORMATION_SCHEMA的作用。

role ― 角色，在DRBD中分为Primary（主）和Secondary（备）两个角色，主上的资源可读可写，而备上的资源“不可见”，你会想了，难道只读都不行吗？在DRBD的文档中给了如下的解释:(The reason for disallowing even read-only access to the device is the necessity to maintain cache coherency, which would be impossible if a secondary resource were made accessible in any way.)。其中，cache coherency我不是太理解，但与群里的chen（陈红卫）聊过之后，得出这么两个：一是怕某种层度会影响写，再有就是有可能是考虑到会出现脏读的情况。

关于DRBD首页的那个内部解剖图，上面有一个部分（RAW DEVICE），我不是太明白，再与chen以及公司资深的同事聊过之后，都没有得到一个很好的解释，不知道它在配置或是在实际内部运行时体现在什么哪里。在文档Chapter 5. Configuring DRBD-The initial device synchronization这个部分中，有这么一句话提到了raw device这两个单词(You may now create a filesystem on the device, use it as a raw block device, mount it, and perform any other operation you would with an accessible block device.)。

接下来说说，Heartbeat的困惑。这个东西听起来感觉，应该蛮“智能”的现代化呀，但就是它的这点智能这两天快把我搞疯了，每次看着它的日志，真让您愁的不行，资源被它搞忽左忽右，一会主释放，备获得，一会备又发现不对劲释放，主又将所有资源开启，飘忽呀！弄得我都崩溃了，来来回回瞎折腾什么呀，auto_failback = off吃屎呢，更然人郁闷的是测试十次竟然还让你看到一次成功，玩人呢！都是浮云，算了，不想了，最后自己弄了脚步，设了个逻辑，做故障切换。

Heartbeat的故障切换的实验，我是这样做的，主（drbd-one）和备（drbd-two），将主上的eth0宕掉，然后，“希望”heartbeat能，将主上资源释放（包括角色降价primary变成secondary），同时备获得资源（包括角色升级secondary变成primary），当我将主上的eth0网卡重新开启以后，“希望”角色维持在当前，同时drbd的状态恢复正常保持同步一致，郁闷的是，多少情况都是drbd-one为Secondary/Unknown，drbd-two为Primary/Unknown，这是比较幸运的呢，有的时候会是两个主机的状态都是Secondary/Unknown或是Primary/Unknown，这时你就看它的日志吧，在哪里纠结的资源过去回来、回来过去。最后，决定自己弄个逻辑简单的脚本去控制故障切换好了，在和公司田老师的讨论之后，通过一个脚步和一个单向的逻辑来实现。

该脚本只放在备机（drbd-two）上，通过while循环设置每60秒检查一次主与备的状态，在为发生获得资源的动作前一直运行检查，通过判断drbd角色状态确定主（drbd-one）是否正常（“/”后面为对方状态），当发现主的状态为Uknown，说明网络出现故障，这时升级角色获得资源，并发出报警邮件通知DBA，接下来的工作就又人为来干预，对主进行降级操作，由primary变成secondary，同时释放之前的资源，最后将eth0成功up。当我们再去执行cat /proc/drbd看到的时候，drbd状态正常，不会是之前的一个杯具了。开始怀疑Heartbeat的可用性，对于我的配置难道还有什么不妥的地方吗，大家可以从我之前的一篇文章得到我配置heartbeat的步骤，帮我找找问题。

对于Heartbeat在ha.cf中的配置有这么一行(respawn hacluster /usr/lib/heartbeat/ipfail)中，提到了这么一个工具ipfail，我也在网上看了一些文章的介绍，但是还不是不知道这个脚步到底是做什么的，什么时候会用到。 如有朋友知道，麻烦回复赐教。

期待听到新的见解… …（给力！）

建议继续学习：

1. Heartbeat+DRBD+MySQL Replication故障处理    (阅读：2452)
2. DRBD使MooseFS跑得更安全    (阅读：1912)
3. DRBD远程实时双机热备系统配置完全手册    (阅读：1207)
4. 基于DRBD的高可用NFS解决方案分析    (阅读：1095)