[dm-devel] CLARiiON failover modes and DM.
Paul Cote
paul.cote at incipient.com
Mon Nov 19 20:20:14 UTC 2007
Tore
I have found the definitions of all CX failover modes. The SAN admin
assigned failover mode 3. Will DM support option 3 assuming that I
follow EMC's guidance wrt the appropriate settings for the CX in
multipath.conf? ... Or should we reassign the failover mode to 1 per
your email? It seems to me that the path state status will differ
significantly based on the failover modes; specifically 1 or 3. We don't
have FLARE 26 so ALUA mode is N/A.
The failover definitions are:
1) Passive not ready; a command failure when I/O issued to non-owning
SP.
2) quiet trespass on I/O to non-owning SP
3) passive always ready; some commands (TUR) return "passive always
ready" status.
-----Original Message-----
From: dm-devel-bounces at redhat.com [mailto:dm-devel-bounces at redhat.com]
On Behalf Of Tore Anderson
Sent: Monday, November 19, 2007 1:51 PM
To: device-mapper development
Subject: Re: [dm-devel] CLARiiON failover modes and DM.
* Paul Cote
> Is there a specific failover mode that the CX must be set for DM
> interoperability?
You have (at least) two options. CLARiiON Open mode 1 is the
traditional way where all paths to the passive controller is present but
will refuse almost all I/O operations. You'll need to be using the
"emc" hardware handler for that to work, since a proprietary command
needs to be sent to a path to the passive controller in order to
trespass the volume there.
The other option (which is only available in FLARE 26) is ALUA mode
(CLARiiON Open mode 4), where I/O is accepted on both controllers even
though only one is the one handling all the I/O. You can use this
without a hardware handler (there's one in developement, though), but
you'll still want to be prioritising the paths to the preferred
controller for optimal performance. This is the mode I would prefer, at
least. I wrote a bit more about the ALUA mode a few days ago:
http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/4366/focu
s=4435
Regards
--
Tore Anderson
--
dm-devel mailing list
dm-devel at redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
More information about the dm-devel
mailing list