Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

LVM agents: Deactivate remotely active LVs before attempting EX activation #148

Merged
merged 2 commits into from Oct 10, 2012

Conversation

Projects
None yet
2 participants
Contributor

jbrassow commented Oct 8, 2012

These changes address rhbz729812. When a clustered volume group is part of
an HA LVM setup (an active/passive installation), the LVs that are activated
as part of the 'clvmd' startup may cause problems with the initialization of
HA LVM. This is because HA LVM requires that logical volumes be active
exclusively. If a remote machine activates the LVs via the 'clvmd' init
script before the local machine runs the service manager, it will be
impossible to activate the LVs exclusively.

Should the exclusive activation fail, the solution is to first attempt to
deactivate the LVs cluster-wide (unless the LVs are open - in which case
a deactivation would obviously fail). If the deactivation is successful,
then another attempt can be made to activate exclusively.

This isn't a perfect solution. It is still possible for yet another machine
to attempt a 'clvmd' activation between the time we deactivate and try again
for the exclusive activation. This does substantially close the gap for
problems though. If this solution proves to be insufficient, then 'lvs' or
some other command will need to be given the capabilities to report whether
an LV is active remotely or not. This would give us the ability to distiguish
between a activation that fails because '--partial' was not used and an
exclusive activation that failed because another machine has the LV open
remotely.

jbrassow added some commits Oct 8, 2012

@jbrassow jbrassow LVM agents: Deactivate remotely active LVs before attempting EX activ…
…ation

These changes address rhbz729812.  When a clustered volume group is part of
an HA LVM setup (an active/passive installation), the LVs that are activated
as part of the 'clvmd' startup may cause problems with the initialization of
HA LVM.  This is because HA LVM requires that logical volumes be active
exclusively.  If a remote machine activates the LVs via the 'clvmd' init
script before the local machine runs the service manager, it will be
impossible to activate the LVs exclusively.

Should the exclusive activation fail, the solution is to first attempt to
deactivate the LVs cluster-wide (unless the LVs are open - in which case
a deactivation would obviously fail).  If the deactivation is successful,
then another attempt can be made to activate exclusively.

This isn't a perfect solution.  It is still possible for yet another machine
to attempt a 'clvmd' activation between the time we deactivate and try again
for the exclusive activation.  This does substantially close the gap for
problems though.  If this solution proves to be insufficient, then 'lvs' or
some other command will need to be given the capabilities to report whether
an LV is active remotely or not.  This would give us the ability to distiguish
between a activation that fails because '--partial' was not used and an
exclusive activation that failed because another machine has the LV open
remotely.
5419c92
@jbrassow jbrassow LVM agents: Handle RAID logical volumes.
This commit addresses rhbz824153.  Specifically, it enables the use
of RAID logical volumes in HA-LVM when using the "tagging" (i.e.
not "clvm") method.

One of the advantages of using RAID LVs is that they can handle
transient failures.  If a device goes down in the RAID LV and comes
back later, it can be reintegrated into the array by simply restarting
(or relocating) the service.  Only those portions of the disk that
have changed will be resync'ed - allowing for faster recovery times.
f8a488e

@feist feist added a commit that referenced this pull request Oct 10, 2012

@feist feist Merge pull request #148 from jbrassow/master
LVM agents:  Deactivate remotely active LVs before attempting EX activation
8ee9185

@feist feist merged commit 8ee9185 into ClusterLabs:master Oct 10, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment