之前写过两篇关于MooseFS的相关概念以及操作管理的BLOG，我们可以看到MFS一些好的地方，比如：通过copy数来保证数据的可靠存，当MFS系统中有个别chunkserver宕机发生，也不会影响应用的正常使用；同时，相比ext3它还能节省存储空间。这里说到，“可靠”，并非这个系统就真的如想象一样，和NFS相比的确，多份copy确实可靠了不少，但是它们都有一个共同的问题，那就是主控server的单点问题。MFS系统中，即便有metalogger server的这个作为master的角色，但问题依然存在。下面就说说使用中的体会。

问题：当mfsmaster主机发生问题，按照MFS系统的提供的故障切换方法，mfsmetalogger主机会被提升为mfsmaster，继续提供服务，服务是能够提供，但是，如果你真的实际操作过，就知道后续你要做多少动作。当你的mfsmaster发生变化，意味着你的主机IP已经改变，那么相应所有挂载的client端，必须要重新连接新的master_host重新挂载一次。你可能会认为以下方法可行。

理想中的方法：

1. 将mfsmount命令中的选项-H的参数采用DNS域名的方式，这样域名始终不变而是IP发生变化，这对于使用者来说是透明的，是这样吧？

2. 有的人可能会说，不用这么麻烦，我们可以调换原mfsmaster与mfsmetalogger的IP不就行了吗？但是，实际工作中，你没权这么改，也不能这么做，公司中这些资源都是由专属部分统一管理，你方便了但是给别的同事带来了麻烦。

下面说说目前我们采用的方法，这个方法在我们看来，所使用的技术都是熟悉的而且是可控的；在和田老师商量之后，采用DRBD来做mfsmaster端的高可用。

先来说说上面提到的方法1为什么不行，原因很简单，因为在client端，mfsmount命令执行挂载后，它cache住的是mfsmaster主机的IP地址，这是根源所以在，导致你不能简单靠域名来解决这个变的问题。既然，知道了根源，那么我们的解决办法应该，放到mfsmaster端来思考方法。要求提供mfsmaster服务的主机IP不变，那么自然我们想到采用虚IP这种方式，VIP在两台真实主机间随时准备故障切换，但整个服务对外始终呈现的是一个IP。能够实现这个的需求的，目前市面上流行的方法也不少，比如：keepalive、heartbeat。keepalive从来没接触过，听不少人说keepalive的使用相比heartbeat要简单很多，计划现学又需要时间弄的差多吧又需要一定的精力，有点懒了也不想弄那么多了，把眼前这点东西看住了就不小了。加之之前，所有的MySQL高可用都是用DRBD搭建的，对heartbeat还是比较熟悉的，经过测试之后，最后选择了DRBD+Heartbeat+MFS来实现MooseFS系统的完全高可用。目前DRBD这个方案，也有点我不太特别舒服的地方，就是heartbeat故障切换使用style 1的，并不是基于服务监控，而是通过主机整体网络环境状况判断故障切换，细想想这其中还是有一些不妥的问题。搭过DRBD+Heartbeat+MySQL的，对于记下来要所的MFS的DRBD应用就没什么难度，下面就一些个人觉得有必须提的一些配置。

DRBD

将原有MFS系统中的mfsmetalogger角色去掉，而是将原mfsmetalogger变成现有mfsmaster的备机。

Heartbeat

# cat /etc/ha.d/haresources

mfsmaster-a drbddisk::r0 Filesystem::/dev/drbd0::/mfsconf  VIP MFSMaster

#cat /etc/ha.d/resource.d/MFSMaster

/usr/sbin/mfsmaster -c /mfsconf/mfsmaster.cfg $1

MooseFS

将原来/etc目录下的mfsmaster.cfg、mfsexports.cfg配置文件，以及/var/lib/mfs目录下的数据文件，存储到drbd分区上；至于lock文件，在1.7以后将被废除使用，目前我们是1.6的版本，我没有将LOCK_FILE存到drbd分区上，之前在测试的时候，有试过的，当启动mfsmaster服务时，提示不能找到lock文件。其实，当你去查看默认的LOCK_FILE的存放位置时，并不存在的（一个服务启动时，需要创建的这个socket文件，有什么用途呢？除了通信意外，…）。

#vi mfsmaster.cfg

EXPORTS_FILENAME = /mfsconf/mfsexports.cfg

DATA_PATH = /mfsconf

目前，我们的MooseFS主要提供内部备份使用，并没有任何线上使用，这套MFS的HA方案完全符合我们的需要，虽说仅用于备份的MFS，也无需多么高的可靠性，但是这最大的方便是当mfsmaster故障后可以减少很多后续人为的操作，减少了我们你的工作量。:)

建议继续学习：

1. MooseFS知多少    (阅读：4962)
2. Heartbeat+DRBD+MySQL Replication故障处理    (阅读：2421)
3. 关于DRBD与Heartbeat的一些思考    (阅读：1923)
4. DRBD远程实时双机热备系统配置完全手册    (阅读：1054)
5. 基于DRBD的高可用NFS解决方案分析    (阅读：925)
6. MooseFS之虚拟机惹的祸    (阅读：884)