Active-Active NFSv4 on GFS2

Latest response

Applicability: This product use case aims at solving data-center resource access bottle-necks (for file serving) that arise when multiple clients try to access data stored in a clustered file-system simultaneously as they read from and write to the data store exported by just one NFS server instance. Currently Red Hat in RHEL 5 and RHEL 6 supports an active-passive configuration of NFS server instances that has GFS2 as well as other single node file systems like Ext3/4 as a back-end filesystem. Red Hat clustering assigns which server will run the NFS service. If that server goes down, the NFS service will be relocated to another server in the cluster. Clustering insures data-integrity while using the stand-alone file systems like Ext3/4. The client will not notice any significant service interruption. The objective of the new use-case in RHEL 7 is to extend this to support an active-active configuration of NFS resources that can effectively lead to a load-sharing configuration where the clients are no longer constrained to access the GFS file system share via one single NFS resource in the cluster.

 

What is in consideration: 2 or more NFSv4 Server resources (max 4) will be supported in a cluster of 2 - 16 nodes. The back-end file-system shall be GFS2. The NFSv4 Server instances run over a GFS2 filesystem and export the entire GFS2 file system from multiple nodes at the same time. No access to the GFS2 file system is allowed except through the NFSv4 Server.  This includes both local GFS2 file system access as well as access via Samba or Clustered Samba.  Clients can mount the shares exported by NFSv4 on GFS2 and do I/O operations without losing and/or corrupting data. If a server goes down clients on that server can be migrated to another active server without significant service interruption. This will be initially enabled using a floating IP address and later using NFSv4 migration and replication features to move clients around between servers for dynamic load balancing.

 

Why are we doing this: This use case will fill a long standing gap in the RHEL portfolio to provide active-active NFS support over a clustered file system. This will in-turn enable applications to do I/O without being constrained by the bottle-neck that arise from the fact that all I/O can get to the data-store (GFS2 share) via one NFS Server instance. It also provides system administrators a lot of flexibility with regards to provisioning of resources in the data center depending on workload demands.

 

Limitations:  We plan to support this for NFSv4 only.

Responses