On May 16, 2013, at 9:08 AM, David Vossel wrote: > ----- Original Message ----- >> From: "Brassow Jonathan" <jbras...@redhat.com> >> To: "David Vossel" <dvos...@redhat.com> >> Cc: "General Linux-HA mailing list" <linux-ha@lists.linux-ha.org>, "Lars >> Marowsky-Bree" <l...@suse.com>, "Fabio M. Di >> Nitto" <fdini...@redhat.com>, "Jonathan Brassow" <jbras...@redhat.com> >> 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" <jbras...@redhat.com> >>>> To: "David Vossel" <dvos...@redhat.com> >>>> Cc: "General Linux-HA mailing list" <linux-ha@lists.linux-ha.org>, "Lars >>>> Marowsky-Bree" <l...@suse.com>, "Fabio M. Di >>>> Nitto" <fdini...@redhat.com> >>>> 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" <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. >>>> >>>> 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? 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 = [ ] ok? brassow _______________________________________________ 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
