HP OpenVMS Systems Documentation

HP TCP/IP Services for OpenVMS
Management

For a typical image restore, follow normal OpenVMS procedures.

For a nonimage restore, an additional step is required after the restore. The Files--11 file identifiers are recorded in the container file. These must be updated by the TCP/IP management command ANALYZE CONTAINER /REPAIR.

This extra step is also required for an image restore if the save set is being restored with the /NOINITIALIZE qualifier to a volume with a different label or if it is being restored to a bound volume set that has a member that was added since the time of the image backup.

22.11 Setting Up NFS Security Controls

The NFS server and the OpenVMS operating system provide many levels of security controls you can use to protect your file systems. Section 22.1.3, Section 22.1.4, and Section 22.1.7 describe how the server uses the proxy and export databases to restrict client access, and how to use OpenVMS account privileges and file protections to control access to files and directories.

The NFS server provides additional security controls through the use of the noproxy_enabled attribute. You can set this attribute in the NFS server site-specific startup file SYS$STARTUP:TCPIP$NFS_SERVER_SYSTARTUP.COM.

The server uses this attribute while it is running. If the attribute is set, a proxy is not required for users attempting to access the NFS server. For more information about the NFS server attributes, see Table 22-3.

22.12 Modifying NFS Server Attributes

You can modify the way the NFS server works by specifying NFS server attributes in the SYSCONFIGTAB database. The characteristics of the NFS server that you can modify include:

• Proxy security
• Default proxy UID
• Default proxy GID
• Maximum concurrent TCP threads
• Maximum concurrent UDP threads

To make permanent modifications, use the SYSCONFIGDB utility to include the new settings in the SYSCONFIGTAB.DAT file, as described in the HP TCP/IP Services for OpenVMS Tuning and Troubleshooting guide.

To make the changes take effect, shut down and then restart the NFS server. For example:

$ @SYS$STARTUP:TCPIP$NFS_SERVER_SHUTDOWN.COM

$ @SYS$STARTUP:TCPIP$NFS_SERVER_STARTUP.COM

Future upgrades or installations will not overwrite the definitions in the SYSCONFIGTAB file.

Modifying NFS server characteristics can affect NFS server performance. Be sure you understand the impact (review Section 22.15) before making any changes.

Table 22-3 describes the NFS server attributes that you can modify to affect NFS server performance.

The file SYS$STARTUP:TCPIP$NFS_STARTUP.COM contains definitions of logical names that set the file system parameters. To change the settings of these logical names, define them in the SYS$STARTUP:TCPIP$SYSTARTUP.COM command procedure by using the /EXECUTIVE_MODE and /SYSTEM qualifiers.

Table 22-4 describes these logical names.

TCP/IP Services supports a partial implementation of NFS network locking, which allows users to lock files. The software coordinates locks among remote users and between remote and local users. The file locking features is applicable regardless of whether the OpenVMS Record Management Services (RMS) is used. However, NFS does not coordinate network locking and RMS record locks.

File locking is implemented using the Network Lock Manager (NLM) (also known remote procedure call, or RPC, lockd ) and the Network Status Monitor (NSM) (also known as RPC statd ). The NLM coordinates locks made by clients. The NSM recovers lock information in case the server or client fails. The NSM uses the NLM to keep the host list when the client or the server fails and reboots, as follows:

• If the client fails and reboots, it notifies the NSMs on its host list. In turn, the NSMs tell their local NLMs to free any locks held for that client.
• If the server fails, when it reboots it notifies the NSMs on each client host in its host list. In turn, the client NSMs tell their local NLMs to request again all the locks that were granted on their behalf by the server before it failed.

The NSM and the NLM are enabled if you select LOCKD/STATD in the TCPIP$CONFIG.COM configuration procedure. As a result, two processes are started when you start TCP/IP Services: TCPIP$LOCKD and TCPIP$STATD. The NLM can be configured with the following optional parameters:

• TCPIP$LOCKD_TIMEOUT_PERIOD specifies the timeout period (in seconds). This value defines the amount of time for the client to wait before retransmitting a lock request to which the server has not responded. The default setting is 5 seconds.
• TCPIP$LOCKD_GRACE_PERIOD specifies the grace period (in seconds). This value defines the amount of time the NLM will deny new lock requests after a failure while the NSM is recovering the lock status. The default setting is 15 seconds.

To set these parameters, create or edit the following file:

SYS$STARTUP:TCPIP$LOCKD_SYSTARTUP.COM

The file locking services can be shut down and started independently of TCP/IP Services. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

• SYS$STARTUP:TCPIP$LOCKD_STARTUP.COM allows you to start up the LOCKD component independently.
• SYS$STARTUP:TCPIP$STATD_STARTUP.COM allows you to start up the STATD component independently.
• SYS$STARTUP:TCPIP$LOCKD_SHUTDOWN.COM allows you to shut down the LOCKD component independently.
• SYS$STARTUP:TCPIP$STATD_SHUTDOWN.COM allows you to shut down the STATD component independently.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$LOCKD_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the LOCKD component is started.
• SYS$STARTUP:TCPIP$LOCKD_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the LOCKD component is shut down.

This section provides information to help you identify and resolve problems and tune system performance.

22.15.1 Displaying NFS Server Performance Information

The SHOW NFS_SERVER command displays information about the running NFS server. You can use the information to tune NFS server performance.

You can enter SHOW NFS_SERVER for a specific client or host if it is listed in the proxy database. The counter information can be especially useful in determining the load on your system.

For more information about the SHOW NFS_SERVER command, refer the HP TCP/IP Services for OpenVMS Management Command Reference.

22.15.2 Increasing the Number of Active Threads

The NFS server is an asynchronous, multithreaded process. This means that multiple NFS requests can be processed concurrently. Each NFS request is referred to as a thread. With increased server activity, client users may experience timeout conditions. Assuming the server host has the available resources (CPU, memory, and disk speed), you can improve server response by increasing the number of active threads. You do this by changing the value for the appropriate NFS server attributes, as described in Section 22.12.

The NFS server supports both TCP and UDP connections. You can control the maximum number of concurrent threads for each type of connection.

• To set the maximum number of TCP threads, set the tcp_threads attribute.
• To set the maximum number of UPD threads, set the udp_threads attribute.

These attributes are not dynamically loadable. You must restart the NFS server in order to effect the changes. See Section 22.12 for more information.

Do not set the UDP maximum threads to zero. If you set the variable to zero, the protocol will be disabled.

If you increase the number of active threads, you should also consider increasing the timeout period on UNIX clients. You do this with the /TIMEOUT option to the TCP/IP Services MOUNT command.

If your clients still experience timeout conditions after increasing the number of active threads and the timout period on the client, you may need to upgrade your hardware.

22.15.3 Managing the File Name Cache

The NFS server caches the contents of directory files in addition to the content of other files. The server must access the directory files to cache them.

You can manage the performance of the NFS server using the following logical names:

• TCPIP$CFS_NAME_CACHE_SIZE
  This logical name establishes the size of the file name cache. The cache size is represented as the number of 128-byte entries. File names up to 88 bytes long are stored in each 128-byte name cache entry. The cache is retained in least recently used (LRU) order, so that the most referenced entries are retained. Certain directory modification operations remove all entries for the directory from the cache.
  The file name cache reduces the number of QIO operations required by the NFS server to look up files by name. The cache increases the virtual memory requirements of the NFS server by 128 bytes times the number of entries configured by the logical name.
• TCPIP$CFS_ODS_CACHE_SIZE
  This logical name establishes the size of the ODS cache, which retains information about sequential files that will require record format conversion.
  The cache size is expressed as the number of 64-byte entries. Entries are retained in LRU order, so that the most referenced entries are retained.
  In addition to 64-bytes per entry, the record conversion information created when the file is first accessed is retained as well. This change increases the virtual memory required by the NFS server, but also greatly improves performance for files that require format conversion. The ODS cache is used on internal file access and deaccess operations and when attribute information is read.

In addition, you can also use the NFS sysconfig attribute ovms_xqp_plus_enabled to modify the behavior of the NFS server to take advantage of the directory and name caches. This attribute is specified as a bit mask. The default value is 0, or OFF.

The following list describes the mask values:

• 1 (open directory on LOOKUP)
  When an NFS LOOKUP operation is performed on a directory, the directory is accessed. This allows subsequent operations to use the directory cache. If the name cache is enabled, entries will be posted to it.
• 2 (open directory on READDIR)
  When an NFS READDIR operation is received, the directory is accessed. This allows subsequent operations to use the directory cache.
• 4 (open file on GETATTR)
  When the attributes of a file subject to record format conversion are read and the MODUS_OPERANDI mask 512 is enabled, the file's true size (that is, its converted size) is to be returned. If this option is enabled, then the access to convert the file will be cached for up to the number of seconds specified by the subsystem attribute vnode_age . If the ODS name cache is also enabled, the size and conversion information will be retained in the ODS cache until either the file is deleted or the entry is replaced by another, subject to the LRU behavior.

Obtain a combination of choices by adding the desired values. For example, enter 7 for a combination of the three.

When directory caching is enabled, the system must be configured to be able to handle the increased directory cache requirements. The following SYSGEN parameters may need to be increased, depending on the maximum number of files that the NFS server may access at any given time. This maximum is determined by the FILLM quota of the NFS$SERVER account and the SYSGEN parameter CHANNELCNT .

Use the MODPARAMS.DAT file and AUTOGEN to make the changes. Define the following parameters:

• ACP_DINDXCACHE
  Increase this value by the number of NFS server channels.
• ACP_DIRCACHE
  Increase this value by four times ACP_DINDXCACHE.

To calculate the PAGEDYN value, add the values of these parameters and multiply by 512.

22.15.4 OpenVMS SYSGEN Parameters That Affect Performance

The following OpenVMS SYSGEN parameters impact NFS server performance:

• CHANNELCNT
  The CHANNELCNT parameter sets the maximum number of channels that a process can use. Ensure that CHANNELCNT is set large enough to handle the total number of files accessed by all clients.

  Note The NFS server process is also limited by the FILLM of the TCPIP$NFS account's SYSUAF record. The effective value is the lower of the FILLM and CHANNELCNT values.

• ACP parameters
  The NFS server issues a large number of ACP QIO calls through CFS. Altering certain ACP parameters could yield better performance. Directory searching and file attribute management constitutes a majority of the ACP operations. Therefore, HP recommends that you monitor and adjust the following parameters as necessary:
  • ACP_HDRCACHE
  • ACP_MAPCACHE
  • ACP_DIRCACHE
  • ACP_FIDCACHE
  • ACP_DATACACHE
  
  To monitor these parameters, use the MONITOR utility (for example, MONITOR FILE_SYSTEM_CACHE), and the AUTGEN FEEDBACK command. For more information, refer to the HP OpenVMS System Management Utilities Reference Manual: M-Z.
• LOCK parameters
  The various lock manager parameters may need some alteration because CFS uses the lock manager extensively. A lock is created for each file system, each referenced file, and each data buffer that is loaded into the CFS cache.

• VIRTUALPAGECNT
  Maximum virtual size of a process in pages. The NFS server requires larger-than-normal amounts of virtual address space to accommodate structures and buffer space.
• WSMAX
  Maximum physical size of a process in pages. The larger the working set, the more pages of virtual memory that can remain resident. Larger values reduce page faults and increase the server's performance.