EVA and VMware Failback preference behavior

[jpmartin]

Hi,

i am confused about different setting on VMware Failback preference behavior with EVA storage system.

On document HP StorageWorks 4x00/6x00/8x00 Enterprise
Virtual Array user guide' page 42, located at

http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c01721462/c01721462.pdf,

we find 'No Preference' or 'Path A/B – Failover Only'

and On document 'Configuration best practices for HP StorageWorks Enterprise Virtual Array (EVA) family and VMware vSphere' page 11, located at

http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-2185ENW.pdf

we find 'Path-A-Failover/Failback' or 'Path-B-Failover/Failback'

I believe that VMware ESX 3.5 or 4.0 performs the Failback operation in the case of a failover, but the second document says that the EVA storage system must do this operation.

Is anybody has an idea which is real ?

Jean-Pierre

[Uwe Zessin · Accepted solution]

c01721462 predates ESX 4. If I had to do path optimization in an ESX3 environment I would do explict fixed path selection on the ESX servers and 'No Preference' on the EVA. If the ESX/EVA path selection is not optimized it should self-correct due to the EVA's automatic ownership transfer after an hour of intense traffic. Of course, this assumes an active/active EVA.

Failover/Failback makes sense if you configure the ESX 4 server to honor ALUA. VMware claims that fixed/MRU honor ALUA, too, but I have not seen that and in a thread in the VMware forums here on ITRC it was confirmed by others.

[jpmartin]

That's right, as described on document http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c01736756, i prefer the fixed mode on ESX 3.5 with combination of a static load distribution between the 2 controllers with Failover-only, the failback is done by ESX:

'In case of a path failure ESX take care of routing the IO through the available path and VMkernel resumes using the preferred path when connectivity is restored'

But i thought it was the same settings on v4 with the ALUA implementation which is more valuable, but the v4 Best Practises document gives some confusion.

[Uwe Zessin]

If you look at the bottom of page 4 in 4AA1-2185ENW you'll read:
""It is worth noting that Round Robin and MRU I/O path policies are ALUA-aware""

That sounds like 'fixed' is not, which makes sense, doesn't it? Nothing prevents you from using a manual path optimization on the ESX server's using 'fixed'.

The nice thing with RR/ALUA is that you can change the controller ownership of a vdisk within Command View EVA - ESX4 will notice this after a short time and automatically redirect I/Os to the new controller.

So you once set up the paths for each vdisk on each ESX4 server to RR and from now any change on the EVA will be honored by all configured ESX4 servers.

[jpmartin]

Thank you Uwe,

the explanations are fine and relevant on this subject.