Use of AutoFS on MC/SG cluster nodes still depricated?

[Ralph Grothe]

Hello,

I'm currently exploring Enhanced AutoFS as I intend to move from seasoned user space automount to kernel space AutoFS, mainly for performance reasons.
Unfortunately, part of the NFS clients affected are nodes of an MC/SG cluster.
The made highly available application is an SAP system which to my grief insists on sharing filesystems from the primary application package node to several standby SAP systems, most of which even aren't part of the cluster.
I'd consider this a design flaw, SAP I'd assume rather a feature.
Anyway, having with great interest read Dave Olker's excellent "NFS Performance Tuning for HP-UX 11.0 and 11i Systems" I've come to the conclusion to at least switch from automount to AutoFS on the non-clustered NFS clients.
However, in the chapter that compares Automount vs. AutoFS is a warning to use AutoFS on cluster nodes because of the unpredictable behavior of LOFS mounts (which AutoFS will use in favour of loopback NFS mounts for involved IP addresses that alias to the localhost (i.e. relocatable package IP addresses)) in the case of a package switch over.
The paper identifies this flaw as work TODO.
Since my copy dates back from July 2002 I think there will be a good chance that this has been fixed meanwhile.
Has anyone come accross such a fix?
Parallel I will be searching HP patch DB server for AutoFS patches, or the like.

Rgds.
Ralph

[Duncan Edmonstone]

Well the Serviceguard extension for SAP explicitly talks about using AutoFS:

http://docs.hp.com/hpux/onlinedocs/B7885-90018/00/00/26-con.html

But whether this means the issues have been addressed or not, I wouldn't like to say.

HTH

Duncan

[Geoff Wild]

I too have SAP - and moved to autofs over a year ago - with no issues at all.

One thing I did do, was set proto=tcp for reliability on the App servers:

# cat /etc/auto_master
/- /etc/auto.direct proto=tcp


Rgds...Geoff

[Ralph Grothe]

Duncan,

thanks for pointing me at the SAP Functions Ref.

Geoff,

thanks for the global master map mount option of proto=tcp.
This may improve connection safety, and hopefully reduce retransmissions.
On the other hand I guess the protocoll overhaed as compared to standard automount UDP datagrams could be an issue?
So what would weigh out what?

[Geoff Wild]

For me - it was all about stability - performance wasn't an issue - as I have a dedicated 1GB backbone just for the connectivity between the App servers and the DB/CI HA server.

Used to have issues when failing the package over to the alternate node - caused the dreaded "NFS server not responding" errors on the App Servers - sometime it would recover - sometime not - and we had to reboot the App servers (such a Windows way to go) - which was pretty sad - being HP-UX and all...

Now, with Autofs and proto=tcp = havn't had that issue once.

Havn't noticed any performance hit at all - but like I said - I have a dedicated LAN for it...

Rgds...Geoff

[Dave Olker · Accepted solution]

Hi Ralph,

Thanks for your kind words about my white paper.

In answer to your question, the Enhanced AutoFS product has a new command-line option for automountd: "-L". This option disables AutoFS from generating LOFS mounts that cause problems for ServiceGuard. This enhancement was added specifically to resolve the problem of LOFS mounts created by AutoFS stopping HA/NFS packages from migrating successfully.

My recommendation for any HA/NFS environment where the HA/NFS servers will run an automounter is to get the Enhanced AutoFS product (either download from http://software.hp.com for 11.11 systems - comes standard with 11.23 systems) and launch automountd with the -L option. This -L option only needs to be used on the NFS servers in the cluster - not any clients accessing the exported filesystems.

Hope this helps,

Dave

[Ralph Grothe]

Geoff,

Huh, 1 GBit/s wiring and switching?
Lucky you...
I'm already fully content as long as firewalls and crypto gateways along the route don't interfere the average 100 Mbit/s bandwidth too much (e.g fragmantation bit set and similar anoyances of unpredictable behavior)

Dave,

I already downloaded and installed the Enhanced AutoFS on one of the NFS clients outside the cluster.

$ /usr/sbin/swlist -l fileset -a title -a install_date -a state ENHAUTOFS
# Initializing...
# Contacting target "aller"...
#
# Target: aller:/
#

# ENHAUTOFS Enhanced AutoFS for better performance and functionality 200409241745.37
ENHAUTOFS.ENH-AUTOFS-KRN Enhanced AutoFS kernel functionality 200409241745.37 configured
ENHAUTOFS.ENH-AUTOFS-USR Enhanced AutoFS runtime functionality 200409241745.38 configured


I even printed a hardcopy of "Enhanced AutoFS Administrator's Guide", March 2004
where there is special mentioning of the acclaimed -L switch for automountd in HA environments.
It even says so in the manpage



-L Force all mounts to the local host to be NFS mounts instead of
the default LOFS mounts. This is necessary for highly available
NFS mounts. This option is only available with Enhanced AutoFS.



I should have read the software's documentation more carefully.
But it's nice to be reassured by an NFS guru.

[Dave Olker]

Hi Ralph,

Glad you were able to find the docs. Just to clarify - this -L option should not be used on client systems outside the cluster. It is really intended for the case where AutoFS is running on the HA/NFS servers themselves and they mount filesystems to themselves via the package IP address.

You probably already understood this, but I just wanted to make sure.

Regards,

Dave