Tuesday, 25 October 2016

WebSphere Application Server and Network File System (NFS)

This came up in discussion today, so I thought I'd x-post some relevant links, as I know I'll need them again: -


NFS v4 is commonly used as a reliable storage for the following components of WebSphere Application Server:
The following table lists mount options that are required. They are not exclusive but other options should not negate these.

Option Description
-t nfs4 Forces NFS v4 to prevent any possibility of falling back to NFS v3.
-o hard,intr Soft mounts can lead to file corruption so hard mounts are required. intr allows a user to interrupt from the keyboard.

However, not all file systems provide the necessary file locking semantics, specifically that file locks are released when a server fails. For example, Network File System Version 4 (NFSv4) provides this release behavior, whereas Network File System Version 3 (NFSv3) does not.


NFSv4 releases locks held on behalf of a host in case that host fails. Peer recovery
can occur automatically without restarting the failed hardware. Therefore, this version
of NFS is better suited for use with automated peer recovery

NFSv3 holds file locks on behalf of a failed host until that host can restart. In this
context, the host is the physical machine running the application server that requested
the lock and it is the restart of the host, not the application server, that eventually
triggers the locks to release


...
If you use NFSv3 to support automatic peer recovery processing, it becomes necessary to disable file locking, as discussed previously in File locking for WebSphere Application Server recovery logs, This action, in turn, requires that additional measures be put in place to prevent system overloading or network partitioning that might lead to a peer recovery process being directed for an active server.
The most recent version of the NFS protocol, NFSv4, provides lease-based exclusive locks on files as does CIFS. NFSv3 locking is not lease-based and so is less effective in an environment where file ownership needs to be failed over in the event of a server crash. If NFSv3 is used with automated peer recovery, a systems administrator must consider additional configuration choices, which are detailed in Considerations for automated peer recovery. These considerations are not required for either manually-initiated peer recovery or when the file system is either NFSv4 or CIFS. This information is summarized in Table 1.


No comments:

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...