NFS storage requirements for Db2 Warehouse

The Db2 Warehouse service has several prerequisites for NFS storage.

NFS version 3 is a "stateless" protocol and relies on Network Lock Manager (NLM) for exchanging lock information between client and server using Remote Procedure Call (RPC) protocol. NLM locking is advisory and the locks do not expire, you must remove them explicitly. This could potentially cause conflicts in parallel access environments such as Db2 Warehouse, especially when a node fails and the file locks are not removed from the server. However, to avoid the locking conflict, NFS version 3 supports a nolock mount option.

NFS version 4 is a "stateful" protocol that does not rely on NLM, and instead uses a limited-duration lock management system using a leasing algorithm that renews client access. If the client is not able to renew the lease within the lease period window (typically 30 seconds on NAS controllers like NetAPP, ONTAP, or EMC Isilion) locks are released and that can cause applications to crash. There is no support for delegating lock management to client-side via nolock mount option in NFS version 4 unlike NFS version 3.

Db2 Warehouse implements its own file locking mechanism to manage concurrent access to shared files, such as Db2 Warehouse diagnostic logs that are saved on bluemta0 file system mounted from a Read-Write-Many (RWX) volume. Delegating lock management using nolock option allows Db2 Warehouse complete control of locking and mitigates potential lock conflicts. Both, NFS version 3 and 4 have limitations in the locking facilities, however, NFS version 3 allows the nolock mount option.

When there is a fail-over in a scale-out NAS environment (such as a storage cluster), where the storage cluster (virtual) IP is moved to a different storage node network interface because of a node failure or maintenance, NFS version 3 allows fail-over to occur transparently without disrupting established NFS sessions.

Note:
  • If you are using an enterprise NAS storage controller, refer to the vendor documentation for the rsize and wsize settings that provide optimal performance.
  • Unlike NFS Version 4, NFS Version 3 is a stateless protocol. This difference has implications when a scale-out NAS controller is used, because with NFS Version 3 a storage cluster fail-over that causes storage cluster IP changes is transparent and does not disrupt established NFS sessions. Therefore, when using NFS protocol with Db2 Warehouse you must use NFS Version 3. This is the reason for the vers=3 option.
  • Because a Db2 Warehouse MPP deployment employs a shared-nothing architecture, to avoid the locking overhead and potential locking conflicts, NLM locking must be disabled. This is the reason for the nolock option.
  • An NFS soft mount might give up after the NFS timeout is exceeded and might not correctly return the error back to the caller. This can lead to data corruption in cluster applications, and is the reason for the hard option.