[Linux-cluster] GFS Multi-pathing and trespassed LUNs
Jonathan E Brassow
jbrassow at redhat.com
Tue Jun 7 16:57:11 UTC 2005
On Jun 6, 2005, at 1:13 AM, <JACOB_LIBERMAN at Dell.com> wrote:
> This is a question regarding GFS native multipathing support:
>
> I have a typical redundant mesh topology -- 2 switches, 2 HBAs per
> host,
> 2 storage processors. I create the pool device per the procedure
> outlined in RedHat KB 4343 and then mount it locally. This works fine.
> However, if I trespass the LUN between SPs during a write operation, I
> lose all access to it. I have tried pool_mp with both failover and
> round
> robin policies.
Unfortunately, pool multipathing does not do any special handling when
switching between LUNs - it assumes all LUNs are active/active. This
does not seem to be the case in your instance, as trespassing LUNs is a
way to do active/passive multipathing (IIRC). So, to answer your
questions....
> Here are my questions:
> 1. Is there any way to accommodate trespassed LUNs via pool_mp?
Short answer: no.
Long answer: yes. However, you would have to purchase a copy of
PowerPath and use that for multipathing. Pool understands powerpath
devices and will sit happily upon them - ignoring the other paths to
the device.
With multipathing in RHEL4, underlying hardware idiosyncrasies are
dealt with properly.
> 2. Do you need to do anything special (ie remount the LUN, run
> partprobe, etc.) to accommodate a trespassed LUN?
If it were possible to make the non-useable LUNs unseen to linux, at
least you would have fault tolerance down to the device... However,
this would mean that if a controller failed, you wouldn't be able to
handle it.
> 3. are the pool_mp policies primarily designed to accommodate front-end
> failures? (IE cables, HBAs, switch ports.)
Again, pool MP requires that all paths are active/active.
hope this helps,
brassow
More information about the Linux-cluster
mailing list