Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message -
> From: "Lars Ellenberg"
> To: linux-ha@lists.linux-ha.org
> Sent: Tuesday, June 18, 2013 4:30:30 AM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
> On Mon, Jun 17, 2013 at 05:53:57PM -0400, David Vossel wrote:
> > > The plan to set 'volume_list=["@*"]' in lvm.conf and override the tags
> > > during
> > > the activation using "vgchange -ay --config 'tags{ mytag{} }' vg0" does
> > > not
> > > work.
> > >
> > > As a similar alternative, I am forcing the volume_list in lvm.conf to be
> > > initialized and not contain the tag the cluster is using for exclusive
> > > activation, and then overriding the volume_list during the activation to
> > > allow volume groups with the cluster tag to be activated. This is a very
> > > similar approach to what Lars original proposed.
> > >
> > > I have finished my initial work on the new set of patches. They can be
> > > found
> > > in this pull request.
> > > https://github.com/ClusterLabs/resource-agents/pull/252
> >
> > This patch is going in tomorrow. Speak up now if you have any reservations
> > concerning it.
>
> Manny thanks for all the work,
> as "tomorrow" has passed,
> I just merged it.
>
> Added a "tag" parameter description.
>
> I'm not sure why we would need to "strip" the tag on stop though?
I see stripping the tag on stop as cleaning up the magic the LVM agent is doing
behind the scenes. The tag is only needed to allow activation, activation is
still prevented outside of the cluster management with or without the tag being
present on the vg.
>
> Or why we would override a different tag on start.
>
> As the "cluster tag" is not supposed to change,
> we could just require the admin to set it once.
Yep, we could do this. It puts another step in the admin's hands that we can
automate though.
>
> Has the side-effect that an admin can revoke the "cluster rights"
> by simply re-tagging with something != the cluster tag.
>
> Do we still want the single-lv activation feature as well?
I gave this a lot of thought. single-lv activation adds additional complexity
to this whole exclusive activation with tags. Rather than complicate the
situation any further, I am in favor of not pulling support for lv activation
to the heartbeat agent. This agent is already complex to manage as it is.
-- Vossel
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> ___
> 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
>
___
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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On Mon, Jun 17, 2013 at 05:53:57PM -0400, David Vossel wrote:
> > The plan to set 'volume_list=["@*"]' in lvm.conf and override the tags
> > during
> > the activation using "vgchange -ay --config 'tags{ mytag{} }' vg0" does not
> > work.
> >
> > As a similar alternative, I am forcing the volume_list in lvm.conf to be
> > initialized and not contain the tag the cluster is using for exclusive
> > activation, and then overriding the volume_list during the activation to
> > allow volume groups with the cluster tag to be activated. This is a very
> > similar approach to what Lars original proposed.
> >
> > I have finished my initial work on the new set of patches. They can be found
> > in this pull request.
> > https://github.com/ClusterLabs/resource-agents/pull/252
>
> This patch is going in tomorrow. Speak up now if you have any reservations
> concerning it.
Manny thanks for all the work,
as "tomorrow" has passed,
I just merged it.
Added a "tag" parameter description.
I'm not sure why we would need to "strip" the tag on stop though?
Or why we would override a different tag on start.
As the "cluster tag" is not supposed to change,
we could just require the admin to set it once.
Has the side-effect that an admin can revoke the "cluster rights"
by simply re-tagging with something != the cluster tag.
Do we still want the single-lv activation feature as well?
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
___
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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message -
> From: "David Vossel"
> To: "General Linux-HA mailing list"
> Sent: Tuesday, June 4, 2013 4:41:06 PM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
> - Original Message -
> > From: "David Vossel"
> > To: "General Linux-HA mailing list"
> > Sent: Monday, June 3, 2013 10:50:01 AM
> > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> >
> > - Original Message -
> > > From: "Lars Ellenberg"
> > > To: linux-ha@lists.linux-ha.org
> > > Sent: Tuesday, May 21, 2013 5:58:05 PM
> > > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> > >
> > > On Tue, May 21, 2013 at 05:52:39PM -0400, David Vossel wrote:
> > > > - Original Message -
> > > > > From: "Lars Ellenberg"
> > > > > To: "Brassow Jonathan"
> > > > > Cc: "General Linux-HA mailing list" ,
> > > > > "Lars
> > > > > Marowsky-Bree" , "Fabio M. Di
> > > > > Nitto"
> > > > > Sent: Monday, May 20, 2013 3:50:49 PM
> > > > > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> > > > >
> > > > > On Fri, May 17, 2013 at 02:00:48PM -0500, Brassow Jonathan wrote:
> > > > > >
> > > > > > On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote:
> > > > > >
> > > > > > > On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
> > > > > > >
> > > > > > >>>>>>> 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.
> > > > > > >
> > > > > > > Only that this is upstream here, so it better work with
> > > > > > > debian oldstale, gentoo or archlinux as well ;-)
> > > > > > >
> > > > > > >
> > > > > > > Would this be good enough:
> > > > > > >
> > > > > > > vgchange --addtag pacemaker $VG
> > > > > > > and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
> > > > > > > then, in the agent start action,
> > > > > > > vgchange -ay --config "tags { pacemaker {} }" $VG
> > > > > > >
> > > > > > > (or have the to be used tag as an additional parameter)
> > > > > > >
> > > > > > > No retagging necessary.
> > > > > > >
> > > > > > > How far back do the lvm tools understand the "--config ..."
> > > > > > > option?
> > > > > >
> > > > > > --config option goes back years and years - not sure of the exact
> > > > > > date,
> > > > > > but
> > > > > > could probably tell with 'git bisect' if you wanted me to.
> > > > > >
> > > > > > The above would not quite be sufficient.
> > > > > > You would still have to change the 'volume_list' field in lvm.conf
> > > > > > (and
> > > > > > update the initrd).
> > > > >
> > > > > You have to do that anyways if you want to make use of tags in this
> > > > > way?
> > > > >
> > > > > > What you are proposing would simplify things in that you would not
> > > > > > need different 'volume_list's on each machine - you could copy
> > > > > > configs
> > >
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message -
> From: "David Vossel"
> To: "General Linux-HA mailing list"
> Sent: Monday, June 3, 2013 10:50:01 AM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
> - Original Message -
> > From: "Lars Ellenberg"
> > To: linux-ha@lists.linux-ha.org
> > Sent: Tuesday, May 21, 2013 5:58:05 PM
> > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> >
> > On Tue, May 21, 2013 at 05:52:39PM -0400, David Vossel wrote:
> > > - Original Message -
> > > > From: "Lars Ellenberg"
> > > > To: "Brassow Jonathan"
> > > > Cc: "General Linux-HA mailing list" ,
> > > > "Lars
> > > > Marowsky-Bree" , "Fabio M. Di
> > > > Nitto"
> > > > Sent: Monday, May 20, 2013 3:50:49 PM
> > > > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> > > >
> > > > On Fri, May 17, 2013 at 02:00:48PM -0500, Brassow Jonathan wrote:
> > > > >
> > > > > On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote:
> > > > >
> > > > > > On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
> > > > > >
> > > > > >>>>>>> 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.
> > > > > >
> > > > > > Only that this is upstream here, so it better work with
> > > > > > debian oldstale, gentoo or archlinux as well ;-)
> > > > > >
> > > > > >
> > > > > > Would this be good enough:
> > > > > >
> > > > > > vgchange --addtag pacemaker $VG
> > > > > > and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
> > > > > > then, in the agent start action,
> > > > > > vgchange -ay --config "tags { pacemaker {} }" $VG
> > > > > >
> > > > > > (or have the to be used tag as an additional parameter)
> > > > > >
> > > > > > No retagging necessary.
> > > > > >
> > > > > > How far back do the lvm tools understand the "--config ..." option?
> > > > >
> > > > > --config option goes back years and years - not sure of the exact
> > > > > date,
> > > > > but
> > > > > could probably tell with 'git bisect' if you wanted me to.
> > > > >
> > > > > The above would not quite be sufficient.
> > > > > You would still have to change the 'volume_list' field in lvm.conf
> > > > > (and
> > > > > update the initrd).
> > > >
> > > > You have to do that anyways if you want to make use of tags in this
> > > > way?
> > > >
> > > > > What you are proposing would simplify things in that you would not
> > > > > need different 'volume_list's on each machine - you could copy
> > > > > configs
> > > > > between machines.
> > > >
> > > > I thought volume_list = [ ... , "@*" ] in lvm.conf,
> > > > assuming that works on all "relevant" distributions as well,
> > > > and a command line "--config" tag would also propagate into that @*.
> > > > It did so for me.
> > > >
> > > > But yes, vlumen_list = [ ... , "pacemaker" ] would be fine as well.
> > >
> > > wait, did we just go around in a circle. If we add "pacemaker" to the
> > > volume list, and use that in every cluster node's config,
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message -
> From: "Lars Ellenberg"
> To: linux-ha@lists.linux-ha.org
> Sent: Tuesday, May 21, 2013 5:58:05 PM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
> On Tue, May 21, 2013 at 05:52:39PM -0400, David Vossel wrote:
> > - Original Message -
> > > From: "Lars Ellenberg"
> > > To: "Brassow Jonathan"
> > > Cc: "General Linux-HA mailing list" , "Lars
> > > Marowsky-Bree" , "Fabio M. Di
> > > Nitto"
> > > Sent: Monday, May 20, 2013 3:50:49 PM
> > > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> > >
> > > On Fri, May 17, 2013 at 02:00:48PM -0500, Brassow Jonathan wrote:
> > > >
> > > > On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote:
> > > >
> > > > > On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
> > > > >
> > > > >>>>>>> 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.
> > > > >
> > > > > Only that this is upstream here, so it better work with
> > > > > debian oldstale, gentoo or archlinux as well ;-)
> > > > >
> > > > >
> > > > > Would this be good enough:
> > > > >
> > > > > vgchange --addtag pacemaker $VG
> > > > > and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
> > > > > then, in the agent start action,
> > > > > vgchange -ay --config "tags { pacemaker {} }" $VG
> > > > >
> > > > > (or have the to be used tag as an additional parameter)
> > > > >
> > > > > No retagging necessary.
> > > > >
> > > > > How far back do the lvm tools understand the "--config ..." option?
> > > >
> > > > --config option goes back years and years - not sure of the exact date,
> > > > but
> > > > could probably tell with 'git bisect' if you wanted me to.
> > > >
> > > > The above would not quite be sufficient.
> > > > You would still have to change the 'volume_list' field in lvm.conf (and
> > > > update the initrd).
> > >
> > > You have to do that anyways if you want to make use of tags in this way?
> > >
> > > > What you are proposing would simplify things in that you would not
> > > > need different 'volume_list's on each machine - you could copy configs
> > > > between machines.
> > >
> > > I thought volume_list = [ ... , "@*" ] in lvm.conf,
> > > assuming that works on all "relevant" distributions as well,
> > > and a command line "--config" tag would also propagate into that @*.
> > > It did so for me.
> > >
> > > But yes, vlumen_list = [ ... , "pacemaker" ] would be fine as well.
> >
> > wait, did we just go around in a circle. If we add "pacemaker" to the
> > volume list, and use that in every cluster node's config, then we've
> > by-passed the exclusive activation part have we not?!
>
> No. I suggested to NOT set that "pacemaker" tag in the config (lvm.conf),
> but only ever explicitly set that tag from the command line as used from
> the resource agent ( --config "tags { pacemaker {} }" )
>
> That would also mean to either override volume_list with the same
> command line, or to have the tag mentioned in the volume_list in
> lvm.conf (but not set it in the tags {} section).
>
> > Also, we're not happy with the auto_activate list because it won't
> > work with old distros?! It's a new feature, why do we have to work
> > with old distros that don't support it?
>
> You are right, we only have to make sure we don't break existing s
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message - > From: "Lars Marowsky-Bree" > To: linux-ha@lists.linux-ha.org > Cc: "Jonathan Brassow" , "Fabio M. Di Nitto" > > Sent: Friday, May 24, 2013 3:35:29 AM > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation > > On 2013-05-15T13:50:45, Lars Ellenberg wrote: > > Are we, in this discussion, perhaps losing the focus on the base > submission of the code merge? > > Can we separate that (IMHO rather worthwhile) patch set from the > exclusive activation part? I don't think we are losing focus, I think we're really close to finalizing the final bits here. If no one objects to the idea you proposed about using a single tag for the entire cluster to ensure exclusive activation, the patches remain similar to the way it is now, I just strip out a bunch of unnecessary stuff. I'm waiting to hear more feedback from Jonathan about this new direction before I act on anything. -- Vossel > (Which I happen to have no strong opinion on, > unless it is already shipped - in which case we need to support it.) > > Regards, > Lars > > -- > Architect Storage/HA > SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, > HRB 21284 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > > ___ > 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 > ___ 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On 2013-05-15T13:50:45, Lars Ellenberg wrote: Are we, in this discussion, perhaps losing the focus on the base submission of the code merge? Can we separate that (IMHO rather worthwhile) patch set from the exclusive activation part? (Which I happen to have no strong opinion on, unless it is already shipped - in which case we need to support it.) Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde ___ 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message -
> From: "Lars Ellenberg"
> To: linux-ha@lists.linux-ha.org
> Sent: Tuesday, May 21, 2013 5:58:05 PM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
> On Tue, May 21, 2013 at 05:52:39PM -0400, David Vossel wrote:
> > - Original Message -
> > > From: "Lars Ellenberg"
> > > To: "Brassow Jonathan"
> > > Cc: "General Linux-HA mailing list" , "Lars
> > > Marowsky-Bree" , "Fabio M. Di
> > > Nitto"
> > > Sent: Monday, May 20, 2013 3:50:49 PM
> > > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> > >
> > > On Fri, May 17, 2013 at 02:00:48PM -0500, Brassow Jonathan wrote:
> > > >
> > > > On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote:
> > > >
> > > > > On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
> > > > >
> > > > >>>>>>> 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.
> > > > >
> > > > > Only that this is upstream here, so it better work with
> > > > > debian oldstale, gentoo or archlinux as well ;-)
> > > > >
> > > > >
> > > > > Would this be good enough:
> > > > >
> > > > > vgchange --addtag pacemaker $VG
> > > > > and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
> > > > > then, in the agent start action,
> > > > > vgchange -ay --config "tags { pacemaker {} }" $VG
> > > > >
> > > > > (or have the to be used tag as an additional parameter)
> > > > >
> > > > > No retagging necessary.
> > > > >
> > > > > How far back do the lvm tools understand the "--config ..." option?
> > > >
> > > > --config option goes back years and years - not sure of the exact date,
> > > > but
> > > > could probably tell with 'git bisect' if you wanted me to.
> > > >
> > > > The above would not quite be sufficient.
> > > > You would still have to change the 'volume_list' field in lvm.conf (and
> > > > update the initrd).
> > >
> > > You have to do that anyways if you want to make use of tags in this way?
> > >
> > > > What you are proposing would simplify things in that you would not
> > > > need different 'volume_list's on each machine - you could copy configs
> > > > between machines.
> > >
> > > I thought volume_list = [ ... , "@*" ] in lvm.conf,
> > > assuming that works on all "relevant" distributions as well,
> > > and a command line "--config" tag would also propagate into that @*.
> > > It did so for me.
> > >
> > > But yes, vlumen_list = [ ... , "pacemaker" ] would be fine as well.
> >
> > wait, did we just go around in a circle. If we add "pacemaker" to the
> > volume list, and use that in every cluster node's config, then we've
> > by-passed the exclusive activation part have we not?!
>
> No. I suggested to NOT set that "pacemaker" tag in the config (lvm.conf),
> but only ever explicitly set that tag from the command line as used from
> the resource agent ( --config "tags { pacemaker {} }" )
>
> That would also mean to either override volume_list with the same
> command line, or to have the tag mentioned in the volume_list in
> lvm.conf (but not set it in the tags {} section).
>
> > Also, we're not happy with the auto_activate list because it won't
> > work with old distros?! It's a new feature, why do we have to work
> > with old distros that don't support it?
>
> You are right, we only have to make sure we don't break existing se
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On Tue, May 21, 2013 at 05:52:39PM -0400, David Vossel wrote:
> - Original Message -
> > From: "Lars Ellenberg"
> > To: "Brassow Jonathan"
> > Cc: "General Linux-HA mailing list" , "Lars
> > Marowsky-Bree" , "Fabio M. Di
> > Nitto"
> > Sent: Monday, May 20, 2013 3:50:49 PM
> > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
> >
> > On Fri, May 17, 2013 at 02:00:48PM -0500, Brassow Jonathan wrote:
> > >
> > > On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote:
> > >
> > > > On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
> > > >
> > > >>>>>>> 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.
> > > >
> > > > Only that this is upstream here, so it better work with
> > > > debian oldstale, gentoo or archlinux as well ;-)
> > > >
> > > >
> > > > Would this be good enough:
> > > >
> > > > vgchange --addtag pacemaker $VG
> > > > and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
> > > > then, in the agent start action,
> > > > vgchange -ay --config "tags { pacemaker {} }" $VG
> > > >
> > > > (or have the to be used tag as an additional parameter)
> > > >
> > > > No retagging necessary.
> > > >
> > > > How far back do the lvm tools understand the "--config ..." option?
> > >
> > > --config option goes back years and years - not sure of the exact date,
> > > but
> > > could probably tell with 'git bisect' if you wanted me to.
> > >
> > > The above would not quite be sufficient.
> > > You would still have to change the 'volume_list' field in lvm.conf (and
> > > update the initrd).
> >
> > You have to do that anyways if you want to make use of tags in this way?
> >
> > > What you are proposing would simplify things in that you would not
> > > need different 'volume_list's on each machine - you could copy configs
> > > between machines.
> >
> > I thought volume_list = [ ... , "@*" ] in lvm.conf,
> > assuming that works on all "relevant" distributions as well,
> > and a command line "--config" tag would also propagate into that @*.
> > It did so for me.
> >
> > But yes, vlumen_list = [ ... , "pacemaker" ] would be fine as well.
>
> wait, did we just go around in a circle. If we add "pacemaker" to the
> volume list, and use that in every cluster node's config, then we've
> by-passed the exclusive activation part have we not?!
No. I suggested to NOT set that "pacemaker" tag in the config (lvm.conf),
but only ever explicitly set that tag from the command line as used from
the resource agent ( --config "tags { pacemaker {} }" )
That would also mean to either override volume_list with the same
command line, or to have the tag mentioned in the volume_list in
lvm.conf (but not set it in the tags {} section).
> Also, we're not happy with the auto_activate list because it won't
> work with old distros?! It's a new feature, why do we have to work
> with old distros that don't support it?
You are right, we only have to make sure we don't break existing setup
by rolling out a new version of the RA. So if the resource agent
won't "accidentally" use a code path where support of a new feature
(of LVM) would be required, that's "good enough" compatibility.
Still it won't hurt to pick the most "compatible" implementation
of several possible "equivalent" ones (RA-feature wise).
I think the proposed --config "tags { pacemaker {} }"
is simpler (no retagging, no re-writing of lvm meta data),
and will work for any setup that knows about tags.
(and I still think the RA should not try to second guess pacemaker and
double check the membership... which in the case of this "cluster wide
tag" would not make sense anymore, anyways)
Of course this cluster wide tag "pacemaker" could be made configurable
itself, so not all clusters in the world using this feature would use
the same tag.
primitive ... params exclusive=1
(implicitly "does the right thing",
and internally guesses whatever that may be,
several times scanning and parsing LVM meta data just for that)
becomes
primitive ... params tag=weather-forecast-scratch-01
(explicitly knows to use the _tag variants of start/monitor/stop,
no parsing and guessing, not try and retry, but just do-it-or-fail)
Does that make sense at all?
Cheers,
Lars
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
___
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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message -
> From: "Lars Ellenberg"
> To: "Brassow Jonathan"
> Cc: "General Linux-HA mailing list" , "Lars
> Marowsky-Bree" , "Fabio M. Di
> Nitto"
> Sent: Monday, May 20, 2013 3:50:49 PM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
> On Fri, May 17, 2013 at 02:00:48PM -0500, Brassow Jonathan wrote:
> >
> > On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote:
> >
> > > On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
> > >
> > >>>>>>> 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.
> > >
> > > Only that this is upstream here, so it better work with
> > > debian oldstale, gentoo or archlinux as well ;-)
> > >
> > >
> > > Would this be good enough:
> > >
> > > vgchange --addtag pacemaker $VG
> > > and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
> > > then, in the agent start action,
> > > vgchange -ay --config "tags { pacemaker {} }" $VG
> > >
> > > (or have the to be used tag as an additional parameter)
> > >
> > > No retagging necessary.
> > >
> > > How far back do the lvm tools understand the "--config ..." option?
> >
> > --config option goes back years and years - not sure of the exact date, but
> > could probably tell with 'git bisect' if you wanted me to.
> >
> > The above would not quite be sufficient.
> > You would still have to change the 'volume_list' field in lvm.conf (and
> > update the initrd).
>
> You have to do that anyways if you want to make use of tags in this way?
>
> > What you are proposing would simplify things in that you would not
> > need different 'volume_list's on each machine - you could copy configs
> > between machines.
>
> I thought volume_list = [ ... , "@*" ] in lvm.conf,
> assuming that works on all "relevant" distributions as well,
> and a command line "--config" tag would also propagate into that @*.
> It did so for me.
>
> But yes, vlumen_list = [ ... , "pacemaker" ] would be fine as well.
wait, did we just go around in a circle. If we add "pacemaker" to the volume
list, and use that in every cluster node's config, then we've by-passed the
exclusive activation part have we not?!
Also, we're not happy with the auto_activate list because it won't work with
old distros?! It's a new feature, why do we have to work with old distros that
don't support it?
-- Vossel
>
> Lars
> ___
> 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
>
___
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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On Fri, May 17, 2013 at 02:00:48PM -0500, Brassow Jonathan wrote:
>
> On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote:
>
> > On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
> >
> >>> 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.
> >
> > Only that this is upstream here, so it better work with
> > debian oldstale, gentoo or archlinux as well ;-)
> >
> >
> > Would this be good enough:
> >
> > vgchange --addtag pacemaker $VG
> > and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
> > then, in the agent start action,
> > vgchange -ay --config "tags { pacemaker {} }" $VG
> >
> > (or have the to be used tag as an additional parameter)
> >
> > No retagging necessary.
> >
> > How far back do the lvm tools understand the "--config ..." option?
>
> --config option goes back years and years - not sure of the exact date, but
> could probably tell with 'git bisect' if you wanted me to.
>
> The above would not quite be sufficient.
> You would still have to change the 'volume_list' field in lvm.conf (and
> update the initrd).
You have to do that anyways if you want to make use of tags in this way?
> What you are proposing would simplify things in that you would not
> need different 'volume_list's on each machine - you could copy configs
> between machines.
I thought volume_list = [ ... , "@*" ] in lvm.conf,
assuming that works on all "relevant" distributions as well,
and a command line "--config" tag would also propagate into that @*.
It did so for me.
But yes, vlumen_list = [ ... , "pacemaker" ] would be fine as well.
Lars
___
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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote:
> On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
>
>>> 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.
>
> Only that this is upstream here, so it better work with
> debian oldstale, gentoo or archlinux as well ;-)
>
>
> Would this be good enough:
>
> vgchange --addtag pacemaker $VG
> and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
> then, in the agent start action,
> vgchange -ay --config "tags { pacemaker {} }" $VG
>
> (or have the to be used tag as an additional parameter)
>
> No retagging necessary.
>
> How far back do the lvm tools understand the "--config ..." option?
--config option goes back years and years - not sure of the exact date, but
could probably tell with 'git bisect' if you wanted me to.
The above would not quite be sufficient. You would still have to change the
'volume_list' field in lvm.conf (and update the initrd).
What you are proposing would simplify things in that you would not need
different 'volume_list's on each machine - you could copy configs between
machines.
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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote:
> > 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.
Only that this is upstream here, so it better work with
debian oldstale, gentoo or archlinux as well ;-)
Would this be good enough:
vgchange --addtag pacemaker $VG
and NOT mention the "pacemaker" tag anywhere in lvm.conf ...
then, in the agent start action,
vgchange -ay --config "tags { pacemaker {} }" $VG
(or have the to be used tag as an additional parameter)
No retagging necessary.
How far back do the lvm tools understand the "--config ..." option?
Lars
___
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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message - > From: "Brassow Jonathan" > To: "David Vossel" > Cc: "General Linux-HA mailing list" , "Lars > Marowsky-Bree" , "Fabio M. Di > Nitto" , "Jonathan Brassow" > 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" > >> To: "David Vossel" > >> Cc: "General Linux-HA mailing list" , "Lars > >> Marowsky-Bree" , "Fabio M. Di > >> Nitto" , "Jonathan Brassow" > >> 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" > >>>> To: "David Vossel" > >>>> Cc: "General Linux-HA mailing list" , "Lars > >>>> Marowsky-Bree" , "Fabio M. Di > >>>> Nitto" > >>>> 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" > >>>>>> To: "Lars Marowsky-Bree" > >>>>>> Cc: "Fabio M. Di Nitto" , "General Linux-HA > >>>>>> mailing > >>>>>> list" , > >>>>>> "Jonathan Brassow" > >>>>>> 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 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 use
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On May 16, 2013, at 9:08 AM, David Vossel wrote: > - Original Message - >> From: "Brassow Jonathan" >> To: "David Vossel" >> Cc: "General Linux-HA mailing list" , "Lars >> Marowsky-Bree" , "Fabio M. Di >> Nitto" , "Jonathan Brassow" >> 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" >>>> To: "David Vossel" >>>> Cc: "General Linux-HA mailing list" , "Lars >>>> Marowsky-Bree" , "Fabio M. Di >>>> Nitto" >>>> 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" >>>>>> To: "Lars Marowsky-Bree" >>>>>> Cc: "Fabio M. Di Nitto" , "General Linux-HA mailing >>>>>> list" , >>>>>> "Jonathan Brassow" >>>>>> 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 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message - > From: "Brassow Jonathan" > To: "David Vossel" > Cc: "General Linux-HA mailing list" , "Lars > Marowsky-Bree" , "Fabio M. Di > Nitto" , "Jonathan Brassow" > 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" > >> To: "David Vossel" > >> Cc: "General Linux-HA mailing list" , "Lars > >> Marowsky-Bree" , "Fabio M. Di > >> Nitto" > >> 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" > >>>> To: "Lars Marowsky-Bree" > >>>> Cc: "Fabio M. Di Nitto" , "General Linux-HA mailing > >>>> list" , > >>>> "Jonathan Brassow" > >>>> 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 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On May 15, 2013, at 7:04 PM, David Vossel wrote: > > > > > - Original Message - >> From: "Brassow Jonathan" >> To: "David Vossel" >> Cc: "General Linux-HA mailing list" , "Lars >> Marowsky-Bree" , "Fabio M. Di >> Nitto" >> 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" >>>> To: "Lars Marowsky-Bree" >>>> Cc: "Fabio M. Di Nitto" , "General Linux-HA mailing >>>> list" , >>>> "Jonathan Brassow" >>>> 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 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 deploymen
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On 05/14/2013 04:20 PM, Lars Marowsky-Bree wrote: > On 2013-05-14T15:59:05, Dejan Muhamedagic wrote: > >>> Appart from a larger restructuring of the code, >> >> For which I'd still like to hear a good explanation. Mind, this >> is not to say that this or that version is better, but that such >> a huge change calls for a serious effort on part of the >> developers and users. > > As far as I understand it (and Fabio has confirmed that), this is > intended to merge the heartbeat LVM and the rgmanager LVM agent, with > the goal to ultimately reduce code duplication. We actually agreed to this merge at LinuxConf 2010 in Boston :) you were there ;) Beside code duplication, there is no reason for rgmanager agents to exists upstream anylonger, since rgmanager and the other components from the old Red Hat stack are deprecated, but they still cover use cases that heartbeat agents do not. Effectively, this would be a full integration process to have one set that does it all. Clearly, the initial merge is bumpy, but the final result also means that users will be able to cover more deployment scenarios and the code is maintained by more developer. Fabio ___ 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message - > From: "Brassow Jonathan" > To: "David Vossel" > Cc: "General Linux-HA mailing list" , "Lars > Marowsky-Bree" , "Fabio M. Di > Nitto" > 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" > >> To: "Lars Marowsky-Bree" > >> Cc: "Fabio M. Di Nitto" , "General Linux-HA mailing > >> list" , > >> "Jonathan Brassow" > >> 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 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 Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On May 14, 2013, at 10:36 AM, David Vossel wrote: > - Original Message - >> From: "Lars Ellenberg" >> To: "Lars Marowsky-Bree" >> Cc: "Fabio M. Di Nitto" , "General Linux-HA mailing >> list" , >> "Jonathan Brassow" >> 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 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. 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message -
> From: "Lars Ellenberg"
> To: "General Linux-HA mailing list"
> Cc: "Jonathan Brassow" , "Lars Marowsky-Bree"
> , "Fabio M. Di Nitto"
>
> Sent: Wednesday, May 15, 2013 6:50:45 AM
> Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation
>
> On Tue, May 14, 2013 at 11:36:54AM -0400, David Vossel wrote:
> > - Original Message -
> > > From: "Lars Ellenberg"
> > > To: "Lars Marowsky-Bree"
> > > Cc: "Fabio M. Di Nitto" , "General Linux-HA mailing
> > > list" ,
> > > "Jonathan Brassow"
> > > 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 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.
>
> The scenario is this (please correct me):
>
> There are a number of hosts that can see the PVs for this VG.
>
> Some of them may *not* be part of the pacemaker cluster.
I don't expect this to be the case. If the node isn't a member of the cluster
and it can see the PVs, then it is likely just starting up after being fenced
and will rejoin the cluster shortly.
>
> But *ALL* of them have their lvm.conf contain the equivalent of
> global { locking_type = 1 }
> tags { hosttags = 1 }
> activation { volume_list = [ "@*" ] }
>
> If any node is able to see the PVs, but has volume_list undefined,
> "vgchange -ay" would activate it anyways.
> So we are back at "Don't do that".
Ha, well if people want to shoot themselves in the foot, we can't help that
either. The point of the feature is to give people a path to ensure exclusive
activation without using clvmd+dlm. The preferred and safest way is still to
use clvmd.
>
> > I've tested this specific scenario and was unable to activate the
> > volume group manually without grabbing the tag first. Have you tested
> > this and found something contrary to my results? This is how the
> > feature is supposed to work.
>
> See above ;-) no hosttags =1, no volume_list, no checking against it.
>
> Granted, the lvm.conf would be prepared at deployment time,
> so let's assume it is setup ok on all hosts accross the site anyways.
>
> Still, I don't see what we gain by
> check tag against my name
> if not me, check tag againts membership list
> not present
> strip all tags and add my name
This is a redundancy check at the resource level to attempt prevent data
corruption. The "if not me, and not in member list" likely means the owner was
a part of the member list at one point and has been fenced. We feel safe
taking the tags in that case. If the owner is a member of the cluster still
then something is wrong that the admin should investigate. I'm guessing this
could mean fencing failed and the admin unblocked the cluster in a weird state.
If I was writing this feature for the first time I probably wouldn't have
thought to add this check in, but I don't see any harm in leaving it as it
appears to serve a purpose.
-- Vossel
>
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On Tue, May 14, 2013 at 11:36:54AM -0400, David Vossel wrote:
> - Original Message -
> > From: "Lars Ellenberg"
> > To: "Lars Marowsky-Bree"
> > Cc: "Fabio M. Di Nitto" , "General Linux-HA mailing
> > list" ,
> > "Jonathan Brassow"
> > 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 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.
The scenario is this (please correct me):
There are a number of hosts that can see the PVs for this VG.
Some of them may *not* be part of the pacemaker cluster.
But *ALL* of them have their lvm.conf contain the equivalent of
global { locking_type = 1 }
tags { hosttags = 1 }
activation { volume_list = [ "@*" ] }
If any node is able to see the PVs, but has volume_list undefined,
"vgchange -ay" would activate it anyways.
So we are back at "Don't do that".
> I've tested this specific scenario and was unable to activate the
> volume group manually without grabbing the tag first. Have you tested
> this and found something contrary to my results? This is how the
> feature is supposed to work.
See above ;-) no hosttags =1, no volume_list, no checking against it.
Granted, the lvm.conf would be prepared at deployment time,
so let's assume it is setup ok on all hosts accross the site anyways.
Still, I don't see what we gain by
check tag against my name
if not me, check tag againts membership list
not present
strip all tags and add my name
try vgchange -ay
instead of doing just
strip all tags and add my name
try vgchange -ay
In what scenario (appart from Pacemaker not being able to count to 1)
would the more elaborate version protect us better than the simple one,
and against what?
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
___
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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message - > From: "Lars Ellenberg" > To: "Lars Marowsky-Bree" > Cc: "Fabio M. Di Nitto" , "General Linux-HA mailing > list" , > "Jonathan Brassow" > 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 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. > > So no, in the current form, > it just *pretends* to protect against a number of things, > but actually does not. > > And that is the other, even worse, Bad Thing. > > > That's similar to what cLVM2 does and protects against, but without > > needing the cLVM2/DLM bits; that has, uhm, advantages too. > > > > In short, I'm in favor of this feature. (Clearly, lge has pointed out > > one or two issues that need fixing, that doesn't detract from the > > idea.) > > But that would be implemented simply by using tags, and on > start: > re-tag with my nodename > activate > > That way, it is always tagged, so no stupid initrd, udev or boot script, > not even a tired admin, will "accidentally" activate it. > > No need for anything else, > no callout to membership necessary. > All that smoke and mirrors adds complexity, and does not buy us anything, > but a false sense of what that could possibly protect us against. > > If it was tagged with an other node name that is in the membership, > then pacemaker would know about it, too, and had made sure it is not > activated there. > > If that other node was not in the membership, > we would re-tag and activate anyways. > > So why not just do that, > document that it is done this way, > and not pretend it would do more than that. > It does not. I've tested this specific scenario and was unable to activate the volume group manually without grabbing the tag first. Have you tested this and found something contrary to my results? This is how the feature is supposed to work. -- Vossel > Lars > > -- > : Lars Ellenberg > : LINBIT | Your Way to High Availability > : DRBD/HA support and consulting http://www.linbit.com > ___ > 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 > ___ 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
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 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... So no, in the current form, it just *pretends* to protect against a number of things, but actually does not. And that is the other, even worse, Bad Thing. > That's similar to what cLVM2 does and protects against, but without > needing the cLVM2/DLM bits; that has, uhm, advantages too. > > In short, I'm in favor of this feature. (Clearly, lge has pointed out > one or two issues that need fixing, that doesn't detract from the > idea.) But that would be implemented simply by using tags, and on start: re-tag with my nodename activate That way, it is always tagged, so no stupid initrd, udev or boot script, not even a tired admin, will "accidentally" activate it. No need for anything else, no callout to membership necessary. All that smoke and mirrors adds complexity, and does not buy us anything, but a false sense of what that could possibly protect us against. If it was tagged with an other node name that is in the membership, then pacemaker would know about it, too, and had made sure it is not activated there. If that other node was not in the membership, we would re-tag and activate anyways. So why not just do that, document that it is done this way, and not pretend it would do more than that. It does not. Lars -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com ___ 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On 2013-05-14T15:59:05, Dejan Muhamedagic wrote: > > Appart from a larger restructuring of the code, > > For which I'd still like to hear a good explanation. Mind, this > is not to say that this or that version is better, but that such > a huge change calls for a serious effort on part of the > developers and users. As far as I understand it (and Fabio has confirmed that), this is intended to merge the heartbeat LVM and the rgmanager LVM agent, with the goal to ultimately reduce code duplication. So that means moving shared code to a library/include, and turning both existing front-ends into wrappers. I'd agree from the way the code was structured before the merge that the rgmanager agent was better suited to be the primary source of the library functions. But the discussion also showed that there were some design decisions made in the heartbeat version that were important - hence, the merged code drops the lvs calls in monitor/status. An important dialogue to have. And such merges of existing code bases are typically less easily broken up into small incremental patches (as any observer of LKML can attest). As far as I can see, it does also provide a few new use cases and improvements. While I agree this invites slightly more audit/review effort, it seems we are in fact getting that here. And as everyone knows, I'm a convergence fanboy, and willing to help out and test this further. > area more than once. Finally, LVM is not without its own set of > oddities which of course vary from version to version. If we're > to go that way, then it should be for a good reason. The reason why we merged the resource agent projects in the first place was convergence, and reducing duplicated code. Exactly because resource agents only seem straightforward, but are actually just as subtle and core to delivering a working cluster as other parts, I think that is a good reason to go this way. Clearly, we want to be careful, do proper inspection, testing, etc. But I'm also not sure how any attempt at merging agent code could happen *without* gutting the existing RAs and turning them into front-ends, and making sure the shared code covers both scenarios. For me, preserving both frontends - and not making one go away - is important, because it allows the configurations that reference either one to continue working. That strikes me as good. In summary, we had a merge that was slightly too broad, but well-intentioned; that got good and important review from Dejan and lge, whose points were addressed; and we're going in a good direction. Lets make sure the remaining points (if any) are hashed out and merged. ;-) (I admit that I'm a bit worried that if this is the amount of effort we go through for something 'as simple as the lvm agent', how much pain will something complex be! But, alas, I can see that it is a constructive and necessary discussion.) > > Maybe this has been originally implemented on request of some customer, > > which was happy once he was able to say "exclusive=1", without thinking > > about technical details? > That'd be my best guess too. Been there myself a few times. Yeah, well, me never of course. *cough* In any case, that might actually be a reason to merge a feature that turns out to not be perfectly well designed (I'm not saying this is one): the merge needs to cover the use cases from before. Since I've been among those beating David up over a certain LRM feature that got dropped during a reimplementation and then was argued back in with exactly that rationale (despite a better design proposal then), even if this was true, I will NOT throw the first stone ;-) Preserving existing deployed features is paramount. (And, of course, that also means the new RA should be as stable as before, too, preferably more so.) Best, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde ___ 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
On 2013-05-14T09:54:55, David Vossel 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. That's similar to what cLVM2 does and protects against, but without needing the cLVM2/DLM bits; that has, uhm, advantages too. In short, I'm in favor of this feature. (Clearly, lge has pointed out one or two issues that need fixing, that doesn't detract from the idea.) Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde ___ 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
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
Hi all, On Tue, May 14, 2013 at 01:22:08PM +0200, Lars Ellenberg wrote: > > This is about pull request > https://github.com/ClusterLabs/resource-agents/pull/222 > "Merge redhat lvm.sh feature set into heartbeat LVM agent" > > Apologies to the CC for list duplicates. Cc list was made by looking at > the comments in the pull request, and some previous off-list thread. > > Even though this is about resource agent feature development, > and thus actually a topic for the -dev list, > I wanted to give this the maybe wider audience of the users list, > to encourage feedback from people who actually *use* this feature > with rgmanager, or intend to use it once it is in the pacemaker RA. > > > > Here is my perception of this pull request, as such very subjective, and > I may have gotten some intentions or facts wrong, so please correct me, > or add whatever I may have missed. > > Appart from a larger restructuring of the code, For which I'd still like to hear a good explanation. Mind, this is not to say that this or that version is better, but that such a huge change calls for a serious effort on part of the developers and users. Yes, LVM is simple, and, yes, resource agents are just silly shell scripts, but we did slip in that area more than once. Finally, LVM is not without its own set of oddities which of course vary from version to version. If we're to go that way, then it should be for a good reason. > this introduces the > feature of "exclusive activation" of LVM volume groups. > > From the commit message: > > This patch leaves the original LVM heartbeat functionality > intact while adding these addition features from the redhat agent. > > 1. Exclusive activation using volume group tags. This feature > allows a volume group to live on shared storage within the cluster > without requiring the use of cLVM for metadata locking. > > 2. individual logical volume activation for local and cluster > volume groups by using the new 'lvname' option. > > 3. Better setup validation when the 'exclusive' option is enabled. > This patch validates that when exclusive activation is enabled, either > a cluster volume group is in use with cLVM, or the tags variant is > configured correctly. These new checks also makes it impossible to > enable the exclusive activation for cloned resources. > > > That sounds great. Why even discuss it, of course we want that. > > But I feel it does not do what it advertises. > Rather I think it gives a false sense of "exclusivity" > that is actually not met. > > (point 2., individual LV activation is ok with me, I think; > my difficulties are with the "exclusive by tagging" thingy) > > So what does it do. > > To activate a VG "exclusively", it uses "LVM tags" (see the LVM > documentation about these). > > Any VG or LV can be tagged with a number of tags. > Here, only one tag is used (and any other tags will be stripped!). > > I try to contrast current behaviour and "exclusive" behaviour: > > start: > non-exclusive: > just (try to) activate the VG > exclusive by tag: > check if a the VG is currently tagged with my node name > if not, is it tagged at all? > if tagged, and that happens to be a node name that > is in the current corosync membership: > FAIL activation > else, it is tagged, but that is not a node name, > or not currently in the membership: > strip any and all tags, then proceed > if not FAILed because already tagged by an other member, > re-tag with *my* nodename > activate it. > > Also it does double check the "ownership" in > monitor: > non-exclusive: > I think due to the high timeout potential under load > when using any LVM commands, this just checks for the presence > of the /dev/$VGNAME directory nowadays, which is lightweight, > and usually good enough (as the services *using* the LVs are > monitored anyways). > exclusive by tag: > it does the above, then, if active, double checks > that the current node name is also the current tag value, > and if not (tries to) deactivate (which will usually fail, > as it can only succeed if it is unused), and returns failure > to Pacemaker, which will then do its recovery cycle. > > By default, Pacemaker would stop all depending resources, > stop this one, and restart the whole stack. > > Which will, in a real split brain situation just > make sure that nodes will keep stealing it from each other; > it does not prevent corruption in any way. > > In a non-split-brain case, this situation "can not happen" > anyways. Unless two nodes raced to activate it, > when it was untagged. > Oops, so it does not prevent that either. > > For completeness, on > stop: >non-exclusive: >
Re: [Linux-HA] LVM Resource agent, "exclusive" activation
- Original Message - > From: "Lars Ellenberg" > To: linux-ha@lists.linux-ha.org > Cc: "David Vossel" , "Fabio M. Di Nitto" > , "Andrew Beekhof" > , "Lars Marowsky-Bree" , "Lon Hohberger" > , "Jonathan Brassow" > , "Dejan Muhamedagic" > Sent: Tuesday, May 14, 2013 6:22:08 AM > Subject: LVM Resource agent, "exclusive" activation > > > This is about pull request > https://github.com/ClusterLabs/resource-agents/pull/222 > "Merge redhat lvm.sh feature set into heartbeat LVM agent" > > Apologies to the CC for list duplicates. Cc list was made by looking at > the comments in the pull request, and some previous off-list thread. > > Even though this is about resource agent feature development, > and thus actually a topic for the -dev list, > I wanted to give this the maybe wider audience of the users list, > to encourage feedback from people who actually *use* this feature > with rgmanager, or intend to use it once it is in the pacemaker RA. > > > > Here is my perception of this pull request, as such very subjective, and > I may have gotten some intentions or facts wrong, so please correct me, > or add whatever I may have missed. > > > Appart from a larger restructuring of the code, this introduces the > feature of "exclusive activation" of LVM volume groups. > > From the commit message: > > This patch leaves the original LVM heartbeat functionality > intact while adding these addition features from the redhat agent. > > 1. Exclusive activation using volume group tags. This feature > allows a volume group to live on shared storage within the cluster > without requiring the use of cLVM for metadata locking. > > 2. individual logical volume activation for local and cluster > volume groups by using the new 'lvname' option. > > 3. Better setup validation when the 'exclusive' option is enabled. > This patch validates that when exclusive activation is enabled, either > a cluster volume group is in use with cLVM, or the tags variant is > configured correctly. These new checks also makes it impossible to > enable the exclusive activation for cloned resources. > > > That sounds great. Why even discuss it, of course we want that. > > But I feel it does not do what it advertises. > Rather I think it gives a false sense of "exclusivity" > that is actually not met. > > (point 2., individual LV activation is ok with me, I think; > my difficulties are with the "exclusive by tagging" thingy) > > So what does it do. > > To activate a VG "exclusively", it uses "LVM tags" (see the LVM > documentation about these). > > Any VG or LV can be tagged with a number of tags. > Here, only one tag is used (and any other tags will be stripped!). > > I try to contrast current behaviour and "exclusive" behaviour: > > start: > non-exclusive: > just (try to) activate the VG > exclusive by tag: > check if a the VG is currently tagged with my node name > if not, is it tagged at all? > if tagged, and that happens to be a node name that > is in the current corosync membership: > FAIL activation > else, it is tagged, but that is not a node name, > or not currently in the membership: > strip any and all tags, then proceed > if not FAILed because already tagged by an other member, > re-tag with *my* nodename > activate it. > > Also it does double check the "ownership" in > monitor: > non-exclusive: > I think due to the high timeout potential under load > when using any LVM commands, this just checks for the presence > of the /dev/$VGNAME directory nowadays, which is lightweight, > and usually good enough (as the services *using* the LVs are > monitored anyways). > exclusive by tag: > it does the above, then, if active, double checks > that the current node name is also the current tag value, > and if not (tries to) deactivate (which will usually fail, > as it can only succeed if it is unused), and returns failure > to Pacemaker, which will then do its recovery cycle. > > By default, Pacemaker would stop all depending resources, > stop this one, and restart the whole stack. > > Which will, in a real split brain situation just > make sure that nodes will keep stealing it from each other; > it does not prevent corruption in any way. > > In a non-split-brain case, this situation "can not happen" > anyways. Unless two nodes raced to activate it, > when it was untagged. > Oops, so it does not prevent that either. > > For completeness, on > stop: >non-exclusive: >just deactivate the VG >exclusive by tag: >double check I am the tag "owner" >then strip that tag (so no tag remains, the VG becomes untagged) >and deactivate. > > So the resource
[Linux-HA] LVM Resource agent, "exclusive" activation
This is about pull request https://github.com/ClusterLabs/resource-agents/pull/222 "Merge redhat lvm.sh feature set into heartbeat LVM agent" Apologies to the CC for list duplicates. Cc list was made by looking at the comments in the pull request, and some previous off-list thread. Even though this is about resource agent feature development, and thus actually a topic for the -dev list, I wanted to give this the maybe wider audience of the users list, to encourage feedback from people who actually *use* this feature with rgmanager, or intend to use it once it is in the pacemaker RA. Here is my perception of this pull request, as such very subjective, and I may have gotten some intentions or facts wrong, so please correct me, or add whatever I may have missed. Appart from a larger restructuring of the code, this introduces the feature of "exclusive activation" of LVM volume groups. >From the commit message: This patch leaves the original LVM heartbeat functionality intact while adding these addition features from the redhat agent. 1. Exclusive activation using volume group tags. This feature allows a volume group to live on shared storage within the cluster without requiring the use of cLVM for metadata locking. 2. individual logical volume activation for local and cluster volume groups by using the new 'lvname' option. 3. Better setup validation when the 'exclusive' option is enabled. This patch validates that when exclusive activation is enabled, either a cluster volume group is in use with cLVM, or the tags variant is configured correctly. These new checks also makes it impossible to enable the exclusive activation for cloned resources. That sounds great. Why even discuss it, of course we want that. But I feel it does not do what it advertises. Rather I think it gives a false sense of "exclusivity" that is actually not met. (point 2., individual LV activation is ok with me, I think; my difficulties are with the "exclusive by tagging" thingy) So what does it do. To activate a VG "exclusively", it uses "LVM tags" (see the LVM documentation about these). Any VG or LV can be tagged with a number of tags. Here, only one tag is used (and any other tags will be stripped!). I try to contrast current behaviour and "exclusive" behaviour: start: non-exclusive: just (try to) activate the VG exclusive by tag: check if a the VG is currently tagged with my node name if not, is it tagged at all? if tagged, and that happens to be a node name that is in the current corosync membership: FAIL activation else, it is tagged, but that is not a node name, or not currently in the membership: strip any and all tags, then proceed if not FAILed because already tagged by an other member, re-tag with *my* nodename activate it. Also it does double check the "ownership" in monitor: non-exclusive: I think due to the high timeout potential under load when using any LVM commands, this just checks for the presence of the /dev/$VGNAME directory nowadays, which is lightweight, and usually good enough (as the services *using* the LVs are monitored anyways). exclusive by tag: it does the above, then, if active, double checks that the current node name is also the current tag value, and if not (tries to) deactivate (which will usually fail, as it can only succeed if it is unused), and returns failure to Pacemaker, which will then do its recovery cycle. By default, Pacemaker would stop all depending resources, stop this one, and restart the whole stack. Which will, in a real split brain situation just make sure that nodes will keep stealing it from each other; it does not prevent corruption in any way. In a non-split-brain case, this situation "can not happen" anyways. Unless two nodes raced to activate it, when it was untagged. Oops, so it does not prevent that either. For completeness, on stop: non-exclusive: just deactivate the VG exclusive by tag: double check I am the tag "owner" then strip that tag (so no tag remains, the VG becomes untagged) and deactivate. So the resource agent tries to double check membership information, as it seems to think it is smarter than Pacemaker. So what does that gain us above just trusting pacemaker? What does that gain us above start: strip all current tags tag with my node name activate (If we insist on useing tags, for whatever other reason we may have to use them) and, for monitor, you could add a $role=Stopped monitor action, to double check that it is not started where it is supposed to be stopped. The norma
