ALUA For Netapp, Windows, and VMWare
What is ALUA and why do I need it?
ALUA is an acronym that stands for "Asymmetric Logical Unit Access". For SANs, typically there are many paths from your servers to your storage - this is OK because you don't want any single point of failure. However, it's a problem if you have two storage controllers/servers that can access the same disk/LUN. Without ALUA your servers might take a non-optimal path to get to the LUNS. This is best illustrated here (image from NetApp):
ALUA was designed to solve this problem by making the client/initiator aware of the different paths, and to automatically choose the optimal path (AKA "Primary" path in the illustration above). The non-optimal/non-primary paths will still be available, but will only be used if the primary path becomes unavailable. If you aren't using ALUA and your hosts are using non-optimal paths, you may experience increased latency / reduced performance. For NetApp, your two storage controllers are connected by a high speed interface called a "VTIC", so I'm guessing that the performance impact is not huge, but I don't have any numbers or stats to back that up. I've also been told that this can complicate cluster failovers and Ontap upgrades.
The examples I have here are for NetApp, but most other storage vendors (EMC, Dell, HP, etc.) support ALUA as well, and the concepts still apply. If you are getting messages like "FCP Partner Path Misconfigured", you probably have this problem.
You can also detect the problem by using the "lun stats" command, below. Notice the "Partner" Ops and kB columns - this is measuring the amount of traffic that is going over the non-optimal path (IE: over the VTIC):
NETAPP01> lun stats -i 5 -o Read Write Other QFull Read Write Average Queue Partner Lun Ops Ops Ops kB kB Latency Length Ops kB 0 23 0 0 12 1076 1.88 1.00 23 1088 /vol/gmxstfsas_exc01/gmxstfsas_exc01 2 19 0 0 818 498 0.57 0.08 0 0 /vol/gmxstfsas_exc04/gmxstfsas_exc04 2 16 0 0 89 898 1.90 1.02 0 0 /vol/gmxstfsas_exc03/gmxstfsas_exc03 0 14 0 0 204 276 0.79 0.09 14 481 /vol/gmxstfsas_exc02/gmxstfsas_exc02 0 0 0 0 0 0 0.00 1.01 0 0 /vol/gmxstfsas_sql10/gmxstfsas_sql10 0 0 0 0 0 0 0.00 1.00 0 0 /vol/gmxstfsas_sql09/gmxstfsas_sql09 0 0 0 0 0 0 0.00 0.05 0 0 /vol/gmxstfsas_sql08/gmxstfsas_sql08
To fix this, you need to configure both the target and the initiator. On NetApp, ALUA is set per igroup. You can check to see the current alua settings with:
igroup show -vIf ALUA is on, you will see ALUA: Yes
You can turn on ALUA on an igroup with the command below:
NETAPP01> igroup set uatstbwy01 alua yes NETAPP01> igroup show -v uatmzone01 (FCP): OS Type: windows Member: 21:00:00:c0:dd:15:dc:c9 (logged in on: vtic, 3a) Member: 21:00:00:c0:dd:15:dc:cb (logged in on: 3b, vtic) Member: 21:00:00:c0:dd:14:72:a9 (logged in on: vtic, 3a) Member: 21:00:00:c0:dd:14:72:ab (logged in on: 3b, vtic) ALUA: YesOn windows 2008 servers, you'll need to install Windows MPIO, then install Data ONTAP DSM. OnTap DSM allows Windows 2008 to be aware of the different paths to storage, as illustrated below:
In the "State" column you can see the preferred paths (optimized) and these will be used exclusively unless there is a problem with your storage infrastructure, in which case the unoptimized paths will be used. (Pay no attention to the "Preferred Path" column - apparently this is not used and is a bit misleading.)
On VMWare ESXi servers, you can set ALUA as well. If ALUA is not configured correctly, you may see the following alerts about MPIO settings:
To fix this, make sure you have ALUA enabled for your igroups on the NetApp (per above). In VCenter, Right click and choose "Manage Paths" (under "Details")
For more details on FCP Partner Path Misconfigured messages, see this netapp KB support link