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

Re: shared LVM



On Mon, Jul 08, 2013 at 10:12:45PM +0100, Tomá?? Hulata wrote:
> Hello,
> 
> related to shared lvm I was able to find from official how-to/documets only
> this http://www.tldp.org/HOWTO/LVM-HOWTO/sharinglvm1.html 
> 
> with recommanded procedure. I'm using shared lvm on the top of iscsi device on
> 2 node and SAN is able to see lsv/vgs as well. So I have
> 
> active same volume group on 3 nodes (3rd is SAN)  and all changes that I did
> like create lvs, snaphots, resizing are immediatly reflected to all nodes.
> 
> It looks like metadata are periodically read, without any cluster service
> behind. What is explanation for this behavior?


I believe that LVM will re-read the PV metadata at the beginning of
each LVM command.

I have used the same setup successfully, but there is a few things to
be ware of, as (it says): LVM is not natively cluster-aware.

As far as I am concerned, this basically boils down to:

- Do not run LVM commands simultaneously on two or more modes. At
  least not commands that change the PV <> LV block mappings:
  lvcreate, lvremove, lvextend, lvresize, pvmove etc.  Note that
  "pvmove" can move things in the background: only one at a time.

- If a LV is active on two or more nodes, and one node renames the LV,
  this is not reflected on the other nodes.  The rule of thumb appears
  to be that an LV should only be active on one node at a time.

- Snapshots can be funny: chaos results if two different nodes are
  involved here.  E.g. having one node write to the original LV and a
  different node writing to the snapshot messes things up.  I suspect
  that similar problems will occur with mirrors and different nodes
  writing to different sides of the mirror.

If you do manage to mess things up (I've done that and learned the
hard way), the nodes will generally refuse to modify things. The
already-open LVs will continue to be accessible, but attempts at
creating/removing/moving LVs will be refused as different PVs will
have different LVM serial numbers.  /etc/lvm/archive, vgcfgbackup, vi,
vgcfgrestore, patience, attention to detail (and andrenalin!) are your
friends here.

Hope this helps


-- 
Karl E. Jorgensen


Reply to: