multiple vg using the same name
Hi,
I'm currently thinking about clustering our storage arrays into a san structure and how to organize usually identical systems with lvm. I'd like to avoid giving each host a different name for its VG in order to have an identical /etc/fstab on every machine (you don't want to alter a mount-option for a single mountpoint on hundreds of machines by hand or by sed).
I've x machines with x local LVM installations. Each machine uses e.g. /dev/vg/spool as a LV. These local LVs have been installed the usual way (pvcreate, vgcreate, lvcreate), so each VG has its own UUID and the LVM should use the suitable UUIDs to gather the PVs to the suitable VG.
Our idea is to take these PVs via a FC-SAN into one structure, the individual hosts can only see 'their' storage, but failover-nodes can see every PV in the SAN so they can completely take a failed node offline (kick the big, red power button), remount its LV and perform a full take-over.
What happens if the physical volumes of one machine becomes additionaly available to a second machine, so that the second machine has to see e.g. 2, 4 or 8 logical volumes with originally the same name (/dev/vg/spool)?
-lvm completely crashes
-only one vg shows up
-the VGs or LVs are temporarily being renamed when doing 'vgscan -a' -the VGs or LVs are permanently being renamed when doing 'vgscan -a'
What happens if one machine failes, doesn't perform a umount/'vgchange -a n'? Does the failover-node have a chance to use this VG/LV?
I now that somehow I have to figure a way out which VG belongs to which machine, but this may be solved via a map of each machines VG UUID, although just offering a /dev/vg_${hostname}/spool and 'seeing' the VG might be also cool :-)
Anders
Signature · 3 lines
Schlund + Partner AG Systemadministration and Security Erbprinzenstrasse 4-12 v://49.721.91374.50 D-76133 Karlsruhe f://49.721.91374.212
Quoted 7 lines · Anders Henke
Hi,
I'm currently thinking about clustering our storage arrays into a san structure and how to organize usually identical systems with lvm. I'd like to avoid giving each host a different name for its VG in order to have an identical
/etc/fstabon every machine (you don't want to alter a mount-option for a single mountpoint on hundreds of machines by hand or by sed).
Changing /etc/fstab by sed is actually quite simple IMHO.
Put something along the lines of this into your startup script chain before the local mounts after running vgscan.
#!/bin/sh
F=/etc/fstab T=/tmp/fstab.$$
sed "s?\(dev/vg_\)[^/]*/?\1${HOSTNAME}/?" $F > $T
cp $T $F; rm -f $T; unset F T
Quoted 11 lines
I've x machines with x local LVM installations. Each machine uses e.g.
/dev/vg/spoolas a LV. These local LVs have been installed the usual way (pvcreate, vgcreate, lvcreate), so each VG has its own UUID and the LVM should use the suitable UUIDs to gather the PVs to the suitable VG.Our idea is to take these PVs via a FC-SAN into one structure, the individual hosts can only see 'their' storage, but failover-nodes can see every PV in the SAN so they can completely take a failed node offline (kick the big, red power button), remount its LV and perform a full take-over.
Quoted 5 lines
What happens if the physical volumes of one machine becomes additionaly available to a second machine, so that the second machine has to see e.g. 2, 4 or 8 logical volumes with originally the same name (
/dev/vg/spool)?-lvm completely crashes
No (hopefully not ;-)
Quoted 1 line
-only one vg shows up
That's how pv_read_all_pv_of_vg(), the library function which reads the metadata in from the physical volumes behaves today. The PV uuid list is read from the first physical volume found, which has the requested VG name in its metadata. The second VG with the same name will be ignored :-(
BTW: future versions of the LVM will probably have uuid support on the command line like for eg. "vgchange -ay -u VolumeGroupUUID VolumeGroupName".
Quoted 1 line
-the VGs or LVs are temporarily being renamed when doing 'vgscan -a'
No
Quoted 1 line
-the VGs or LVs are permanently being renamed when doing 'vgscan -a'
No. I think renaming the LVs is not needed anyway in case we had support to rename the VG which would give us unique path names again.
Quoted 3 lines
What happens if one machine failes, doesn't perform a umount/'vgchange -a n'? Does the failover-node have a chance to use this VG/LV?
With the existing code only in case the VG names differ.
Quoted 4 lines
I now that somehow I have to figure a way out which VG belongs to which machine, but this may be solved via a map of each machines VG UUID, although just offering a
/dev/vg_${hostname}/spooland 'seeing' the VG might be also cool :-)
That could be configurable with the existing LVM software and would cover the take over quite happily, because the volume group names would be unique.
See above mentioned script.
Quoted 12 lines
Anders
Signature · 8 lines
Schlund + Partner AG Systemadministration and Security Erbprinzenstrasse 4-12 v://49.721.91374.50 D-76133 Karlsruhe f://49.721.91374.212 _______________________________________________ linux-lvm mailing list [email protected] http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
Signature · 12 lines
Regards,
Heinz -- The LVM Guy --
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-