----- 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]>, "Jonathan Brassow" <[email protected]> > Sent: Thursday, May 16, 2013 8:37:08 AM > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation > > > On May 15, 2013, at 7:04 PM, David Vossel wrote: > > > > > > > > > > > ----- 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 :) > > I guess I don't quite understand what you are saying here. If > 'auto_activation_volume_list' is undefined - as it is by default - then > every non-clustered VG will be activated on boot. If it is defined, then > only those volumes defined will be activated. > > So, to do what you want above you would simply: > auto_activation_volume_list = [ "vg1", "vg2" ] > > That denies activation to all but "vg1" and "vg2". > > Did I miss something?
Yeah, that wasn't the point. The point was how do we tell the lvm startup scripts not to start _ANY_ non-clustered volume groups. I don't see a way to express that with the activation list. Would the user just have to initialize the auto_activation list to some dummy value to get this behavior? This is why I suggested a way to explicitly deny all volume groups activation at start up with another list. -- Vossel > brassow > > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
