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? 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
