NSD server considerations

If you plan to use NSD servers to remotely serve disk data to other nodes, as opposed to having disks SAN-attached to all nodes, you should consider the total computing and I/O load on these nodes.

  • Will your Network Shared Disk servers be dedicated servers or will you also be using them to run applications? If you will have non-dedicated servers, consider running less time-critical applications on these nodes. If you run time-critical applications on a Network Shared Disk server, servicing disk requests from other nodes might conflict with the demands of these applications.
  • The special functions of the file system manager consume extra processing time. If possible, avoid using a Network Shared Disk server as the file system manager. The Network Shared Disk server consumes both memory and processor cycles that could impact the operation of the file system manager. See The file system manager.
  • The actual processing capability required for Network Shared Disk service is a function of the application I/O access patterns, the type of node, the type of disk, and the disk connection. You can later run iostat on the server to determine how much of a load your access pattern will place on a Network Shared Disk server.
  • Providing sufficient disks and adapters on the system to yield the required I/O bandwidth. Dedicated Network Shared Disk servers should have sufficient disks and adapters to drive the I/O load you expect them to handle.
  • Knowing approximately how much storage capacity you will need for your data.
You should consider what you want as the default behavior for switching between local access and NSD server access in the event of a failure. To set this configuration, use the -o useNSDserver file system mount option of the mmmount, mount, mmchfs, and mmremotefs commands to:
  • Specify the disk discovery behavior
  • Limit or eliminate switching from either:
    • Local access to NSD server access
    • NSD server access to local access
You should consider specifying how long to wait for an NSD server to come online before allowing a file system mount to fail because the server is not available. The mmchconfig command has these options:
nsdServerWaitTimeForMount
When a node is trying to mount a file system whose disks depend on NSD servers, this option specifies the number of seconds to wait for those servers to come up. If a server recovery is taking place, the wait time you are specifying with this option starts after recovery completes.
Note: The decision to wait for servers is controlled by the nsdServerWaitTimeWindowOnMount option.
nsdServerWaitTimeWindowOnMount
Specifies a window of time (in seconds) during which a mount can wait for NSD servers as described for the nsdServerWaitTimeForMount option. The window begins when quorum is established (at cluster startup or subsequently), or at the last known failure times of the NSD servers required to perform the mount.
Notes:
  1. When a node rejoins a cluster, it resets all the failure times it knew about within that cluster.
  2. Because a node that rejoins a cluster resets its failure times within that cluster, the NSD server failure times are also reset.
  3. When a node attempts to mount a file system, GPFS checks the cluster formation criteria first. If that check falls outside the window, it will then check for NSD server fail times being in the window.