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

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

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

 

local

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

nfs_stack

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

nfscomponents

这样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

Tagged: ,

Comments are closed.