基于DRBD的高可用NFS解决方案分析

之前对DRBD分析比较多，但是一直没有找到该怎么用他。最近又在看NFS协议（ RFC3530）。分析了NFS4对于的迁移、复制和服务端重启等场景的定义。DRBD提供块设备，其上是文件系统，而NFS在文件系统上层，二者结合可以构建一个高可用的文件共享解决方案。关于DRBD，在之前的博客中有一些分析（tag： DRBD）。对于NFS，从如下示意图可以看出其在系统中的位置：

传统的DAS存储模型：主机直接连接存储设备，使用总线接口进行访问。

 

而对于NAS，同时又客户端和服务端，二者使用以太网进行连接，最新的NFS4版本基于TCP/IP协议。

NFS在网络分层模型中的位置：

 

这样DRBD相当于提供了底层的存储设备，虚拟出块设备来，在该块设备上面建立文件系统，再将该文件系统上的目录共享为NFS服务，这样客户端就可以通过NFS来访问一个DRBD提供的网络镜像硬盘，当一端故障时，倒换，另一端还能继续访问。

我们知道，对于本地文件系统，只要知道文件的FID就可以访问文件的inode结构，进而操作文件。但是NFS则不一样，NFS的文件系统是虚拟出来的，在服务端，可能有多个文件系统中存在相同的FID，因此必须用一个唯一标识一个文件的句柄，这个句柄就是由FSID和FID来组成。

再来看这里的高可用解决方案，DRBD是对整个块设备进行了实时复制，那么文件系统在双机的两端应该也是完全一致的。如果两台主机共用一个浮动IP，由DRBD的主端来决定浮动IP绑定到哪一端。当发生倒换时，原主端的DRBD镜像出来的共享硬盘设备切换到对端，在对端重新挂载，然后再启动NFS服务，这样其实就相当于是NFS服务进程在本端重启了一次，对于重启，协议有明确的grace time定义，只要服务端和客户端按此实现，那么对于客户端的上层应用这个倒换是不感知的。当客户端重新以其持有的NAS FH访问文件时，在对端仍然能解析出FSID和FID，同样找到具体的文件来访问。

整个想法理论上面来说应该是没有问题。开始搭建这样一个验证环境。按照： DRBD远程实时双机热备系统配置完全手册文章介绍的步骤配置DRBD，挂载到本地/drbd目录，然后在NFS的配置文件中配置导出该目录。另起一个虚拟机，作为客户端，通过浮动IP挂载该共享目录，并开启复制一个大文件到该目录的过程，这样模拟业务在线。

在此过程中，进行DRBD、NFS和浮动IP的倒换。倒换流程：

1、停止主端NFS
2、倒换DRBD到对端
3、对端启动NFS服务
4、切换浮动IP地址到到对端

预期在经过了NFS服务的静默期后，原来的大文件操作仍然能继续。客户端不会提示任何错误。

实际的结果是，客户端提示NFS句柄无效。 本来还想找更高版本的Linux系统，验证NFS4版本是否能支持，但是由于Linux高版本中DRBD配置一直没有搞定，没能成功。但是一想，其实都是RPC，都是基于NAS FH，并不是协议的问题。DRBD设备上面的文件系统是挂载在系统宿主文件系统上面的，有一个块设备文件到文件系统的转换过程，对于NFS服务，根本看不到原来的DRBD设备上面的文件系统，看到的还是根文件系统。虽然DRBD是保证了文件系统的完全镜像，但是挂载之后，二者的inode分配并不一致，因此在解析客户端传过来的FH时，也是无法找到具体的文件的。以后有空可以分析一下NFS的源码，看能否通过其他方式实现直接共享DRBD设备上面的文件系统的内容，而不是通过挂载到宿主文件系统再共享的方式。

参考页面：

1、NFS4文件锁机制探秘 http://www.cnblogs.com/zhenjing/archive/2011/05/15/NFS4_lock.html
2、关于NFS http://blog.yikuyiku.com/?tag=nfsv4
3、NFSv4 提供无缝的网络访问 http://www.ibm.com/developerworks/cn/linux/l-nfsv4.html
4、NFS文件句柄 http://blog.csdn.net/ycnian/article/details/8506704