EVA, VMS Blade and preferred paths

[Steve Reece_3]

Hiya,

I should be asking this of my HP Storage Expert, but he's already home for the evening and I have a nagging doubt in my head.

config:
Three EVA6400s with eight disk shelves each.
BL860c blade servers - two enclosures with three and one with eight.
SAN in between the hosts and the storage managed by others. Storage will be configured using Command View and Continuous Access will be doing replication between two of the EVAs.
OpenVMS 8.3-1H1 on all of the blades.

Question:
With VMS being able to do path switching, do I need/want to include a preferred path in the EVA config or should I just rely on VMS to pick a path and, if I don't like it, choose a different path?

With redundant paths between the controllers and no fibre connection between them, I'm suspecting that we should actually just leave VMS to manage it.

Any ideas please???

Steve

[The Brit · Accepted solution]

Steve,
As you can see from the Help for "set preferred_path", this is usually used for MSCP served disks.
You could use this at boot time to mount your disks units using a specific path, you would need to have specific knowledge about the IO characteristics of the volume for your path choices to be even close to optimal.
The alternative would be to let the system select a path at boot time and then, if necessary, modify it later using the "set device /path= /switch". As far as I recall, if a path switch is required, (because the current path in not available) the system will switch to the "next available", not necessarily the best.
Unless you have an extremely IO intensive system with specific "HOT" disks, I would recommend letting the system take care of it.
If you are using Virtual Connect (VC) in your enclosures, then you need to consider your VC SAN configuration to ensure the maximum number of redundant paths.

I would also comment that I am surprised that you are using CA for data replication when Volume Shadowing is both available and superior (assuming that you have the EOE license.) CA on EVA is not really synchronous, even when you specify synchronous. (it is basically asynchronous with a large journal file)

but that is just my opinion, it is of course a personal choice.

HTH

Dave.

[Steve Reece_3]

Thanks Dave.
Host based shadowing would be great, but I can't do that to DR systems that are a couple of hundred miles away and not clustered (the latency of the disks would be too high I fear.)
Steve

[The Brit]

Agreed!

Just be sure that you understand the limitations of CA on the EVA's! Dont get me wrong, I am a big fan of EVA storage, but I work at a location where there have been "issues".

Dave.

[Hoff]

You're probably planning for this, but I'd leave it alone and start rolling up some T4 data under normal load.

I have a basic SAN load-balancing discussion posted at:

http://labs.hoffmanlabs.com/node/1451

And generic DT advice: test the full CA path before you need the recovery.

[Steve Reece_3]

Hi Hoff,

I'm planning on collecting it when this new environment goes live, but the ancient VAX systems that we're running the apps on at the moment doesn't have anything like T4 on it and we're fairly constrained on what we can and can't install.

The SAN management contact that we have has experience of EVA, but none of VMS yet is telling me that he must have preferred controllers configured on the EVA for every LUN.

Steve

[Hoff]

T4 is built on MONITOR /RECORD, and that exists on VAX. So if you can't get to use T4, you can at least get a baseline.

[Steve Reece_3]

Good point! Ta!

[Robert Gezelter]

Steve,

T4 itself is effectively a reporting tool. The CPU-related information can be run directly.

I suggest that you install T4 on one of your Alpha/Itanium systems, and take a careful look at the batch job that collects statistics. It is straightforward to implement the MONTIOR/RECORD, even if the system is significantly behind on revisions.

The resulting data file can then be extracted and used with directly with the T4 analysis tools.

- Bob Gezelter, http://www.rlgsc.com

[Robert Brooks_1]

As far as I recall, if a path switch is required, (because the current path in not available) the system will switch to the "next available", not necessarily the best.

---

Right -- there is no definition of "best".

There is, however, a definition of "worst". An MSCP path will only be automatically switched to if there are no other local paths.
In that case, as soon as a local path becomes available, multipath will automatically "fail back" to that newly-available local path.

Multipath will first try paths that are "connected" before any "non-connected" paths.
This is an older HSG/HSZ artifact from the dual controller setup, where a LUN would only be "connected" to one of the two controllers at a time. For the EVA's, with
active/active support, it's less of an issue, but I believe that there is still a distinction for a dual-controller setup, with a performance penalty on reads.

-- Rob