From: Thomas Guyot-S. <Th...@za...> - 2005-11-11 14:37:22
|
Thanks for your answer, it's greatly appreciated. In the case I described, the first node to go up effectively doesn't have quorum. It's a bug in heartbeat since in my setup, a node starting up alone always stonith the other node... Do you have any idea when heartbeat 2 support is expected? Thanks, Thomas Guyot-Sionnest System Administrator Zango Canada th...@za... > -----Original Message----- > From: Steve Dobbelstein [mailto:st...@us...] > Sent: November 10, 2005 19:32 > To: Thomas Guyot-Sionnest > Cc: evm...@li...; evm...@li... > Subject: Re: [Evms-cluster] Evms unable to import a deported container > > "Thomas Guyot-Sionnest" <Th...@za...> wrote on 11/10/2005 04:43:06 > PM: > > > Hi, > > > > I'm setting-up a HA test cluster with a fibre channel SAN. So far > > the failover > > process goes well, but I have a problem as soon as both nodes go down, > > whenever it's a graceful shutdown or hard reset. > > > > When the first node goes back on, evms_failover exits without getting > > ownership of the deported container (RC=7) and let heartbeat move on to > > higher-level resources. I end-up with an unmounted filesystem. (I have > no > > > other services yet except Filesystem and IPaddr2, and Filesystem fail > since > > there's no volume) > > > > When the 2nd node goes back on, I can force a failover and everything > goes > > back to normal. Graceful AND hard (STONITH-assisted) failovers works > > perfectly. > > > > I'm running evms-2.5.3 and heartbeat-1.2.3 on both systems. test1 runs > Gentoo > > with those packages coming from portage. test2 runs Slackware 10.2 with > > packages compiled by hand (Heartbeat uses these configure > > options: --prefix=/usr --sysconfdir=/etc --localstatedir=/var -- > > enable-ltdl-convenience) > > > > The layout is: > > > > Clusted container "TEST_cluster" with "sdc" and "sdf" in it. > > md0 on TEST_cluster/sdc and TEST_cluster/sdf. > > LVM2 on that md device with one region using all container space. > > EVMS volume on it with ReiserFS filesystem. > > > > > > Is there's a way to fix this? > > Hello, Thomas. > > By design, EVMS will not let you access containers or change their > properties unless it is running on a node that is in a membership that has > quorum. EVMS can't let you access a private container unless it knows it > is owned by a node that is a valid member of the cluster. EVMS can't let > you change the properties of the container unless it can safely coordinate > those changes with the other nodes in the cluster. EVMS can't safely > coordinate the changes unless it knows it is running on a node that is in > a > membership that has quorum. > > I have seen occasions where the CCM (cluster communication manager, I > think) in heartbeat does not report a membership when just one node is > brought up. It reports a membership when the second node is brought up. > > You can check to see if heartbeat is reporting a membership and the > membership has quorum by running "evmsccm -v". > > If you are not getting a membership with only one node started, then the > problem is with the CCM; EVMS is doing what it is supposed to do in that > situation. We had reported that problem back to the Linux-HA folks, but > I'm not sure if or when they took care of it. > > EVMS is getting support for heartbeat version 2 soon. When it does, you > could try moving up to heartbeat 2 and see if that solves your problem. > > Steve D. |