HPE EVA Storage
1833471 Members
2809 Online
110052 Solutions
New Discussion

Set LUN Managing Controller

 
Mike Peckston
Occasional Contributor

Set LUN Managing Controller

According to the "HP Storageworks EVA best practice.pdf" for optimal performance you should:

"Manually load balance LUN ownership to both controllers. If dynamic path management software is used, select the shortest-service-time option. Use EVAPerf to measure the load on each controller, and then redistribute LUN ownership as required."

I've got my servers running SQST with ALB (and the SAN set to "No preference" for the LUN).

However the majority of LUNs are using one controller and i cannot workout how to manually assign the LUN ownership.

Anyone know how to manually assign the LUN ownership?
8 REPLIES 8
IBaltay
Honored Contributor

Re: Set LUN Managing Controller

Hi,
In your case, the MPIO ALB SQST dynamicaly selects the path according to the shortest service time. It can be, that one of the controller paths are less utilised permanently and thus becoming the master/managing controller frequently.

If you want to try the static load balancing, it can be set via the set preferred path in the vdisk presentation to evenly distribute them vdisk IO...

the pain is one part of the reality
IBaltay
Honored Contributor

Re: Set LUN Managing Controller

But then of course on the host side the alb should be switched off and the load balancing as well, (or it can be set to LB RR) exactly in sync with the EVA real set preferred path to each vdisk...
the pain is one part of the reality
Uwe Zessin
Honored Contributor

Re: Set LUN Managing Controller

I don't think that is correct. The purpose of enabling ALB in the MPIO is to tell it to only use the paths leading to the controller owning the virtual disk. So unless you use a single preferred path (which disables ALB anyway), you really want to keep it enabled.

I think Mike' setting of:
> running SQST with ALB
> (and the SAN set to "No preference" for the LUN).

is fine. The EVA will round-robin the virtual disk ownership and the hosts _should_ only use the performance /optimized paths.

Unfortunately, the MPIO does not work properly in all cases. I have tried this on a server with two (2) FC ports, but only one port has access to the Port_1 of Controller-1+2. Even the latest MPIO does not honor the ALB setting - it still load balances across both controller ports.

This error(IMO) is documented with the V2 MPIO: all host FC-ports must see the EVA. I found it some time ago when I was troubleshooting a customer's configuration which used 3 FC-ports (2x EVA, 1x tape backup).

At that time I have tested the V2 MPIO with a true single-port server against two EVA controller ports. The ALB setting was honored correctly.
.
IBaltay
Honored Contributor

Re: Set LUN Managing Controller

Uwe,
I agree that Mikes mpio/alb setting is correct, I guess he wanted to compare the perf counters monitoring between:
a) mpio/alb/sqst (dynamic loadbalancing)
b) set preferred path (static loadbalancing)

something like the comparison between the "HP-UX native MPIO and PVlinks on Windows".

Therefore I have suggested the second scenario without the alb/lb to get rid of any alb/lb features on the host side (maybe the only lb which can be compatible with the EVA set preferred path is LB RR, which was mentioned)
the pain is one part of the reality
Mike Peckston
Occasional Contributor

Re: Set LUN Managing Controller

What prompted my question is a slow performance problem being experienced by users. So as a starting point i decided to health check the SAN config and set it to HP's performance best practice recommendation.

Perhaps i am mis-reading HP's recommendation.

I take it to mean:
1. Manually load balance LUN ownership to both controllers
AND
2. If dynamic path management s/w is used then select SQST

Which implies to me that you should:

Manually balance the load on the controllers regardless of how the hosts may be configured as they have no impact on which controller is chosen as the LUN owner.

Use Host MPIO SQST if available - which should mean the host talks to the owning controller. ALB will load balance traffic across the available ports to the owning controller.

From reading other posts i've also seen mention that any traffic that goes to the non owning proxy controller will be routed through the owning controller to honour the disk I/O request.

So perhaps the AND should be an OR ? (and that the host configuration therefore has an impact on which controller is chosen as the owning controller, with the EVA dynamically load balancing the LUN ownership? - not that i've seen any evidence of this).

Also, i did try setting the preferred path for a LUN to set it to use the second controller - but on saving the setting the owning controller remained the same - is there another step requried to actually change the owner?
IBaltay
Honored Contributor

Re: Set LUN Managing Controller

Hi,
this thread is good for understanding the differences:
https://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1233363
the pain is one part of the reality
IBaltay
Honored Contributor

Re: Set LUN Managing Controller

and this doc could be usefull:
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01535361/c01535361.pdf
the pain is one part of the reality
IBaltay
Honored Contributor

Re: Set LUN Managing Controller

this is the HP-UX 11.31 document on the native MPIO.
http://docs.hp.com/en/native-multi-pathing/native_multipathing_wp_AR0803.pdf

It explains the conceipts fairly well and ALUA/ALB basic theory remains the same across all the OS platforms:

dynamic io load distribution - page 9
the disk devices policies - page 10 (they are different in each platform but they show you all ALB variants)

From here you can see better that
a) the so called static LB (EVA set preferred path to controller a or b) can be combined with the LB RR only.

b) if ALB is switched on, it has higher priority than set preferred path (which is ignored)

c) if the static LB on EVA is NONE with no ALB on the host side, the whole IO could go via 1 path only... (io bottleneck)
the pain is one part of the reality