It is a very well known fact that NFS protocol used to mount file systems in clustered application environments can be prone to issues with things like lock contention, dirty reads, and stale file handle if not configured correctly. This article is targeted at outlining how a WebCenter Content clustered implementation requires NFS file systems to be mounted in order to operate without issues.
NFS V3 and V4 are very common protocols to be used in Unix/Linux environments for mounting shared file systems which are mutually accessible to physical servers which are hosting clustered applications. WebCenter Content is an application which supports and is commonly deployed in a clustered capacity to provide high availability and fault tolerance. I have always thought that it was common knowledge on the requirements that WebCenter Content had for mounting shared file systems over NFS protocol but recently I have run into a couple of very high profile implementations where NFS mounts were not correctly configured. This leads me to believe that the knowledge I thought was common might not be as common as I thought and has inspired me to write this article to ensure that this information is made highly visible via the A-Team chronicles.
In a clustered implementation of WebCenter Content a shared file system is required. This is true even if WebCenter Content has been configured to store managed content in the database using a filestore provider storage rule configured for jdbc storage. This is the case due to the fact that in addition to content there is application process data that resides on a portion of the shared file system used by WebCenter Content which also needs to be mutually accessible to all nodes in a cluster. The high level requirements of a shared file system for WebCenter Content no matter what protocol is used are:
Specific to when NFS protocol is being used for file system mounting and sharing over a standard TCP/IP backbone the following requirements also need to be adhered to in order to avoid performance issues
It is common that the last requirement of having locking and caching disabled will give most server administrators cause for concern over file contention and file system performance degradation. These NFS mounting options are required for WebCenter Content due to how it uses a portion of the shared file system as a semaphore for process coordination between nodes in a cluster running the application.
To minimize concerns related to locking, WebCenter Content has been designed to manage file contention and locking on shared file system resources at the application level. Therefore it needs full control over files without potential of NFS locking conflicting with its application processes. Disabling attribute and file handle caching is required to ensure that the application processes running on each node is not subject to dirty reads for operations like checking time stamps on files used as part of process coordination/synchronization. To manage the breadth of impact disabling caching has on operations like
WebCenter Content provides configuration entries that allows the sub-section of the overall shared file system used for process coordination and indexing to be placed on separate NFS mounted volume that has locking and caching disabled. This enables the NFS volume that stores things like content (e.g. Vault and Weblayout ) and components which do not require caching and locking to be disabled to be on a volume that has caching and locking enabled to mitigate performance issues. The configuration entries are the following:
The following diagram is used to illustrate the recommended distribution of WebCenter Content directory structure across two NFS volumes to allow WebCenter Content to operate in the most scalable capacity in relation to shared file system access.
Hopefully this article has been able to provide you with good insight on the NFS shared file system requirements that WebCenter Content has and a good explanation behind these requirements.