Date: Tue, 9 Dec 2014 14:59:01 +0100 From: patpro@patpro.net To: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org> Subject: Re: multipath problem: active provider chosen on passive FC path? Message-ID: <D6081D56-776E-4F71-B6C1-39A41110711C@patpro.net> In-Reply-To: <C9246F8D-076B-4D2D-93E4-C2FECC52B888@patpro.net> References: <23F06C2E-558A-4E68-AD35-B3CD49760DFE@patpro.net> <81548287-A118-4AFD-8AB5-F76CD3B060FF@samplonius.org> <C9246F8D-076B-4D2D-93E4-C2FECC52B888@patpro.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 d=E9c. 2014, at 22:33, Patrick Proniewski <patpro@patpro.net> =
wrote:
>> FC switches are typically active-active, as the FC switch fabric is =
"intelligent" and doesn't have looping issues like ethernet.
>>=20
>> Your issue is probably on the storage array. Storage arrays =
typically have an OS profile, and various advanced settings for how a =
LUN is exported to a client. Storage arrays typically support SCSI =
Reservations, where the LUN must be reserved before it can be used. =
Also, storage arrays typically have multiple controller cards, and =
typically an LUN is owned by one of the controllers at a time. The =
storage array can signal to the client via SCSI that it wants to move =
the the ownership to another controller. With proper client support, =
migrating a LUN to another controller is typically hit-less.=20
>>=20
>> In your case, the storage array is probably configured to use one =
controller/path at a time. And it is probably expecting to see specific =
SCSI messages between itself and the host. These type of settings are =
typically set by the OS profile.
>>=20
>> Generally, storage arrays work best if you only send IO to one =
controller at a time. And this involves co-ordination between the array =
and the client using SCSI control messages. Though active-active paths =
can usually be supported as well.
>=20
>=20
> Thank you for your reply. The SAN is an EMC VNX 5300. By default it =
presents LUNs using ALUA as failover mechanism. I though GEOM could not =
handle ALUA properly, so I changed the failover setting for this LUN, =
now the FreeBSD hang during boot. If I boot in single user mode, it =
boots completely but the result is the same default active path is not =
functioning correctly.
>=20
> Tomorrow, I'll try another failover setting (dubbed "legacy"). The SAN =
also allows me to specify initiator type (default to Clariion), I'll dig =
into this setting to see if something exists that is more adapted to =
FreeBSD host.
Ok, I've tried a lot of things, but the problem is the same: I can =
create a gmultipath device, play with it, but it will always have very =
poor performances until providers are marked "FAIL".
Eventually it ends with this kind of situation:
# gmultipath status
Name Status Components
multipath/SPLUNK_2 DEGRADED da3 (PASSIVE)
da7 (FAIL)
da2 (ACTIVE)
da6 (FAIL)
If I play with every settings, I can come up with more than 70 =
combinations. Far more than I can afford to test, unfortunately. Unless =
a clever solution exists that I don't know yet, I'll have to give up on =
FreeBSD for this project.
I've asked EMC for support. Let's hope it does not end with a "not in =
compatibility matrix" answer.
Any help still appreciated...
Patrick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D6081D56-776E-4F71-B6C1-39A41110711C>