heartbeat原理介绍

HeartBeat运行于备用主机上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的"心跳"则自动接管主服务器的资源。通常情况下，主、备服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由"交叉线"实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。从实践经验的角度来说，建议为Heartbeat配置多条独立的物理连接，以避免Heartbeat通信线路本身存在单点故障。

1、串行电缆：被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。

2、以太网连接：使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主备服务器间同步文件系统，从而减少了从正常通信连接带宽的占用。

基于冗余的角度考虑，应该在主、备服务器使用两个物理连接传输heartbeat的控制信息；这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的"脑裂"（split-brain）或"partitioned cluster"。在两个节点共享同一个物理设备资源的情况下，脑裂会产生相当可怕的后果。

为了避免出现脑裂，可采用下面的预防措施：

1、如前所述，在主、备节点间建立一个冗余的、可靠的物理连接来同时传送控制信息；

2、一旦发生脑裂时，借助额外设备强制性地关闭其中一个节点；

第二种方式即是俗称的"将其它节点'爆头'（shoot the other node in the head）"，简称为STONITH。基于能够通过软件指令关闭某节点特殊的硬件设备，Heartbeat即可实现可配置的Stonith。但当主、备服务器是基于WAN进行通信时，则很难避免"脑裂"情景的出现。因此，当构建异地"容灾"的应用时，应尽量避免主、备节点共享物理资源。

Heartbeat的控制信息：

"心跳"信息: （也称为状态信息）仅150 bytes大小的广播、组播或多播数据包。可为以每个节点配置其向其它节点通报"心跳"信息的频率，以及其它节点上的heartbeat进程为了确认主节点出节点出现了运行等错误之前的等待时间。

集群变动事务（transition）信息：ip-request和ip-request-rest是相对较常见的两种集群变动信息，它们在节点间需要进行资源迁移时为不同节点上heartbeat进程间会话传递信息。比如，当修复了主节点并且使其重新"上线"后，主节点会使用ip-request要求备用节点释放其此前从因主节点故障而从主节点那里接管的资源。此时，备用节点则关闭服务并使用ip-request-resp通知主节点其已经不再占用此前接管的资源。主接点收到ip-request-resp后就会重新启动服务。

重传请求：在某集群节点发现其从其它节点接收到的heartbeat控制信息"失序"（heartbeat进程使用序列号来确保数据包在传输过程中没有被丢弃或出现错误）时，会要求对方重新传送此控制信息。 Heartbeat一般每一秒发送一次重传请求，以避免洪泛。

上面三种控制信息均基于UDP协议进行传送，可以在/etc/ha.d/ha.cf中指定其使用的UDP端口或者多播地址（使用以太网连接的情况下）。

此外，除了使用"序列号/确认"机制来确保控制信息的可靠传输外，Heartbeat还会使用MD5或SHA1为每个数据包进行签名以确保传输中的控制信息的安全性。

资源脚本：

资源脚本（resource scripts）即Heartbeat控制下的脚本。这些脚本可以添加或移除IP别名（IP alias)或从属IP地址（secondary IP address），或者包含了可以启动/停止服务能力之外数据包的处理功能等。通常，Heartbeat会到/etc/init.d/或/etc/ha.d/resource.d/目录中读取脚本文件。Heartbeat需要一直明确了解"资源"归哪个节点拥有或由哪个节点提供。在编写一个脚本来启动或停止某个资源时，一定在要脚本中明确判断出相关服务是否由当前系统所提供。

Heartbeat的配置文件：

/etc/ha.d/ha.cf

定义位于不同节点上的heartbeat进程间如何进行通信；

1.3.1 配置ha.cf文件 ha.cf是heartbeat的主要配置文件，可以对heartbeat的多数性能和状态进行配置。大部分选项的取值可以采用默认值，其中的主要选项及配置方法说明如下： debugfile /var/log/ha-debug：该文件保存heartbeat的调试信息 logfile /var/log/ha-log：heartbeat的日志文件 keepalive 2：心跳的时间间隔，默认时间单位为秒 deadtime 30：超出该时间间隔未收到对方节点的心跳，则认为对方已经死亡。 warntime 10：超出该时间间隔未收到对方节点的心跳，则发出警告并记录到日志中。 initdead 120：在某些系统上，系统启动或重启之后需要经过一段时间网络才能正常工作，该选项用于解决这种情况产生的时间间隔。取值至少为deadtime的两倍。 udpport 694：设置广播通信使用的端口，694为默认使用的端口号。 baud 19200：设置串行通信的波特率。 serial /dev/ttyS0：选择串行通信设备，用于双机使用串口线连接的情况。如果双机使用以太网连接，则应该关闭该选项。 bcast eth0：设置广播通信所使用的网络接口卡。 auto_failback on：heartbeat的两台主机分别为主节点和从节点。主节点在正常情况下占用资源并运行所有的服务，遇到故障时把资源交给从节点并由从节点运行服务。在该选项设为on的情况下，一旦主节点恢复运行，则自动获取资源并取代从节点，否则不取代从节点。 ping ping-node1 ping-node2：指定ping node，ping node并不构成双机节点，它们仅仅用来测试网络连接。 respawn hacluster /usr/lib/heartbeat/ipfail：指定与heartbeat一同启动和关闭的进程，该进程被自动监视，遇到故障则重新启动。最常用的进程是ipfail，该进程用于检测和处理网络故障，需要配合ping语句指定的ping node来检测网络连接。

/etc/ha.d/haresources

定义对某个资源来说哪个服务器是主节点，以及哪个节点应该拥有客户端访问资源时的目标IP地址。 authkeys文件用于heartbeat的鉴权设置，共有三种可用的鉴权方式：crc、md5和sha1。三种方式安全性依次提高，但同时占用的系统资源也依次扩大。crc安全性最低，适用于物理上比较安全的网络，sha1提供最为有效的鉴权方式，占用的系统资源也最多。 其配置语句格式如下： auth <number> <number> <authmethod> [<authkey>] 举例说明： auth 1 1 sha1 key-for-sha1 其中键值key-for-sha1可以任意指定，number设置必须保证上下一致。 auth 2 2 crc crc方式不需要指定键值。

/etc/ha.d/authkeys

定义Heartbeat包在通信过程中如何进行加密。

当ha.cf或authkeys文件发生改变时，需要重新加载它们就可以使用之生效；而如果haresource文件发生了改变，则只能重启heartbeat服务方可使之生效。

尽管Heartbeat并不要求主从节点间进行时钟同步，但它们彼此间的时间差距不能超过1分钟，否则一些配置为高可用的服务可能会出异常。

Heartbeat当前也不监控其所控制的资源的状态，比如它们是否正在运行，是否运行良好以及是否可供客户端访问等。要想监控这些资源，冉要使用额外的Mon软件包来实现。

haresources配置文件介绍：

主从节点上的/etc/ra.d/raresource文件必须完全相同。文件每行通常包含以下组成部分：

1、服务器名字：指正常情况下资源运行的那个节点（即主节点），后跟一个空格或tab；这里指定的名字必须跟某个节点上的命令"uname -n"的返回值相同；

2、IP别名（即额外的IP地址，可选）：在启动资源之前添加至系统的附加IP地址，后跟空格或tab；IP地址后面通常会跟一个子网掩码和广播地址，彼此间用"/"隔开；

3、资源脚本：即用来启动或停止资源的脚本，位于/etc/init.d/或/etc/ha.d/resourcd.d目录中；如果需要传递参数给资源脚本，脚本和参数之间需要用两个冒号分隔，多个参数时彼此间也需要用两个冒号分隔；如果有多个资源脚本，彼此间也需要使用空格隔开； haresources文件用于指定双机系统的主节点、集群IP、子网掩码、广播地址以及启动的服务等。其配置语句格式如下： node-name network-config <resource-group> 其中node-name指定双机系统的主节点，取值必须匹配ha.cf文件中node选项设置的主机名中的一个，node选项设置的另一个主机名成为从节点。 network-config用于网络设置，包括指定集群IP、子网掩码、广播地址等。resource-group用于设置heartbeat启动的服务，该服务最终由双机系统通过集群IP对外提供。

格式如下：

primary-server [IPaddress[/mask/interface/broadcast]] resource1[::arg1::arg2] resource2[::arg1::arg2]

例如：

primary-server 221.67.132.195 sendmail httpd

HA的LVS集群有两台Director，在启动时，主节点占有集群负载均衡资源（VIP和LVS的转发及高度规则），备用节点监听主节点的"心跳"信息并在主节点出现异常时进行"故障转移"而取得资源使用权，这包括如下步骤：

1、添加VIP至其网络接口；

2、广播GARP信息，通知网络内的其它主机目前本Director其占有VIP；

3、创建IPVS表以实现入站请求连接的负载均衡；

4、Stonith；

弃用resource脚本，改用ldirecotord来控制LVS：

ldirectord用来实现LVS负载均衡资源的在主、备节点间的故障转移。在首次启动时，ldirectord可以自动创建IPVS表。此外，它还可以监控各Realserver的运行状态，一旦发现某Realserver运行异常时，还可以将其从IPVS表中移除。

ldirectord进程通过向Realserver的RIP发送资源访问请求并通过由Realserver返回的响应信息来确定Realserver的运行状态。在Director上，每一个VIP需要一个单独的ldirector进程。如果Realserver不能正常响应Directord上ldirectord的请求，ldirectord进程将通过ipvsadm命令将此Realserver从IPVS表中移除。而一旦Realserver再次上线，ldirectord会使用正确的ipvsadm命令将其信息重新添加至IPVS表中。

例如，为了监控一组提供web服务的Realserver，ldirectord进程使用HTTP协议请求访问每台Realserver上的某个特定网页。ldirectord进程根据自己的配置文件中事先定义了的Realserver的正常响应结果来判断当前的返回结果是否正常。比如，在每台web服务器的网站目录中存放一个页面".ldirector.html"，其内容为"GOOD"，ldirectord进程每隔一段时间就访问一次此网页，并根据获取到的响应信息来判断Realserver的运行状态是否正常。如果其返回的信息不是"GOOD"，则表明服务不正常。

ldirectord需要从/etc/ha.d/目录中读取配置文件，文件名可以任意，但建议最好见名知义。

实现过程：

创建/etc/ha.d/ldirectord-192.168.0.219.cf，添加如下内容： 

Global Directives

checktimeout=20

ldirectord等待Realserver健康检查完成的时间，单位为秒；

任何原因的检查错误或超过此时间限制，ldirector将会将此Realserver从IPVS表中移除；

checkinterval=5

每次检查的时间间隔，即检查的频率；

autoreload=yes

此项用来定义ldirectord是否定期每隔一段时间检查此配置文件是否发生改变并自动重新加载此文件；

logfile="/var/log/ldirectord.log"

定义日志文件存放位置；

quiescent=yes

当某台Realserver出现异常，此项可将其设置为静默状态（即其权重为"0"）从而不再响应客户端的访问请求；

For an http virtual service

virtual=192.168.0.219:80

此项用来定义LVS服务及其使用的VIP和PORT

real=192.168.0.221:80 gate 100

定义Realserver，语法：real=RIP:port gate|masq|ipip [weight]

real=192.168.0.223:80 gate 300

fallback=127.0.0.1:80 gate

当IPVS表没有任何可用的Realserver时，此"地址：端口"作为最后响应的服务；

一般指向127.0.0.1，并可以通过一个包含错误信息的页面通知用户服务发生了异常；

service=http

定义基于什么服务来测试Realserver；

request=".ldirectord.html"

receive="GOOD"

scheduler=wlc

#persistent=600

#netmask=255.255.255.255

protocol=tcp

定义此虚拟服务用到的协议；

checktype=negotiate

ldirectord进程用于监控Realserver的方法；{negotiate|connect|A number|off}

checkport=80

在/etc/hd.d/haresources中添加类似如下行：

node1.example.com 192.168.0.219 ldirectord::ldirectord-192.168.0.219.cf  

DRBD详细说明 

一、主要功能

    DRBD实际上是一种块设备的实现,主要被用于Linux平台下的高可用(HA)方案之中。他是有内核模块和相关程序而组成，通过网络通信来同步镜像整个设备，有点类似于一个网络RAID的功能。也就是说当你将数据写入本地的DRBD设备上的文件系统时,数据会同时被发送到网络中的另外一台主机之上，并以完全相同的形式记录在一个文件系统中（实际上文件系统的创建也是由DRBD的同步来实现的）。本地节点（主机）与远程节点（主机）的数据可以保证实时的同步，并保证IO的一致性。所以当本地节点的主机出现故障时,远程节点的主机上还会保留有一份完全相同的数据,可以继续使用，以达到高可用的目的。

    在高可用(HA)解决方案中使用DRBD的功能,可以代替使用一个共享盘阵存储设备。因为数据同时存在于本地主机和远程主机上,在遇到需要切换的时候,远程主机只需要使用它上面的那份备份数据,就可以继续提供服务了。 

二、底层设备支持

    DRBD需要构建在底层设备之上，然后构建出一个块设备出来。对于用户来说，一个DRBD设备，就像是一块物理的磁盘，可以创建文件系统。DRBD所支持的底层设备有以下这些类：

    1、一个磁盘，或者是磁盘的某一个分区；

    2、一个soft raid 设备；

    3、一个LVM的逻辑卷；

    4、一个EVMS（Enterprise Volume Management System，企业卷管理系统）的卷；

    5、其他任何的块设备。 

三、配置简介

    1、全局配置项（global）

        基本上我们可以做的也就是配置usage-count是yes还是no了，usage-count参数其实只是为了让linbit公司收集目前drbd的使用情况。当drbd在安装和升级的时候会通过http协议发送信息到linbit公司的服务器上面。

    2、公共配置项（common）

        这里的common，指的是drbd所管理的多个资源之间的common。配置项里面主要是配置drbd的所有resource可以设置为相同的参数项，比如protocol，syncer等等。

    3、资源配置项（resource）

        resource项中配置的是drbd所管理的所有资源，包括节点的ip信息，底层存储设备名称，设备大小，meta信息存放方式，drbd对外提供的设备名等等。每一个resource中都需要配置在每一个节点的信息，而不是单独本节点的信息。实际上，在drbd的整个集群中，每一个节点上面的drbd.conf文件需要是完全一致的。

        另外，resource还有很多其他的内部配置项：

        net：网络配置相关的内容，可以设置是否允许双主节点（allow-two-primaries）等。

        startup：启动时候的相关设置，比如设置启动后谁作为primary（或者两者都是primary：become-primary-on both）

        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 值：drbdsetup /dev/drbd0 syncer -r 100M。这样就临时的设置了re-synchronization的速度为100M。不过在re-synchronization结束之后，你需要通过 drbdadm adjust resource_name 来让drbd按照配置中的rate来工作。 

四、资源管理

    1、增加resource的大小：

     当遇到我们的drbd resource设备容量不够的时候，而且我们的底层设备支持在线增大容量的时候（比如使用lvm的情况下），我们可以先增大底层设备的大小，然后再通过 drbdadm resize resource_name来实现对resource的扩容。但是这里有一点需要注意的就是只有在单primary模式下可以这样做，而且需要先在所有节点上都增大底层设备的容量。然后仅在primary节点上执行resize命令。在执行了resize命令后，将触发一次当前primary节点到其他所有secondary节点的re-synchronization。

     如果我们在drbd非工作状态下对底层设备进行了扩容，然后再启动drbd，将不需要执行resize命令（当然前提是在配置文件中没有对disk参数项指定大小），drbd自己会知道已经增大了容量。

     在进行底层设备的增容操作的时候千万不要修改到原设备上面的数据，尤其是drbd的meta信息，否则有可能毁掉所有数据。

    2、收缩resource容量：

    容量收缩比扩容操作要危险得多，因为该操作更容易造成数据丢失。在收缩resource的容量之前，必须先收缩drbd设备之上的容量，也就是文件系统的大小。如果上层文件系统不支持收缩，那么resource也没办法收缩容量。

    如果在配置drbd的时候将meta信息配置成internal的，那么在进行容量收缩的时候，千万别只计算自身数据所需要的空间大小，还要将drbd的meta信息所需要的空间大小加上。

    当文件系统收缩好以后，就可以在线通过以下命令来重设resource的大小：drbdadm -- --size=***G resize resource_name。在收缩的resource的大小之后，你就可以自行收缩释放底层设备空间（如果支持的话）。

    如果打算停机状态下收缩容量，可以通过以下步骤进行：

        a、在线收缩文件系统

        b、停用drbd的resource：drbdadm down resourcec_name

        c、导出drbd的metadata信息（在所有节点都需要进行）：drbdadm dump-md resource_name > /path_you_want_to_save/file_name

        d、在所有节点收缩底层设备

        e、更改上面dump出来的meta信息的la-size-sect项到收缩后的大小（是换算成sector的数量后的数值）

        f、如果使用的是internal来配置meta-data信息，则需要重新创建meta-data:drbdadm create-md resource_name

        g、将之前导出并修改好的meta信息重新导入drbd（摘录自linbit官方网站的一段导入代码）： 

              drbdmeta_cmd=$(drbdadm -d dump-md test-disk)

              ${drbdmeta_cmd/dump-md/restore-md} /path_you_want_to_save/file_name

       h、启动resource：drbdadm up resource_name 

五、磁盘损坏

    1、detach resource

        如果在resource的disk配置项中配置了on_io_error为pass_on的话，那么drbd在遇到磁盘损坏后不会自己detach底层设备。也就是说需要我们手动执行detach的命令（drbdadm detach resource_name），然后再查看当前各节点的ds信息。可以通过cat /proc/drbd来查看，也可以通过专有命令来查看：drbdadm dstat resource_name。当发现损坏的那方已经是Diskless后，即可。如果我们没有配置on_io_error或者配置成detach的话，那么上面的操作将会由自动进行。

        另外，如果磁盘损坏的节点是当前主节点，那么我们需要进行节点切换的操作后再进行上面的操作。

    2、更换磁盘

        当detach了resource之后，就是更换磁盘了。如果我们使用的是internal的meta-data，那么在换好磁盘后，只需要重新创建mata-data（drbdadm create-md resource_name），再将resource attach上（drbdadm attach resource_name），然后drbd就会马上开始从当前primary节点到本节点的re-synchronisation。数据同步的实时状况可以通过 /proc/drbd文件的内容获得。

        不过，如果我们使用的不是internal的meta-data保存方式，也就是说我们的meta-data是保存在 resource之外的地方的。那么我们在完成上面的操作（重建meta-data）之后，还需要进行一项操作来触发re- synchnorisation，所需命令为：drbdadminvalidate resource_name 。 

六、节点crash（或计划内维护）

    1、secondary节点

        如果是secondary接待你crash，那么primary将临时性的与secondary断开连接，cs状态应该会变成 WFConnection，也就是等待连接的状态。这时候primary会继续对外提供服务，并在meta-data里面记录下从失去secondary 连接后所有变化过的block的信息。当secondary重新启动并连接上primary后，primary -> secondary的re-synchnorisation会自动开始。不过在re-synchnorisation过程中，primary和 secondary的数据是不一致状态的。也就是说，如果这个时候primary节点也crash了的话，secondary是没办法切换成 primary的。也就是说，如果没有其他备份的话，将丢失所有数据。

    2、primary节点

        一般情况下，primary的crash和secondary的crash所带来的影响对drbd来说基本上是差不多的。唯一的区别就是需要多操作一步将secondary节点switch成primary节点先对外提供服务。这个switch的过程drbd自己是不会完成的，需要我们人为干预进行一些操作才能完成。当crash的原primary节点修复并重新启动连接到现在的primary后，会以secondary存在，并开始re-synchnorisation这段时间变化的数据。

        在primary节点crash的情况下，drbd可以保证同步到原secondary的数据的一致性，这样就避免了当 primary节点crash之后，secondary因为数据的不一致性而无法switch成primary或者即使切换成primary后因为不一致的数据无法提供正常的服务的问题。

    3、节点永久性损坏（需要更换机器或重新安装相关软件的情况）

        当某一个节点因为硬件（或软件）的问题，导致某一节点已经无法再轻易修复并提供服务，也就是说我们所面对的是需要更换主机（或从 OS层开始重新安装）的问题。在遇到这样的问题后，我们所需要做的是重新提供一台和原节点差不多的机器，重新开始安装os，安装相关软件，从现有整提供服务的节点上copy出drbd的配置文件（/etc/drbd.conf），创建meta-data信息，然后启动drbd服务，以一个 secondary的身份连接到现有的primary上面，后面就会自动开始re-synchnorisation。 

七、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问题，具体解决策略是根据配置中的设置来进行的。

      如果没有配置split brain自动解决方案，我们可以手动解决。首先我们必须要确定哪一边应该作为解决问题后的rimary，一旦确定好这一点，那么我们同时也就确定接受丢失在split brain之后另外一个节点上面所做的所有数据变更了。当这些确定下来后，我们就可以通过以下操作来恢复了：

    a、首先在确定要作为secondary的节点上面切换成secondary并放弃该资源的数据：

        drbdadm secondary resource_name

        drbdadm -- --discard-my-data connect resource_name

    b、在要作为primary的节点重新连接secondary（如果这个节点当前的连接状态为WFConnection的话，可以省略）  drbdadm connect resource_name

    当作完这些动作之后，从新的primary到secondary的re-synchnorisation会自动开始。 

八、meta data存放地点的比较

    1、internal meta-data（meta-data和数据存放在同一个底层设备之上）

    优点：一旦meta-data创建之后，就和实际数据绑在了一起，在维护上会更简单方便，不用担心meta-data会因为某些操作而丢失。另外在硬盘损坏丢失数据的同时，meta-data也跟着一起丢失，当更换硬盘之后，只需要执行重建meta-data的命令即可，丢失的数据会很容易的从其他节点同步过来。

    缺点：如果底层设备是单一的磁盘，没有做raid，也不是lvm等，那么可能会造成性能影响。因为每一次写io都需要更新meta- data里面的信息，那么每次写io都会有两次，而且肯定会有磁头的较大寻道移动，因为meta-data都是记录在dice设备的最末端的，这样就会造成写io的性能降低。

    2、external meta data（meta-data存放在独立的，与存放数据的设备分开的设备之上）

    优点：与internal meta-data的缺点完全相对，可以解决写io的争用问题。

    缺点：由于meta-data存放在与数据设备分开的地方，就意味着当磁盘损坏更换磁盘之后，必须手动发起全量同步的操作。也就是管理维护会稍微麻烦那么一点点，很小的一点点。

    如果我们希望在已经存在数据的设备上面建立drbd的资源，并且不希望丢失该设备上面的数据，又没办法增大底层设备的容量，而且上层文件系统又没办法收缩的话，我们就只能将meta data创建成external方式。