Conference smurf::ase

1983.0. "filesystem for 2 services" by NETRIX::"[email protected]" (Clair Garman) Thu Apr 03 1997 19:56

     Two mail servers (POP amd sendmail)  need access to /usr/spool/mail.
If both servers are configured as ASE DISK services, they both run on
the same box and the other box is a hot standby.  They cannot be configured
as 2 ASE DISK services since they need access to the same directory,
/usr/spool/mail.

     One solution is to create an ASE NFS service to serve /usr/spool/mail
from shared disks.  Each member of the cluster mounts the NFS /usr/spool/mail.
Each mail server is configured as an ASE USER-DEFINED service and accesses
its files from the NFS, /usr/spool/mail.  The problem with this solution is
that when the ASE NFS service runs on member-1, the mail server on member-1
must access its files through NFS, incurring what one customer (AOL) measured
at a 30% performance loss.

     I have devised a solution that will not incur the performance loss, but
want input as to possible problems.  I have constructed the following scheme
and it seems to work.

ASE NFS service is named "nfs".
It exports the directory /data.
On the system running the service, the directory is mounted by ASE at:
        /var/ase/mnt/nfs/data.
Clients mount nfs:/data as /test.

When the service runs on member-1, /test is a symlink to
/var/ase/mnt/nfs/data and member-2 is a client of the "nfs" service.

On either system, the files are accessed in /test.  Files that are locked
from either system are locked to the other system.  The member that runs
the NFS service offers direct access to the files of /test.  The performance
loss experienced by going through the NFS server is not experienced.



# Start Action script for "nfs" service
# start_nfs     umount the NFS and establish a symlink to /test

umount /test
rmdir /test
ln -s /usr/var/ase/mnt/nfs/data /test

# Stop Action script for "nfs" service
# stop_nfs      remove the symlink to /test and mount it as an NFS

rm -fr /test
mkdir /test
mount nfs:/data /test


     At boot time, the "nfs" service will run on one member.  On that
member, ASE will mount /var/ase/mnt/nfs/data from S14asemember.  In order
to perform the NFS client mount on the other member, the following script
is created.

# /sbin/rc3.d/S99local

if mount | grep -q /var/ase/mnt/nfs/data
then
    :
else
    rm -fr /test        2> /dev/null
    mkdir /test         2> /dev/null
    mount nfs:/data /test
fi

     Does this scheme seem workable?
     Has anyone configured such a service?

Clair Garman
Washington, DC
[Posted by WWW Notes gateway]

    Clair,
    
    What you propose can work, but your stop script should close any open
    file on /var/ase/mnt/... otherwyse ASE will not be able to umount the
    filsystem. So, your proposal is a NFS service integrating a DISK
    service feature.
    
    You can also create a DISK service that you NFS exports via the ASE
    provided scripts. I use that technique since one year in a customer.
    The method is explained in details in note 1265.1
    
    Regards, Manu.
    

    Another way of achieving the same goal is to use automount.  Automount
    does what you want by default and thus you could have all of your
    servers mount in the standard /etc/fstab.  If automount finds that
    the IP address to mount the directory from is configured locally,
    then it creates a sym link to the physical storage.  If not, it does
    an NFS mount from the server of the storage.
    
    With automount, the service becomes just a standard NFS service with
    no init.d startup file and no ASE start or stop scripts.
    
    -- Greg
    

    >> With automount, the service becomes just a standard NFS service with
    >> no init.d startup file and no ASE start or stop scripts.
    
    Greg, 
    
    If someone is opening a file on the local resource linked by a symbolic
    link, then a stop script is needed to stop this process, isn't it ?
    
    Manu.
    

    Manu,
    
    Yes this is correct.  This is one of the drawbacks of using autmount
    in this manner.  It seemed to me, however, that this was going to
    happen anyway with the suggested implementation.  If one wanted to
    avoid this, automount now has a new option (-p introduced in the DU
    V4.0B stream, I think) which forces automount not to sym link.  Instead
    it does an NFS local loopback mount.  This allows someone running
    an NFS service with automount to relocate the service without having
    to kill processes.
    
    -- Greg

    Thanks, Greg
    
    I didn't know automount -p.
    
    Manu.