CLARiiON with Asymmetric Logical Unit Access (ALUA) mode is supported beginning with ESX 4.0.

For CLARiiON, the default failover mode for ESX host is failover m ode 1 with the storage type as Active/Passive. When ESX host is registered in fa ilover mode 4, ALUA mode is enabled. In such a case, the CLARiiON array will beh ave similarly to an Active/Active array. The ESX server applies the "Fixed" poli cy to CLARiiON devices in a VMware native multipathing environment by default. Note the following: ESX 3.5 and earlier do not support ALUA mode ESX 4.0 with VMware native Multipathing fixed policy supports EMC FLARE 04.28.00 .5.704 or later in ALUA mode ESX 4.0 with PowerPath /VE supports FLARE 03.26 or later in ALUA mode ALUA failover mode behavior Starting with FLARE release 03.26, EMC introduced the Asymmetric Active/Active feature for CLARiiON storage arrays. This changes h ow a host handles having multiple communication paths to LUNs on the array by pe rmitting I/O to flow to either, or both, storage processors. CLARiiON Asymmetr ic Active/Active is based on the Asymmetric Logical Unit Access (ALUA) standard. The primary ALUA feature allows any I/O request to be sent to either Storage Pr ocessor (SP), and to be executed by the SP that owns the LUN. However, if a VMwa re ESX Server 4.0 host loses all paths (optimal path) to the owning SP, VMware n ative multipathing software will initiate a trespass using ALUA commands in orde r to maximize I/O performance. Without such trespass, I/O may be sent to the non -owning (non-optimal) SP and then redirected to the owning SP for processing wit hout errors. Use of ALUA failover mode has additional benefits when combined w ith VMware ESX Sever 4.0 native multipathing software, providing automatic resto re of LUNs to its preferred paths after a fault has been repaired. However, this only applies to "Fixed" policy situation. It does not apply to "Round Robin" po licy. The EMC CLARiiON Asymmetric Active/Active Feature (ALUA) whitepaper avai lable on Powerlink, provides an in-depth discussion of ALUA features and benefit s. 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 c ause I/O redirection. In such a situation, the array based on how many I/Os (th reshold of 64000 +/- I/Os) a LUN processes on each SP will change the ownership of 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 host s 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, mak ing 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.

In "failovermode 4," both storage processors (SPs) will report that all non-owne d units exist and are available for access (Inquiry Peripheral Qualifier code 0x 00). If the SP is in the process of shutting down, an Inquiry Peripheral Qualifi er code of 0x01 will be returned. In addition, both SPs will accept and process media access commands to the logic al unit. Internally, the logical unit is still owned by one of the SPs. The nonowning SP will internally forward the media access operation to the owning SP fo r processing. As a result, the array operates in what is termed an Asymmetric Log ical Unit Access" (ALUA) mode of operation. The owning SP will process commands more quickly and efficiently and is thus referred to as the optimized path. The no n-owning SP will process commands less quickly and efficiently and is thus refer red to as the non-optimized path. The optimized path is driven by LUN ownership, which can be changed in one of fo ur ways in Active/Active mode: Explicit Trespass via Navisphere array management command. Explicit Trespass via Mode Select (Trespass Page) SCSI command. Explicit Trespass via Set Target Port Group SCSI command. Implicit Trespass (within the array) if the I/O load on the non-optimized path e xceeds the I/O load on the optimized path by a specified quantity of I/O. The Auto-trespass setting of the logical unit is ignored in this mode of operati

on.