0

I'm knowingly taking a naive approach to a warm standby NFS server setup. I have two servers (CentOS 7.7) sharing a directory (not a filesystem) via NFS. This directory is kept in sync on both servers with rsync. The /etc/exports file on both servers uses the same fsid for the export. I have a service IP for the NFS service which is used by clients. Clients are using "soft,nosharecache" mount options.

Now I tested manual failover for this IP twice and watched client behaviour (and silently hoped that it "just works"...). Unfortunately my hopes were smashed, but client behaviour is "inconsistent" IMHO and I want to know for educational purposes why this doesn't "just work" and what could be done to make it work (outside of dedicated HA setups like pacemaker).

On the first try my setup seemed to work for some clients (could access the share on new server without noticing the switch), others showed the "stale filehandle" error (which I resolved with umount -fl and remount).

On the second try (using arping for faster IP switch) again some clients had "stale filehandle" errors, others seemed to have lost the mount completely (disappeared from "mount" output), but still had a line in /proc/fs/nfsfs/volumes for the mount. When I remounted the share for those clients I "sometimes" got duplicate entries in /proc/fs/nfsfs/volumes (which don't seem to cause harm). No clients "just worked" this time.

Can somebody explain the (probably obvious) causes why this approach fails?

thanks a lot

0

on nfs server, /var/lib/nfs contains session informations for nfs clients.

If you failover the IP, the other node is not aware of /var/lib/nfs contents, which is empty.

| improve this answer | |
0

NFS server is not that easy to failover. Here is at least two reasons why:

  • file handles as nfs file handles are permanent, after failover client will expect that existing handles are still valid and point to the very same file system object. In your setup you export different file systems, thus file handles are different.

  • NFSv4 state if your client mount with NFSv4.x, then they expect that after transparent failover all states are still valid. This is possible only when both server have a shared state store.

This two requirements makes simple (or naive) failover setups like yours impossible.

NFSv4 protocol allows life server migration, but, AFIK, only Oracle Solaris 11 server with ZFS implements it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.