[Linux-HA] stickiness for master in master/slave resource?

[Andreas Kurz]

sorry, forgot the latest logs

Regards,
Andreas

On 7/12/07, Andreas Kurz <andreas.kurz at gmail.com> wrote:
> > > > > > > I am using hearbeat 2.1.0 on CentOS 4.5 and drbd 8.0.3. I know drbd8
> > > > > > > is currently not supported but I give it a try ;-).
> > > > > > >
> > > > > > > I adopted the drbd ocf RA and configured a master/slave resource with
> > > > > > > resource_stickiness INFINITY and a location constraint to define the
> > > > > > > prefered master. I killed heartbeat on the drbd master and the second
> > > > > > > node does the failover as expected .... but .... when the stonithed
> > > > > > > node comes up again the drbd master resource stays on the second node
> > > > > > > as expected, but in a first attempt to negotiate who is the master for
> > > > > > > the drbd resource heartbeat demotes the drbd resource, including a
> > > > > > > stop of the drbd resource. Then the second nodes gets promoted again
> > > > > > > and the drbd starts up again on the second node.
> > > > > > >
> > > > > > > Is this a known behaviour, or is there something wrong with my
> > > > > > > configuration or is this a drbd8 problem?
> > > > > >
> > > > > > can you please attach the files
> > > > > >    /var/lib/heartbeat/pengine/pe-warn-72.bz2
> > > > > >    /var/lib/heartbeat/pengine/pe-warn-73.bz2
> > > > > > from smsdb06?
> > > > >
> > > > > of course, thanks for your help!
> > > >
> > > > ouch - we're not behaving properly here at all.
> > > > i'll get back to when its fixed.
> > >
> > > Not "fixed", but I can offer a simple work-around
> > >
> > > Change:
> > >            <nvpair id="remove-after-stop" name="remove-after-stop"
> > > value="true"/>
> > > to
> > >            <nvpair id="remove-after-stop" name="remove-after-stop"
> > > value="false"/>
> > >
> > > That particular option is not well tested, I'd not advise turning it on.
> > > Was there any particular reason you had it on?
> >
> > When reading the description of this option I found it a good idea to
> > use it, but I think I can live without it. I will test this
> > work-around.
>
> This workaround has no noteable effect on my config .... additionally
> the resource_stickiness for the master resource does not work as
> expected and I have no idea how the values for the crm_master command
> are calculated. Once the drbd master stays on the second node even
> after the first node with the higher location-constraint score comes
> up again, after the next reset the first node gets drbd master
> although there is the resource_stickiness=INFINITY in the master-slave
> resource .....
>
> Is there an easy way to predict the master-slave behaviour .... or to
> change my config to get the expected drbd-master stickiness???
>
> Regards,
> Andreas
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cib_smsdb05-06.xml.gz
Type: application/x-gzip
Size: 3982 bytes
Desc: not available
URL: <http://lists.linux-ha.org/pipermail/linux-ha/attachments/20070712/bc1f02e7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ha-log-smsdb05.gz
Type: application/x-gzip
Size: 35990 bytes
Desc: not available
URL: <http://lists.linux-ha.org/pipermail/linux-ha/attachments/20070712/bc1f02e7/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ha-log-smsdb06.gz
Type: application/x-gzip
Size: 45168 bytes
Desc: not available
URL: <http://lists.linux-ha.org/pipermail/linux-ha/attachments/20070712/bc1f02e7/attachment-0002.bin>