Product:

Product: CLARiiON CX3 Series

Product: CLARiiON CX4 Series


Description:

How trespassing works using ALUA (Failover mode 4) on a VNX/CLARiiON storage sys
tem?

Resolution:
Since FLARE 26, Asymmetric Active/Active has provided a new way for CLARiiON arr
ays to present LUNs to hosts, eliminating the need for hosts to deal with the LU
N ownership model. Prior to FLARE 26, all CLARiiON arrays used the standard acti
ve/passive presentation feature which one SP "owns" the LUN and all I/O to that
LUN is sent only to that SP. If all paths to that SP fail, the ownership of the
LUN was 'trespassed' to the other SP and the host-based path management software
adjusted the I/O path accordingly.
Asymmetric Active/Active introduces a new initiator Failover Mode (Failover mode
4) where initiators are permitted to send I/O to a LUN regardless of which SP a
ctually owns the LUN.
Manual trespass
when a manual trespass is issued (using Navisphere Manager or CLI) to a LUN on a
SP that is accessed by a host with Failover Mode 1, subsequent I/O for that LUN
is rejected over the SP on which the manual trespass was issued. The failover s
oftware redirects I/O to the SP that owns the LUN.
A manual trespass operation causes the ownership of a given LUN owned by a given
SP to change. If this LUN is accessed by an ALUA host (Failover Mode is set to
4), and I/O is sent to the SP that does not currently own the LUN, this would ca
use I/O redirection. In such a situation, the array based on how many I/Os (thr
eshold of 64000 +/- I/Os) a LUN processes on each SP will change the ownership o
f the LUN.
Path, HBA, switch failure
If a host is configured with Failover Mode 1 and all the paths to the SP that ow
ns a LUN fail, the LUN is trespassed to the other SP by the hosts failover softw
are.
With Failover Mode 4, in the case of a path, HBA, or switch failure, when I/O ro
utes to the non-owning SP, the LUN may not trespass immediately (depending on th
e failover software on the host). If the LUN is not trespassed to the owning SP,
FLARE will trespass the LUN to the SP that receives the most I/O requests to t
hat LUN. This is accomplished by the array keeping track of how many I/Os a LUN
processes on each SP. If the non-optimized SP processes 64,000 or more I/Os than
the optimal SP, the array will change the ownership to the non-optimal SP, maki
ng it optimal.
SP failure
In case of an SP failure for a host configured as Failover Mode 1, the failover
software trespasses the LUN to the surviving SP.
With Failover Mode 4, if an I/O arrives from an ALUA initiator on the surviving
SP (non-optimal), FLARE initiates an internal trespass operation. This operation
changes ownership of the target LUN to the surviving SP since its peer SP is de
ad. Hence, the host (failover software) must have access to the secondary SP so
that it can issue an I/O under these circumstances.
Single backend failure
Before FLARE Release 26, if the failover software was misconfigured (for example
, a single attach configuration), a single back-end failure (for example, an LC
C or BCC failure) would generate an I/O error since the failover software would
not be able to try the alternate path to the other SP with a stable backend.
With release 26 of FLARE, regardless of the Failover Mode for a given host, when
the SP that owns the LUN cannot access that LUN due to a back-end failure, I/O
is redirected through the other SP by the lower redirector. In this situation, t
he LUN is trespassed by FLARE to the SP that can access the LUN. After the fail
ure is corrected, the LUN is trespassed back to the SP that previously owned the
LUN. See the Enabler for masking back-end failures section for more information.


Note: Information in this solution is taken from the White Paper "EMC CLARiiON
Asymmetric Active/Active Feature"