Mixing ALUA LUNs with non-ALUA LUNs

[Svedja]

We just upgraded from ESX3.5 to ESXi4.0 and now I have some thoughts about enabling ALUA on our FC-Luns

Our envirovment consists of 4 ESXi servers connected to a Netapp with Ontap 7.3.2 code.

*) What is the proper (recomended) order of changing the multipathing policy? ESX first or on the controller?

I can't find any document/instructions regarding the correct order for this change.

Ie will changing "default" also change current behaviour on exising path/LUNs or just new ones?

*) Can I mix ALUA Luns with non-ALUA luns from the same controller, the later ones so we be able to run MSCS cluster in our envirovment.

I was thinking of creating two initiator groups, with the same WWPN:s, but one mapping ALUA enabled LUNs and the other where I have to use Fixed policy for MSCS virtual machines. I would use default ALUA and manualy handing the handfull Fixed Path LUNs.

/ Dejan

[binoche]

*) What is the proper (recomended) order of changing the multipathing policy? ESX first or on the controller?

[] the controller only; ESX will take default actions when ALUA luns presented

Ie will changing "default" also change current behaviour on exising path/LUNs or just new ones?

[] only new ones will take effect at once; existing luns should be reclaimed

*) Can I mix ALUA Luns with non-ALUA luns from the same controller, the later ones so we be able to run MSCS cluster in our envirovment.

[] it should be OK

binoche, VMware VCP, Cisco CCNA

[Svedja]

To answer on my own question, it seems that ALUA in itself is not a problem for MSCS envirovment, but only selecting RoundRobin path selection.

Those who stick to MRU shouldn't have any problem.

I'm pushing for RR pah selection to get the necessary thruput, but will set a manual Fixed or MRU path selection for the MSCS LUNs.

That is possible from what I can read in the documentation.

This way I don't have to mix ALUA and non-ALUA in the same envirovment, just different path policies.

On the other hand Vmware support recommended a complete shutdown(!) for machines on the FC to enable ALUA.

It can't be changed on the fly with running machines, so you have to evacuate machines first if you can't stop them for a moment.

Luckily, we have a mixed NFS/FC envirovment but for those with FC-only my first suggestion with mixed ALUA / non-ALUA might be the only answer.

I that case I would first create new LUNs on ALUA enabled group, vStorageMigrate to new LUNs, remove old LUNs.

At the same time you would have freshly formated VMFS storage with all the newest bells and whistles in version 3.33