HP StorageWorks 8000 NAS - Manual (Page 7)

nfs: Server NASName OK
While these errors are not catastrophic, they may signal the need to ‘tune’ the number of nfsd daemons.
Changing the number of nfsd daemons will cause an nfs restart; however, this should not cause an
interruption in nfs service. If an Oracle server has the NAS 8000 soft-mounted, be sure to check the values
of the timeo and retrans nfs parameters (on the Oracle server); otherwise, it is possible that if all of the nfsd
daemons were busy for some period of time, the nfs process on the Oracle server could return I/O errors.
It is best to error (somewhat conservatively) on the side of having too many nfsd daemons rather than too
few. The NAS 8000 administrator can configure between 10 and 128 nfsd daemons. For more
information on how to set the number of nfsd daemons, please refer to the HP NAS 8000 User’s Guide.
allowing ‘root’ access / trusted hosts
The NAS 8000 administrator also configures any systems that will be allowed to access the NAS 8000 as
the user ‘root’. In the normal case when a Unix system ‘root’ user accesses the NAS 8000, their UID (0 on
the Unix system), is remapped to the user ‘nobody’ (UID 65534) on the NAS 8000. This means that the
files and directories they create on the NAS 8000 will be owned by the user ‘nobody’, rather than ‘root’.
In most cases, for security reasons, this is desired behavior. In some instances, this mapping can cause
undesirable side effects. When it is imperative that the ‘root’ user from a Unix system be able to store and
access their files on the NAS 8000 as ‘root’ (UID 0), or any executable owned by ‘root’ and stored on the
NAS 8000 with the SetUID bit set, that Unix system must be given “trusted host” access. This is usually the
case when the files being accessed have the SetUID bit set, or if the owner/group of the file/directories is
checked by the application accessing the file. When the user ‘root’ from one of these “trusted host” systems
accesses the NAS 8000, the UserID is not remapped from ‘root’ to the user ‘nobody’. This is essential in
the case where the Oracle binaries and support files are installed on the NAS 8000 because there are
some executables that have the SetUID bit set, and must be owned and accessed as ‘root’. Please note that
it is not necessary to set the Oracle server to have “root access” in the case where only the database data
files are stored on the NAS 8000. Please see the section on Installation of Oracle for more details. The
use of the ‘trusted host’ allows the NAS 8000 to provide a higher level of security because the nfs export is
not ‘opened’ to root access by other ‘non-trusted’ Unix hosts as would be the case if setting the nfs server
option anon=0 on the export.
nfs mounting guidelines (Client side)
On the client side, (the nfs client is the Oracle server), there are a number of options and settings to help
“fine-tune” nfs access for each environment. One of the first things that must be decided is whether the
Oracle server will mount the NAS 8000 exports as hard or soft mounts. Before deciding on a mounting
strategy, a discussion should be had with the IT administrator(s) responsible for the NAS 8000 and Oracle
server(s) to fully understand the ramifications of each choice. As well, if soft mounting is the method
chosen, be sure to be familiar with the default settings on the nfs clients (Oracle servers) of various nfs
parameters such as retrans and timeo and have them changed if they are not satisfactory.
hard mounting
Hard mounting the Oracle server to NAS 8000 exported directories implies that any outage (due either to
network or NAS 8000 failure) will cause nfs mounts and Oracle processes using those mounts on the
Oracle server to block/wait until service is restored. In many cases, this is the desired behavior. For
instance, if a client (Oracle server) is performing transactions that are not easily reproducible (from the
client side), it is crucial that the transactions not fail out. In this case, it would be desirable for the client to
wait rather than have the application terminate with an I/O error, especially if the outage is due to a
temporary network problem. The NAS 8000 is engineered so that in the unlikely event of a failure or
crash, no data corruption should occur. Additionally, the storage subsystem of the NAS 8000 is
engineered such that only a catastrophic condition causing multiple NVRAM failures or the loss of multiple
hard disks could result in a loss of data requiring some form of recovery. Please see the section on NVRAM
for more details.
soft mounting
Soft mounting the Oracle server to NAS 8000 exported directories implies that outages (due either to
network or NAS 8000 failure) can cause the nfs process on the client to “fail” and an I/O error to be
returned to the Oracle process(es). This usually results in the application terminating. This behavior may be
7