Re: HACMP , NFS and NFSmaestro
From: Andy (gk15374_at_yahoo.com)
Date: 08/08/03
- Next message: Dr. David Kirkby: "Re: Free UNIX for non-commerical use."
- Previous message: Bert Moos: "Re: second ftpd on the same system"
- In reply to: JohnM: "Re: HACMP , NFS and NFSmaestro"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 8 Aug 2003 02:06:28 -0700
JohnM <jmadd@austin.rr.com> wrote in message news:<3F32F8CE.3A45B505@austin.rr.com>...
> Yoyo wrote:
>
> > Uzytkownik "Mark Lundy" <marklundy@comcast.net> napisal w wiadomosci
> > news:225577dc.0308070918.2aecd49f@posting.google.com...
> > > Hi There!
> > >
> > > We have an HACMP cluster, cascading, where one system fails over to
> > > another system.
> > >
> > > Part of the environment is an NFS export.
> > >
> > > The entries in /etc/exports are identical on both machines, and the
> > > nfs exports are re-exported on failover.
> > >
> > > This is connected to using NFSMaestro client (Hummingbird)?
> > >
> > > On the first system (let's call it mach1) the NFSMaestro client
> > > connection works fine.
> > >
> > > When we failover to the second system ( let's call that mach2) the
> > > reconnect attempt gives "Bad Network Name".
> > >
> > > The nfs client is connecting to the same service IP address in both
> > > cases, but the mount only seems to work on mach1, not on mach2. If
> > > we fail back, we're fine.
> > >
> > > We had a similar problem once upon a time, which seemed to be
> > > corrected by making a change to the entry in /etc/hosts on mach2 for
> > > the service IP :
> > >
> > > Before the fix:
> > > 10.10.10.1 mach1_srv mach1
> > >
> > > After the fix it looks like:
> > >
> > > 10.10.10.1 mach1_srv mach1 mach2
> > >
> > >
> > > Can anyone point me in the right direction about why this might be
> > > happening?
> > >
> > > Also , please forgive any ignorance in this question, as this is
> > > somewhat new to me.
> > >
> > > Thanks in advance for any help.
> > >
> > > Cheers! :)
> > >
> > > -M
> >
> > Be sure after takeover the takeovered filesystems have the same Major
> > Numbers....the other word: the shared filesystems which are NFS mounted have
> > to have the same Major Numbers on all cluster nodes.....
> >
> > To met it you schould do as follows:
> >
> > eg.
> > on clnode1
> > ls -al /dev/sharedvg
> > (check major number)
> > let's say it is 100
> >
> > umount sharedfilesystems
> > varyoffvg sharedvg
> >
> > on clnode2
> > exportvg sharedvg
> > importvg -V 100 -y sharedvg hdisk_belonging_to_sharedvg
> > chvg -an sharedvg
> > (having mirroring switch also Quorum off to avoid VG disabled when quorum is
> > not met)
> > varoffvg sharedvg
> >
> > Having the same major number on each cluster node NFS mount will never hangs
> > after takeover....
> >
> > regards,
> > Y.
>
> Hmm. Y. has a bunch of good suggestions. If that message is a poorly worded
> bubble up for a stale file handle error or some such then certainly it's the
> major number thing. But digging back through moldy memory banks I'm thinking you
> also have to make sure that the failover adapter assumes the MAC address of the
> primary card. Sorry, I can't recall how that's configured in HACMP but you might
> check it out after a failover and see what MAC address it has lit up with. If
> you don't get that right, the arp table will be in a bad state.
>
> Regards, John
I think MAC address change will not affect NFS mounts. Just
ManorNumber in above case.
rgrds,
- Next message: Dr. David Kirkby: "Re: Free UNIX for non-commerical use."
- Previous message: Bert Moos: "Re: second ftpd on the same system"
- In reply to: JohnM: "Re: HACMP , NFS and NFSmaestro"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]