EVA 4400 MPIO Load Balancing on W2K8: Why using all four paths?

[sam bell]

Hi,

we are currently running the following environment with an EVA 4400 as storage:

- two W2K8 servers with two LUNs each, all presented to controller A. HP MPIO installed with load balancing set to SQST and all four paths being active (controller A + B).

- two ESX 4.1 servers with four LUNs each, all presented to controller B. Path policy set to Round Robin and two paths being active (controller B).

While compared to the VMware environment I/O from the Windows servers is fairly high we want to separate both environments by explicitly using controller A for Windows and controller B for VMware.

I already thought that this was the case by selecting the preferred path/policy for each LUN to the corresponding controller on the EVA.

However, monitoring performance with EVAperf shows that I/O from the Windows servers is still distributed over both controllers (see attached screenshot) whereas I/O from the ESX servers only uses controller B.

I guess this is because MPIO on the Windows servers is configured with all four paths being active. When removing the paths to controller B from the subset, only controller A is used. So basically this is what I want: Using controler A for the Windows servers and controller B for VMware.

But I've got one question: Why is the default behaviour of MPIO to use all four paths and why does it actually do this? Doesn't it make more sense to only use the two (optimized) paths to the LUN owning controller like VMware does?

Especially with the load balancing policy set to SQST I would expect that only the optimized path were used (since there is nothing that needs to be proxied so the time for pending I/O should always be less?).

Any suggestions are highly appreciated!

[Steven Clementi]

First off...

Using Controller A for one environment and Controller B for the other... exclusively... does not make ANY sense at all. It totally blows away the idea of having a Redundant Storage System.

What if Controller A fails? You lose access toall of your Windows data?

What if Controller B fails? All of your VM's go offline?

From the sounds of it... you don't have enough i/o to make even the slightest dent in the i/o capability of the EVA4400. I have customers with 16+ ESX servers and 6+ Windows servers and they don;t have a problem with i/o.


What is "fairly high" ? Do you have numbers you can share?

How many disks do you have in the EVA? How many disk groups?

It sounds to me like you may have a design or configuration problem, vs. a real problem with i/o.

What firmware is running on the EVA? How about your SAN Switches? Which models are they?


Anything else you can share about the environment?


Steven

[sam bell]

In the case one controller becomes unavailable, the hosts are switching to the second one. Using the paths to only one controller doesn't reduce redundancy - it just means that only those paths that are specified are used for I/O. The other paths are still available and are only used when the preferred paths become unavailable.

I actually don't have any problems with poor performance. However, it looks best practice to me to seperate those to systems. Because of ALUA the ESX servers are only using the optimized paths anyway (which are the ones to the LUN managing controller). Why would I want the Windows systems to use those paths as well when there is the possibility to use dedicated controllers for each environment?

Maybe I'm misssing something, but I don't see your point regarding redundancy.

[Steven Clementi]

"- two W2K8 servers with two LUNs each, all presented to controller A. HP MPIO installed with load balancing set to SQST and all four paths being active (controller A + B).

- two ESX 4.1 servers with four LUNs each, all presented to controller B. Path policy set to Round Robin and two paths being active (controller B).
"


Sorry, I misread the second statement since it seemed like you were only allowing the ESX servers to see Controller B. (like one of those trickily worded questions on a test) Appparently that is not the case.

I still don't think you have to split it the way you are saying, but that just my opinion.


Steven

[sam bell]

That's indeed not the case.

However - regarding my original question - do you know why MPIO not only uses the two paths to the LUN managing controller but also the unoptimized paths to the non managing controller?

On the screenshot you can see I/O happening on both controllers. I would have expected to only see I/O on one controller (the managnig one) like it is the case with VMware.

If I understand correctly and only the LUN managing controller can issue I/O to the disks, you can't reach 8gbit/s just by using both controllers. So I really don't understand why MPIO uses both controllers.

[Bulent ILIMAN]

The thing you are trying to apply is the old Active Passive solution.

EVA's are Active/Active since Generation 2 (EVA 4/6/8000)

The native state of an A/A controller pair is to use all available paths with respect to the setting of Load balancing.

If you want to force to use only one controller then you need to set Load balancing to NLB (No Load Balancing) and set a preferred path to the controller you want. It will also failover if a path fails, but without any failure only one path will work to a LUN. You can set each LUN to a different path to utilize paths to Controller A.

[sam bell]

Thanks, however, I already know how to do that and it still doesn't answer my question. I know the EVA is active/active - but from what I know asymmetrical and not symmetrical, which is why only one controller (the managing one) can issue I/O to one Vdisk at a time.

Hence, I still don't understand the benefit of additionally using the unoptimized paths when everything needs to be proxied to the managing controller anyway. Again, VMware only uses the optimized paths and that makes sense to me.

[Sheldon Smith]

Have you gone in to the Windows MPIO DSM Manager and set all presented drives to *enable* ALB? Disabled is still the default setting.

[sam bell]

Yes, however it did not make any difference. But maybe it just takes a while - I performed the test only 10 minutes after enabling ALB.

But am I right in assuming that using both the optimized and unoptimized path doesn't nake any sense?

[Sheldon Smith]

Unless you enable ALB on all the LUNs, the driver will use all paths, not just the optimized ones.
As I recall, Windows checks every five (5) minutes if the IO to the LUN is 2/3's read. Only if the Read ratio is high enough will the paths switch (assuming you have ALB enabled in the first place).

FWIW, the last time I helped a customer set up his HP MPIO DSM and DSM Manager, once we enabled ALB on the LUN, the paths immediately showed which were active and which were "unoptimized".