Failover Mode 0 LUN Based Trespass Mode This failover mode is the default and works in conjunction with the Auto-trespass feature. Auto-trespass is a mode of operation that is set on a LUN by LUN basis. If Auto-Trespass is enabled on the LUN, the non-owning SP will report that the LUN exists and is available for access. The LUN will trespass to the SP where the I/O request is sent. Every time the LUN is trespassed a Unit Attention message is recorded. If Auto-trespass is disabled, the non-owning SP will report that the LUN exists but it is not available for access. If an I/O request is sent to the non-owning SP, it is rejected and the LUN™s ownership will not change.
Note: The combination of Failover Mode 0 and Auto-Trespass can be dangerous if the host is sending I/O requests to both SP-A and SP-B because the LUN will need to trespass to fulfill each request. This combination is most commonly seen on an HP-UX server using PV-Links. The Auto-trespass feature is enabled through the Initiator Type setting of HP-Autotrespass. A host with no failover software should use the combination of Failover Mode 0 and Auto-trespass disabled.
Failover Mode 1 Passive Not Ready Mode In this mode of operation the non-owning SP will report that all non-owned LUNs exist and are available for access. Any I/O request that is made to the non-owning SP will be rejected. A Test Unit Ready (TUR) command sent to the non-owning SP will return with a status of device not ready. This mode is similar to Failover Mode 0 with Auto-Trespass disabled.
Note: This mode is most commonly used with PowerPath. To a host without PowerPath, and configured with Failover Mode 1, every passive path zoned, for example, a path to SP-B for a LUN owned by SP-A, will show to the server as Not Ready. This will show as with offline errors on a Solaris server, SC_DISK_ERR2 errors with sense bytes 0102, 0700, and 0403 on an AIX server or buffer to I/O errors on a Linux server. If PowerPath is installed, these types of messages should not occur.
Failover Mode 2 DMP Mode In this mode of operation the non-owning SP will report that all non-owned LUNs exist and are available for access. This is similar to Failover Mode 0 with Auto-trespass Enabled. Any I/O requests made to the non-owning SP will cause the LUN to be trespassed to the SP that is receiving the request. The difference between this mode and Auto-trespass mode is that Unit Attention messages are suppressed.
Note: This mode is used for some VERITAS DMP configurations on some operating systems. Because of the similarities to Auto-Trespass, this mode has been known to cause Trespass Storms. If a server runs a script that probes all paths to the CLARiiON, for instance format on a Solaris server, the LUN will trespass to the non owning SP when the I/O request is sent there. If this occurs for multiple LUNs, a significant amount of trespassing will occur.
Failover Mode 3 Passive Always Ready Mode In this mode of operation the non-owning SP will report that all non-owned LUNs exist and are available for access. Any I/O requests sent to the Non-owning SP will be rejected. This is similar to Failover Mode 1. However, any Test Unit Ready command sent from the server will return with a success message, even to the non-owning SP.
Note: This mode is only used on AIX servers under very specific configuration parameters and has been developed to better handle a CLARiiON non-disruptive upgrade (NDU) when AIX servers are attached. See EMC Knowledgebase solution 2431.
In "failovermode 4," both storage processors (SPs) will report that all non-owned units exist and are available for access (Inquiry Peripheral Qualifier code 0x00). If the SP is in the process of shutting down, an Inquiry Peripheral Qualifier code of 0x01 will be returned.
In addition, both SPs will accept and process media access commands to the logical unit. Internally, the logical unit is still owned by one of the SPs. The non-owning SP will internally forward the media access operation to the owning SP for processing. As a result, the array operates in what is termed an Asymmetric Logical 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 non-owning SP will process commands less quickly and efficiently and is thus referred to as the non-optimized path.
The optimized path is driven by LUN ownership, which can be changed in one of four ways in Active/Active mode: 1.Explicit Trespass via Navisphere array management command. 2.Explicit Trespass via Mode Select (Trespass Page) SCSI command. 3.Explicit Trespass via Set Target Port Group SCSI command. 4.Implicit Trespass (within the array) if the I/O load on the non-optimized path exceeds the I/O load on the optimized path by a specified quantity of I/O. If IOPS on non-optimal path to a LUN exceed IOPS by 128k via the optimal path , CLARiiON FLARE code will perform implicit trespass of the LUN.
The Auto-trespass setting of the logical unit is ignored in this mode of operation.
There is a linked document in that article which shows all the different OS's.
Please make sure you set the Failover Mode according to that last article/document, it is vital that this is set correctly as predefined value for your OS (and multipath solution). This is not a "pick and mix" setting.
Alternatively; let us know the OS you are running and we can advice you what to set it to.
HTH
Edwin.
If this answer was useful, please "Mark as Answer" and "Like"
Asymmetrical Active/Active mode(failover mode4)- When configured in ALUA mode,the host issues I/O to either VNX SP.The LUN is owned by one SP that provides an optimal I/O path.The peer SP provides a non-optimal path which is used only when all optimal paths have failed or otherwise unavailable.Failover mode 4 is required for support of VAAI operations on VNX.
For more information,please refer to the below mentioned document:
EdwinVanMierlo
39 Posts
5
January 31st, 2014 01:00
hi John,
The Failover modes 0 thru 3 are explained in KB: https://support.emc.com/kb/9011
This failover mode is the default and works in conjunction with the Auto-trespass feature. Auto-trespass is a mode of operation that is set on a LUN by LUN basis. If Auto-Trespass is enabled on the LUN, the non-owning SP will report that the LUN exists and is available for access. The LUN will trespass to the SP where the I/O request is sent. Every time the LUN is trespassed a Unit Attention message is recorded. If Auto-trespass is disabled, the non-owning SP will report that the LUN exists but it is not available for access. If an I/O request is sent to the non-owning SP, it is rejected and the LUN™s ownership will not change.
Note: The combination of Failover Mode 0 and Auto-Trespass can be dangerous if the host is sending I/O requests to both SP-A and SP-B because the LUN will need to trespass to fulfill each request. This combination is most commonly seen on an HP-UX server using PV-Links. The Auto-trespass feature is enabled through the Initiator Type setting of HP-Autotrespass. A host with no failover software should use the combination of Failover Mode 0 and Auto-trespass disabled.
In this mode of operation the non-owning SP will report that all non-owned LUNs exist and are available for access. Any I/O request that is made to the non-owning SP will be rejected. A Test Unit Ready (TUR) command sent to the non-owning SP will return with a status of device not ready. This mode is similar to Failover Mode 0 with Auto-Trespass disabled.
Note: This mode is most commonly used with PowerPath. To a host without PowerPath, and configured with Failover Mode 1, every passive path zoned, for example, a path to SP-B for a LUN owned by SP-A, will show to the server as Not Ready. This will show as with offline errors on a Solaris server, SC_DISK_ERR2 errors with sense bytes 0102, 0700, and 0403 on an AIX server or buffer to I/O errors on a Linux server. If PowerPath is installed, these types of messages should not occur.
In this mode of operation the non-owning SP will report that all non-owned LUNs exist and are available for access. This is similar to Failover Mode 0 with Auto-trespass Enabled. Any I/O requests made to the non-owning SP will cause the LUN to be trespassed to the SP that is receiving the request. The difference between this mode and Auto-trespass mode is that Unit Attention messages are suppressed.
Note: This mode is used for some VERITAS DMP configurations on some operating systems. Because of the similarities to Auto-Trespass, this mode has been known to cause Trespass Storms. If a server runs a script that probes all paths to the CLARiiON, for instance format on a Solaris server, the LUN will trespass to the non owning SP when the I/O request is sent there. If this occurs for multiple LUNs, a significant amount of trespassing will occur.
In this mode of operation the non-owning SP will report that all non-owned LUNs exist and are available for access. Any I/O requests sent to the Non-owning SP will be rejected. This is similar to Failover Mode 1. However, any Test Unit Ready command sent from the server will return with a success message, even to the non-owning SP.
Note: This mode is only used on AIX servers under very specific configuration parameters and has been developed to better handle a CLARiiON non-disruptive upgrade (NDU) when AIX servers are attached. See EMC Knowledgebase solution 2431.
Failover mode 4 is explained in KB: https://support.emc.com/kb/10989
In "failovermode 4," both storage processors (SPs) will report that all non-owned units exist and are available for access (Inquiry Peripheral Qualifier code 0x00). If the SP is in the process of shutting down, an Inquiry Peripheral Qualifier code of 0x01 will be returned.
In addition, both SPs will accept and process media access commands to the logical unit. Internally, the logical unit is still owned by one of the SPs. The non-owning SP will internally forward the media access operation to the owning SP for processing. As a result, the array operates in what is termed an Asymmetric Logical 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 non-owning SP will process commands less quickly and efficiently and is thus referred to as the non-optimized path.
The optimized path is driven by LUN ownership, which can be changed in one of four ways in Active/Active mode:
1.Explicit Trespass via Navisphere array management command.
2.Explicit Trespass via Mode Select (Trespass Page) SCSI command.
3.Explicit Trespass via Set Target Port Group SCSI command.
4.Implicit Trespass (within the array) if the I/O load on the non-optimized path exceeds the I/O load on the optimized path by a specified quantity of I/O. If IOPS on non-optimal path to a LUN exceed IOPS by 128k via the optimal path , CLARiiON FLARE code will perform implicit trespass of the LUN.
The Auto-trespass setting of the logical unit is ignored in this mode of operation.
The different failover modes for different Operating systems is listed in KB: https://support.emc.com/kb/31521
There is a linked document in that article which shows all the different OS's.
Please make sure you set the Failover Mode according to that last article/document, it is vital that this is set correctly as predefined value for your OS (and multipath solution). This is not a "pick and mix" setting.
Alternatively; let us know the OS you are running and we can advice you what to set it to.
HTH
Edwin.
If this answer was useful, please "Mark as Answer" and "Like"
Jyothi_P_Bharat
317 Posts
2
January 31st, 2014 02:00
Hi,
Asymmetrical Active/Active mode(failover mode4)- When configured in ALUA mode,the host issues I/O to either VNX SP.The LUN is owned by one SP that provides an optimal I/O path.The peer SP provides a non-optimal path which is used only when all optimal paths have failed or otherwise unavailable.Failover mode 4 is required for support of VAAI operations on VNX.
For more information,please refer to the below mentioned document:
http://www.emc.com/collateral/hardware/technical-documentation/h8229-vnx-vmware-tb.pdf
Thanks
Jyothi