SIOS TECHNOLOGY CORP.

NFS Server – Known Issues / Restrictions

Description
When performing a switchover or failover with a file mounted with NFSv4 open, the remove processing of file system resources may fail.

When performing a switchover or failover with a file mounted with NFSv4 open, unmounting the file system resource under the hanfs resource times out and the remove processing fails.

This is because the nfsd kernel thread continues to retain the file open information of the NFS client even after the export is released, and this behavior is considered a specification of NFSv4. (Note that in some versions of RHEL 8, unmount may be performed but this behavior is treated as an nfsd bug. Updating to a bug-fixed package may result in the above condition.)

If the remove processing fails, switchover cannot be performed.

Failover due to resource failure cannot be performed, but if the remove processing fails, the OS on that node is forced to shut down and failover due to node failure is performed.

Failover due to a node failure is not affected because each resource is not removed.

Solution: Please use NFSv3.
Invalid subdirectory cache of $id still exists

See LifeKeeper Core – Known Issues for more information.
Top level NFS resource hierarchy uses the switchback type of the hanfs resource

The switchback type, which dictates whether the NFS resource hierarchy will automatically switch back to the primary server when it comes back into service after a failure, is defined by the hanfs resource.
IPv6 address cannot be used to specify the client

Resource creation will fail when the client is specified using an IPv6 address in the /etc/exports file.

Solution: Use hostnames or wildcards to specify the client.
File Lock switchover fails

Switchover file locks during resources switchover/failover does not work. The result is the same when mounting with both NFS v3 or v4. Do not use file lock from client applications.
Resource creation process will hang when gssproxy is not running

If the gssproxy daemon is not running, LifeKeeper starts it when a resource is created. However, the resource creation process is not completed since the gssproxy does not work as LifeKeeper expected. This issue can occur in both lkGUIapp and lkcli. If the gssproxy is not installed and rpc.svcgssd is installed, this issue does not occur because the rpc.svcgssd is used.

Solution: Start gssproxy daemon. Enable the auto-start to keep it running all the time.The following are examples of RHEL 7.

systemctl start gssproxy.service
systemctl enable gssproxy.service
If rpc.idmapd and rpc.svcgssd are not running in the LifeKeeper Single Server Protection environment, the restore function will fail

In LifeKeeper Single Server Protection, the directory to mount rpc_pipefs is not created. Mounting rpc_pipefs is tried before starting rpc. idmapd and rpc.svcgssd daemons, but it fails because the directory is missing.

Soulution: Start rpc.idmapd and rpc.svcgssd daemons. Enable the auto-start to keep it running all the time.The following are examples of SLES15. If the gssproxy is installed, it is not necessary to have the rpc.svcgssd daemon running.

systemctl start nfs-idmapd.service
systemctl enable nfs-idmapd.service
systemctl start rpc-svcgssd.service
systemctl enable rpc-svcgssd.service

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment