DRBD-based high availability NFS solution analysis

Previously, more DRBD analysis, but did not find what to use him. Recently I have seen the NFS protocol (RFC3530). The definitions of the scenes such as migration, replication, and server restart are analyzed. DRBD provides block devices, which are file systems, while NFS is on the upper layer of the file system, and both can build a highly available file sharing solution. About DRBD, there are some analyzes (Tag: DRBD) in the previous blog. For NFS, you can see the location in the system from the following schematic:

Traditional DAS Storage Model: The host directly connects the storage device and use the bus interface to access.

For NAS, both the client and the server, both Ethernet are connected, and the latest NFS4 version is based on TCP / IP protocol.

NFS location in the network layering model:

Such a DRBD is equivalent to providing the underlying storage device, the virtual outbound device, establishes a file system on the block device, and then shares the directory on the file system to NFS service so that the client can access a DRBD through NFS. The network mirror hard drive provided, when one end is faulty, the switchover, the other end can continue to access.

We know that for local file systems, as long as you know the file’s FID, you can access the file’s inode structure, and then operate files. However, NFS is different. NFS’s file system is virtual, on the server, there may be the same FID in multiple file systems, so you must use a uniquely identifiable handle, this handle is FSID and FID. composition.

Look at the high available solution here, DRBD is a real-time copying of the entire block device, then the two ends of the file system should be completely consistent. If the two hosts share a floating IP, which ends from the main end of the DRBD determines which end of the floating IP bind. When the switch is switched, the shared hard disk device from the original main end is switched to the peer, and then the NFS service is restarted, then the NFS service is then launched, so that the NFS service process is restarted once, for restarting, The protocol has a clear grace time definition, as long as the server and the client are implemented by this, then this switching is not perceived for the upper layer of the client. When the client re-accessed the file with its NAS FH, the opposite end can still be parsed to the FSID and FID, and the specific file is also found to access.

It should be no problem in the theory of the idea. Start building such a verification environment. Follow: DRBD Remote Real Time Double Hatup System Configuration Full Manual Article Description Procedure Configure DRBD, mounted to a local / DRBD directory, and then configure this directory in the NFS profile. A virtual machine, as the client, mount the shared directory through floating IP, and turn on the process of copying a large file to the directory, so that the business is online.

During this process, the switchover of DRBD, NFS, and floating IP is performed. Switching process:

1, stop the main NFS

2, switch to DRBD to the peer

3, the peer starts NFS service

4, switch floating IP address to the peer

It is expected that after the NFS service is silent, the original large file operation can continue. The client will not prompt any errors.

The actual result is that the client prompts the NFS handle to be invalid. Originally wanted to find a higher version of Linux system, verify that the NFS4 version can be supported, but due to the DRBD configuration in Linux high, it has not been successful. But thinking, in fact, RPC is based on NAS FH, not an agreement problem. The file system on the DRBD device is mounted on the system host file system, with a block device file to the file system conversion process, for the NFS service, basically not see the file system above the original DRBD device, what is seen or Root file system. Although DRBD is a complete image of the file system, after mount, the two of the inode allocation is inconsistent, so the specific file cannot be found when parsing the FH passing through the client. After you have time, you can analyze the source code of NFS, see if you can implement the contents of the file system above the DRBD device in other ways, not by mounting to the host file system.

Reference page:

1, NFS4 file lock mechanism] http://www.cnblogs.com/zhenjing/archive/2011/05/15/nfs4_lock.html

2, about NFS http://blog.yikuyiku.com/?tagnfsv4

3, NFSV4 provides seamless network access http://www.ibm.com/developerWorks/cn/linux/l-nfsv4.html

4, NFS file handle http://blog.csdn.net/ycnian/Article/details/8506704