----- 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 9:32:38 AM > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation > > > On May 16, 2013, at 9:08 AM, 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]>, "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. > > Surely they will want the VG that contains their root file system?
I would think so, but that isn't a requirement. > auto_activation_volume_list = [ "root_vg" ] > > That will deny all others. If they have no volume groups for their root VG, > then simply: > > auto_activation_volume_list = [ ] Yep, if initializing an empty list keeps all local volume groups from activating, then that will work great. -- Vossel > ok? > > brassow _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
