Re: discussion about activation/auto_activation_volume_list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 11/18/2020 12:17 AM, David Teigland wrote:
On Tue, Nov 17, 2020 at 04:00:10PM +0800, heming.zhao@xxxxxxxx wrote:
Hello LVM-maintainers,

Currently activation/auto_activation_volume_list is not enable and it does the default behavior:
   pvscan will activate all the devices on booting.

This rule will trigger a clumsy process in HA (corosync+pacemaker stack) env.

## let me show the scenario:

2 nodes (A & B) share a disk, and using systemid to manage vg/lv on this shared disk.
(keep the activation/auto_activation_volume_list default style: comment out this cfg item)

(below steps come from resource-agent LVM-active script)
1. Node A own & active shared vg/lv, node B standby status.
2. A reboot, B detect & wait for A rejoined cluster.
3. because systemid doesn't be changed, lvm2-pvscan@.service will active the vg/lv on A during booting.
4. A finishes reboot, B starts to switch systemid & active shared vg/lv.
5. on B, pacemaker detects lvm resource is running on both nodes.
6. on B, pacemaker restarts lvm resource and enable it on single node.

## rootcause:

we can see step 3,4,5 is useless if step 3 is non-existent.
So the rootcause is step <3>: node A auto activate shared vg/lv.

I believe there's an assumption that the system or a user will not
activate LVs that are managed by the cluster, i.e. only LVM-activate will
activate LVs managed by the cluster.  Perhaps we could make some attempt
to enforce that, or at least make sure the instructions for LVM-activate
make it clear what to do.

## discussion (how to fix):

Could activation/auto_activation_volume_list support a new symbol/function like "!".
e.g.
auto_activation_volume_list = [ "!vg1", "!vg2/lvol1" ]
the '!' means lvm absolutely doesn't active this vg1 & vg2/lvol1 automatically.

my question:
Does it acceptable for LVM2 adding this new function?

auto_activation_volume_list is difficult to use IMO, and I don't think
many people use it.  Your suggestion sounds reasonable, but I've wondered
if autoactivation should be a property set on the VG or LV itself (i.e.
in the metadata)?  The "activationskip" flag is a possible way to handle
the unwanted autoactivation, and also seems to justify the idea of making
autoactivation a similar flag.
I prefer to use a metadata flag for each VG or LV to skip auto-activation.
Otherwise, it is not easy for the pacemaker cluster to manager a local VG(e.g. local or systemid type) in a cluster via active-passive mode.

Thanks
Gang


Dave


_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux