----- Original Message -----
> From: "Lars Ellenberg" <lars.ellenb...@linbit.com>
> To: "General Linux-HA mailing list" <linux-ha@lists.linux-ha.org>
> Cc: "Jonathan Brassow" <jbras...@redhat.com>, "Lars Marowsky-Bree"
> <l...@suse.com>, "Fabio M. Di Nitto"
> <fdini...@redhat.com>
> Sent: Wednesday, May 15, 2013 6:50:45 AM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
> On Tue, May 14, 2013 at 11:36:54AM -0400, David Vossel wrote:
> > ----- Original Message -----
> > > From: "Lars Ellenberg" <lars.ellenb...@linbit.com>
> > > To: "Lars Marowsky-Bree" <l...@suse.com>
> > > Cc: "Fabio M. Di Nitto" <fdini...@redhat.com>, "General Linux-HA mailing
> > > list" <linux-ha@lists.linux-ha.org>,
> > > "Jonathan Brassow" <jbras...@redhat.com>
> > > Sent: Tuesday, May 14, 2013 9:50:43 AM
> > > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> > >
> > > On Tue, May 14, 2013 at 04:06:09PM +0200, Lars Marowsky-Bree wrote:
> > > > On 2013-05-14T09:54:55, David Vossel <dvos...@redhat.com> wrote:
> > > >
> > > > > Here's what it comes down to. You aren't guaranteed exclusive
> > > > > activation just because pacemaker is in control. There are scenarios
> > > > > with SAN disks where the node starts up and can potentially attempt
> > > > > to
> > > > > activate a volume before pacemaker has initialized.
> > > >
> > > > Yeah, from what I've read in the code, the tagged activation would also
> > > > prevent a manual (or on-boot) vg/lv activation (because it seems lvm
> > > > itself will refuse). That seems like a good idea to me. Unless I'm
> > > > wrong, that concept seems sound, barring bugs that need fixing.
> > >
> > > Sure.
> > >
> > > And I'm not at all oposed to using tags.
> > > I want to get rid of the layer violation,
> > > which is the one Bad Thing I'm complaining about.
> > >
> > > Also, note that on stop, this strips all tags, leaving it untagged.
> > > On the next cluster boot, if that was really the concern,
> > > all nodes would grab and activate the VG, as it is untagged...
> >
> > That's not how it works. You have to take ownership of the volume
> > before you can activate it. Untagged does not mean a node can
> > activate it without first explicitly setting the tag.
>
> The scenario is this (please correct me):
>
> There are a number of hosts that can see the PVs for this VG.
>
> Some of them may *not* be part of the pacemaker cluster.
I don't expect this to be the case. If the node isn't a member of the cluster
and it can see the PVs, then it is likely just starting up after being fenced
and will rejoin the cluster shortly.
>
> But *ALL* of them have their lvm.conf contain the equivalent of
> global { locking_type = 1 }
> tags { hosttags = 1 }
> activation { volume_list = [ "@*" ] }
>
> If any node is able to see the PVs, but has volume_list undefined,
> "vgchange -ay" would activate it anyways.
> So we are back at "Don't do that".
Ha, well if people want to shoot themselves in the foot, we can't help that
either. The point of the feature is to give people a path to ensure exclusive
activation without using clvmd+dlm. The preferred and safest way is still to
use clvmd.
>
> > I've tested this specific scenario and was unable to activate the
> > volume group manually without grabbing the tag first. Have you tested
> > this and found something contrary to my results? This is how the
> > feature is supposed to work.
>
> See above ;-) no hosttags =1, no volume_list, no checking against it.
>
> Granted, the lvm.conf would be prepared at deployment time,
> so let's assume it is setup ok on all hosts accross the site anyways.
>
> Still, I don't see what we gain by
> check tag against my name
> if not me, check tag againts membership list
> not present
> strip all tags and add my name
This is a redundancy check at the resource level to attempt prevent data
corruption. The "if not me, and not in member list" likely means the owner was
a part of the member list at one point and has been fenced. We feel safe
taking the tags in that case. If the owner is a member of the cluster still
then something is wrong that the admin should investigate. I'm guessing this
could mean fencing failed and the admin unblocked the cluster in a weird state.
If I was writing this feature for the first time I probably wouldn't have
thought to add this check in, but I don't see any harm in leaving it as it
appears to serve a purpose.
-- Vossel
> try vgchange -ay
>
> instead of doing just
> strip all tags and add my name
> try vgchange -ay
>
> In what scenario (appart from Pacemaker not being able to count to 1)
> would the more elaborate version protect us better than the simple one,
> and against what?
>
>
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
