From: Tore Anderson <tore@linpro.no>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: CLARiiON failover modes and DM.
Date: Tue, 20 Nov 2007 08:46:37 +0100 [thread overview]
Message-ID: <474290DD.2080004@linpro.no> (raw)
In-Reply-To: <940B4FF1F5958E4F96FC83C055A2F2611B8C6A@exch-2003.incipient.waltham>
* Paul Cote
> 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.
Mode 1 is what I've used on my CX so far (no support for ALUA yet).
You'll get lots of I/O failures when something wants to access the
passive paths (to scan for partition tables, PV signatures, and so on),
but they're harmless and can be disregarded. You'll need path_checker
emc_clariion, hardware_handler emc, prio_callout mpath_prio_emc, and
path_grouping_policy group_by_prio I think this is the default mode
multipath-tools is set up to handle, so unless you can invite EMC over
for a FLARE 26 upgrade party, I think this is the one you want.
Mode 2 you don't want unless you really know what you're doing. This
will cause the I/O that failed in mode 1 to cause a volume trespass. So
if you boot node 2 in a cluster, the data volumes will bounce around
wildly between SPs until it has finished booting, which'll affect I/O
from the production nodes in your cluster. Same problem if you run
"vgdisplay", "fdisk -l", run HAL (maybe), and so on.
Mode 3 I never tried but it sounds like it's like mode 1, only that the
TEST UNIT READY will succeed. If that's the case the only difference is
probably that you could use path_checker tur instead of path_checker emc.
Regards
--
Tore Anderson
next prev parent reply other threads:[~2007-11-20 7:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-19 16:14 CLARiiON failover modes and DM Paul Cote
2007-11-19 18:51 ` Tore Anderson
2007-11-19 20:20 ` Paul Cote
2007-11-20 7:46 ` Tore Anderson [this message]
2007-11-20 18:59 ` Paul Cote
2007-11-21 7:20 ` Tore Anderson
2007-11-20 11:20 ` Stephan Austermühle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=474290DD.2080004@linpro.no \
--to=tore@linpro.no \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.