[linux-lvm] Mirror between different SAN fabrics

Ty! Boyack ty at nrel.colostate.edu
Thu Dec 28 18:19:02 UTC 2006

I'm wondering how well a "stacked" lvm approach would work for this.  
Could you take LVM and make a two VGs called "Fabric1VG" and 
"Fabric2VG", where you put all of the "fabric 1 paths" to your PVs into 
Fabric1VG, and all your "fabric 2 paths" to your PVs into Fabric2VG.  
Then form volumes in each of those (it would be your responsibility to 
ensure that you have equal volumes in each fabric group).  So you would 
have Fabric1VG/LVa and Fabric2VG/LVa as "equivilant" devices, going 
across your different fabric paths.  Then you could create a new VG 
called MirrorVG and put both Fabric1VG/LVa and Fabric2VG/LVa into 
MirrorVG as PVs.  Then I think you should be able to create a new 
mirrored LV from MirrorVG which would mirror across your two fabrics.  
This should move all of your management into LVM2, which is cluster 
aware, but it 1) makes management a bit messy (but it is all quite 
scriptable), and 2) adds a wierd LVM 2-layer setup.

Anyone know if this 2-layer LVM approach would kill performance (any 
more than a two layer approach of lvm->mdadm or mdadm->lvm)?

Hmm... Thinking about this further, I've been thinking of this 2-layer 
approach for striping and mirroring, but it looks like it might be more 
problematic for your case, where you really want multipath and 
mirroring.  I'm not sure how to ensure that Fabric1VG/LVa and 
Fabric2VG/LVa are placed on the same PV blocks as the other one.  When 
you create Fabric1VG/LVa it might end up on disks 0,1, and 2, but 
Fabric2VG/LVa might end up on disks 1, 2, and 3 (but by different 
paths).  Anyone know any way to ensure that block placement is 
identical?  Is the block allocation algorithm predictable and repeatable 
so that if you have two VGs with equal PVs in each, and you create LVs 
in the same order in each, they get the same PV mapping?  Or is there a 
built-in randomness?  You would likely be assured of the same failures, 
since a bad block on fabric 1 should also be a bad block on fabric 2, 
and a failed PV would fail in both LVs...  Might work, if the placement 
routines are predictably defined. 


mathias.herzog at postfinance.ch wrote:
> [...] 
>> At that stage the md stuff is only ever accessed on a single 
>> node, and there's no problem.
> I will use GFS Filesystem with all cluster nodes up and running at the
> same time, sharing their disks.
> So my problem with the lvm2 mirroring feature still exists. Think I have
> to use the expensive and not easy configurable Continuous Access
> Solution to mirror directly on SAN fabric level...
> Mathias
> Sicherheitshinweis:
> Dieses E-Mail von PostFinance ist signiert. Weitere Informationen finden Sie unter: 
> https://www.postfinance.ch/e-signature.
> Geben Sie Ihre Sicherheitselemente niemals Dritten bekannt.
> ------------------------------------------------------------------------
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

  Ty! Boyack
  NREL Unix Network Manager
  ty at nrel.colostate.edu
  (970) 491-1186

More information about the linux-lvm mailing list