ALUA or Not ALUA

[jsierz]

We are working with several ESX 4.0 U2 hosts and NetApp FAS2050 (Ontap 7.3.3) with Active/Active controllers configuration. We are following the TR-3749 NetApp and Vmware vSphere Storage Best Practices document to make sure we stick to best practices

I'm a confusion regarding enable ALUA or not in the iGroup since the documentation that I have been reading from NetApp and Vmware is not that clear enough and some people is recommending that ALUA should only be enable if you are using Fiber Channel protocol (but it is not our case)

My question are:

1. Should I be enabling ALUA and use the VMW_SATP_ALUA (SATP) with Round Robin MPIO policy ?

2. Should I NOT be enabling ALUA and use the VMW_SATP_DEFAULT_AA  (SATP) with Fixed MPIO policy despite VSC 2.0 is selecting RR ?

I will appreciate any suggestion or other experiences on this.

[aborzenkov]

some people is recommending that ALUA should only be enable if you are using Fiber Channel protocol (but it is not our case)

It is not recommending. ALUA applies only to FCP so if you do not use it you do not need to use ALUA (nor should you even be able to set it for iSCSI igroup).

[jsierz]

Thanks Aborsenkov,

Any suggestion regarding RR or fixed MPIO policy ?

Is VMW_SATP_DEFAULT_AA (default / generic storage) the right SATP that should be picking up ESX 4.0 or I have to change it ?

Thanks

[aborzenkov]

For iSCSI active/active with round robin is fine.

[sam_wozniak]

If ALUA only applies to FCP, then what do the commands "iscsi tpgroup alua set <tpgroup_name> { optimized | nonoptimized } [preferred]" and "iscsi tpgroup show" do?

Asymmetric Logical Unit Access (ALUA) management Data ONTAP supports SCSI ALUA functionality for managing multi-pathed SCSI devices. ALUA provides a standardized mechanism for path discovery and prioritization. Devices are identified by target port IDs, which are then grouped into target port groups Each group has a state which, when configured, enables the host multipathing software to select the appropriate path priorities when accessing a LUN.

For iSCSI, ALUA settings are controlled at the target portal group level using the iscsi tpgroup alua set command. A target portal group can be configured to be either optimized or non-optimized; a host typically uses all the optimized paths before using any non-optimized paths it may find. All target portal groups are optimized by default.

There is also an optional preferred setting that may be used on a target portal group. Check your host's multipathing software documentation to see if it supports ALUA and the preferred setting.

ALUA is enabled on Initiator Groups using the igroup set command. All LUNs mapped to an ALUA enabled igroup will support ALUA functionality.

iscsi tpgroup alua show

Display the ALUA settings for all iSCSI target portal groups.

iscsi tpgroup alua set <tpgroup_name> { optimized | nonoptimized } [preferred]

Configure ALUA priorities for a target portal group. If the preferred argument is not given then the target portal group will not be configured as preferred.

[aborzenkov]

From 8.1 7-mode release notes: “The "Configuring iSCSI target portal groups" topic in the "iSCSI network management" chapter includes information about enabling ALUA. This topic has to be removed because you cannot enable ALUA on iSCSI groups.”

[sam_wozniak]

Thanks for clearing that up.  I've always been told ALUA and iSCSI didn't work together, but the fact that these commands were available always confused me. 

[sam_wozniak]

So while that's true that ALUA isn't supported on iSCSI iGroups, I hope the "iscsi tpgroup alua" commands will be removed.  Do you know if they're gone too?  I see in the 8.1 documentation they don't include the man pages like they did previously.

[radek_kubka]

It's not a question of being supported, or not.

ALUA differentiates between optimized & non-optimized paths, so it fits with the scenario when FCP is used on 7-mode - optimized paths are 'direct' (via the controller owning the LUN), non-optimized paths go through the cluster interconnect.

When using iSCSI, there are no non-optimized paths (there is no way to traverse cluster interconnect, as both nodes have different IP addresses, etc.), so ALUA doesn't make sense.

[scottgelb]

With Cluster Mode though it is useful since a vol move can change node affinity and the TPG state Active/Optimized and Active/Unoptimized are updated for the MPIO on the client.  When cluster-mode gets more adoption we probably will see a lot of new best practice papers.