For the Gurus: MPIO LB question with 2003 and EVA8100

[Kase]

Hello, storage gurus! I have a series of questions concerning how MPIO load balancing works (refs at end of post) with Windows 2003 hosts on an EVA8100. If anyone can shed some light on these questions, I would really appreciate it. I split these questions into separate posts so as to assign an appropriate amount of points. Also, I apologize in advance for any awkward or incorrect terminology I might use.

FIRST SCENARIO
Here's the sample config:

SAN fabric: Level 4 NSPOF

Storage Device: EVA 8100
Controller Software: XCS 6.2
LUN1: Preferred path/mode:None
Managing controller: A

Host Device: BL25P G2
OS: Windows 2003 Ent x64 SP2
HBA: Emulex dual-port FC mezz (Port1->A Fabric, Port2->B Fabric)
MPIO: HP DSM EVA 3.03.00
Paths: 8
LB: SQST
ALB: No

Scenario 1 Read IO without ALB
1. Controller A is the owning controller for LUN1. If a read IO request is issued for LUN1, the host MPIO driver determines which path has the shortest queue service time and sends it down that path. This path could go through either port of the FC HBA on the host (consequently, through either fabric) and the target could be any of the 4 host ports on either of the Controllers A or B (for a total of 8 potential targets).

2. If the host ports on Controller A are all very busy, the read IO request might be sent to a host port on Controller B. However, only Controller A (as the owning controller) can issue the actual read IO request to the vDisk. So, Controller B (the proxy controller) issues the read IO request to Controller A, which in turn issues the read IO request to the vDisk and then stores that data in read cache. Controller B then reads that data from mirror cache and transfers the data to the host. This method of proxy requests incurs a high overhead.
3. If the array detects that the majority of read requests are coming from the non-owning controller, it will transition ownership of the vDisk (LUN) to that controller via the implicit LUN transition process to improve performance.

Q1: Is this correct?
Q2: How does the MPIO driver determine SQST?
Q3: Under what conditions would the MPIO driver select a host port on the non-owning controller?
Q4: What is the time interval and percentage of read requests required for the array to initiate implicit LUN transition?
Q5: Other than the EVA User Guide and the SAN Design Reference Guide, are there other documents that go into low-level detail about this process?

References:
HP StorageWorks MultiPath Software - Windows MPIO Load Balancing Across EVA Controllers (http://tinyurl.com/mhmxuq)
HP StorageWorks Enterprise Virtual Arrays (EVAs) - Implicit LUN Transition in Active/Active Arrays (http://tinyurl.com/ld23b3)
HP MPIO Full Featured DSM for EVA4x00/6x00/8x00 family of Disk Arrays 3.03.00 installation and reference guide -Page #27- (http://tinyurl.com/ltgrf9)

[IBaltay]

Hi,

Intro/Q1,Q2

1. scenario without ALB
the read IO goes via all available EVA FP ports (8) of both controllers, which is not optimum because one of the controller is always the proxy controller and its reads go through the mirror port and then via the managing controller...

2 scenario with ALB
the read IO goes only via the EVA FP ports (4) of the managing controller, there are no reads via the mirror port

3. if there is NONE, there is no chance (in Windows MPIO) to failback to the original managing controller, therefore, it should not be none, but SET PREFERED PATH TO CONTOLLER A or B FAILOVER/FAILBACK

Q3 - e.g. after the failback if there is no ALB it will reside on the controller to which it failed over and force it to return to that controller which is not optimum, because thus you cannot be sure to load balance both controllers in a deterministic way...

[IBaltay · Accepted solution]

Q4:
If more then 60% of the READ IO (minimum 5000 IO per hour) occurs within 1 hour at the proxy controller, the EVA controllers swap the managing controller role to it.

[Kase]

Thank you. That is what I was looking for. You actually already answered the next question I had. Thank you for your quick response.