- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Use of AutoFS on MC/SG cluster nodes still deprica...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-27-2004 08:04 PM
тАО09-27-2004 08:04 PM
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
Solved! Go to Solution.
- Tags:
- LOFS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-27-2004 08:27 PM
тАО09-27-2004 08:27 PM
Re: Use of AutoFS on MC/SG cluster nodes still depricated?
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
I am an HPE Employee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2004 12:40 AM
тАО09-28-2004 12:40 AM
Re: Use of AutoFS on MC/SG cluster nodes still depricated?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2004 02:11 AM
тАО09-28-2004 02:11 AM
Re: Use of AutoFS on MC/SG cluster nodes still depricated?
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2004 02:29 AM
тАО09-28-2004 02:29 AM
Re: Use of AutoFS on MC/SG cluster nodes still depricated?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2004 02:43 AM
тАО09-28-2004 02:43 AM
SolutionThanks 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
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2004 05:01 AM
тАО09-28-2004 05:01 AM
Re: Use of AutoFS on MC/SG cluster nodes still depricated?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2004 05:09 AM
тАО09-28-2004 05:09 AM
Re: Use of AutoFS on MC/SG cluster nodes still depricated?
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
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]