----- Original Message -----
> From: "Brassow Jonathan" <[email protected]>
> To: "David Vossel" <[email protected]>
> Cc: "General Linux-HA mailing list" <[email protected]>, "Lars
> Marowsky-Bree" <[email protected]>, "Fabio M. Di
> Nitto" <[email protected]>
> Sent: Tuesday, May 14, 2013 5:01:02 PM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
>
> On May 14, 2013, at 10:36 AM, David Vossel wrote:
>
> > ----- Original Message -----
> >> From: "Lars Ellenberg" <[email protected]>
> >> To: "Lars Marowsky-Bree" <[email protected]>
> >> Cc: "Fabio M. Di Nitto" <[email protected]>, "General Linux-HA mailing
> >> list" <[email protected]>,
> >> "Jonathan Brassow" <[email protected]>
> >> 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 <[email protected]> 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.
>
> Ok, so I'm coming into this late. Sorry about that.
>
> David has this right. Tagging in conjunction with the 'volume_list' setting
> in lvm.conf is what is used to restrict VG/LV activation. As he mentioned,
> you don't want a machine to boot up and start doing a resync on a mirror
> while user I/O is happening on the node where the service is active. In
> that scenario, even if the LV is not mounted, there will be corruption. The
> LV must not be allowed activation in the first place.
>
> I think the HA scripts written for rgmanager could be considerably reduced in
> size. We probably don't need the matrix of different methods (cLVM vs
> Tagging. VG vs LV). Many of these came about as customers asked for them
> and we didn't want to compromise backwards compatibility. If we are
> switching, now's the time for clean-up. In fact, LVM has something new in
> lvm.conf: 'auto_activation_volume_list'. If the list is defined and a VG/LV
> is in the list, it will be automatically activated on boot; otherwise, it
> will not. That means, forget tagging and forget cLVM. Make users change
> 'auto_activation_volume_list' to include only VGs that are not controlled by
> pacemaker. The HA script should then make sure that
> 'auto_activation_volume_list' is defined and does not contain the VG/LV that
> is being controlled by pacemaker. It would be necessary to check that the
> lvm.conf copy in the initrd is properly set.
>
> The use of 'auto_activation_volume_list' depends on updates to the LVM
> initscripts - ensuring that they use '-aay' in order to activate logical
> volumes. That has been checked in upstream. I'm sure it will go into RHEL7
> and I think (but would need to check on) RHEL6.
The 'auto_activation_volume_list' doesn't seem like it exactly what we want
here though. It kind of works for what we are wanting to achieve but as a side
effect, and I'm not sure it would work for everyone's deployment. For example,
is there a way to set 'auto_activation_volume_list' as empty and still be able
to ensure that no volume groups are initiated at startup?
What I'd really like to see is some sort of 'allow/deny' filter just for
startup. Then we could do something like this.
# start by denying everything on startup
auto_activation_deny_list=[ "@*" ]
# If we need to allow some vg on startup, we can explicitly enable them here.
allow_activation_allow_list=[ "vg1", "vg2" ]
Is something like the above possible yet? Using a method like this, we lose
the added security that the tags give us outside of the cluster management. I
trust pacemaker though :)
-- Vossel
-- Vossel
>
> brassow
>
>
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
