[Linux-cluster] GFS Multi-pathing and trespassed LUNs

JACOB_LIBERMAN at Dell.com JACOB_LIBERMAN at Dell.com
Tue Jun 7 18:03:48 UTC 2005


Thanks! So pool_mp will work with an active-active array like a
Symmetrix.

I tried pool on powerpath, and it works very well. 

Thanks, jacob 

-----Original Message-----
From: linux-cluster-bounces at redhat.com
[mailto:linux-cluster-bounces at redhat.com] On Behalf Of Jonathan E
Brassow
Sent: Tuesday, June 07, 2005 11:57 AM
To: linux clustering
Subject: Re: [Linux-cluster] GFS Multi-pathing and trespassed LUNs


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

--
Linux-cluster mailing list
Linux-cluster at redhat.com
http://www.redhat.com/mailman/listinfo/linux-cluster





More information about the Linux-cluster mailing list