OPEN VMS PATH Settings

[ramatemc]

Hi

The current OPENVMS version is

OpenVMS V8.3-1H1.

It is a cluster across sites . (3 nodes in primary and 3 nodes in secondary).

And each DSA is presented with local DGA+ Remote site DGA using  volume shadow.

The 2 sites are interconnected with 2 ISL links.  FC1 and FC2.

I would like to understand what is the best practice to set the Local DGA path setting and remote DGA path setting.

Is it good practice to use , suppose Local DGA$ uses FC1 then Remote DGA$ FC2 to distribute load, as the copy is always sync?

Pls suggest.

[Hoff]

Not one of my favorite phrases, lately.  Tends to be rather heavily used for "covering one's posterior" and not with thinking through the local requirements and expectations.   The best "best practices" are those that are "best" locally, and not with whatever the latest "Best Practices" fads might be.

OpenVMS FC SAN load balancing probably doesn't operate the way folks might think it does.

In general, and in no particular order:

• Gather data, keep data, and find out what your current and historical load is.  If you don't have this data or simply haven't analyzed this data, then any discussions of configuration changes are probably premature.
• Use T4 to gather system performance data.
• I'd allow FC SAN to operate across both links, and not try to link-restrict access.   This for reliability.  Load balancing is a tough problem to solve in general.
• Investigate whether the network physical links are co-routed, or if they're entirely separately routed.  This for reliability.
• Spend more time with testing and then upgrading than has been within this environment; it's past time to get to V8.4 here, and off of V8.3-1H1.
• If there is serious performance limit identified here, then determine if faster storage or faster FC SAN links or related are appropriate, or if adding memory is better, or if manual load balancing is sufficient.   Test, in other words.

Put another way, it's best to spend more time studying your environment and your current configuration and current usage, and consuder any requirements growth predicted, and then with modeling and testing potential improvements, and looking for and predicting any impending performance limitations that might lurk, with adding or swapping hardware as needed, and with keeping relatively current with your releases.

"Your post has been changed because invalid HTML was found in the message body. The invalid HTML has been removed. Please review the message and submit the message when you are satisfied." — none of which I entered here.