setting up cluster environment

[IFX_1]

Hi all,
Do you know any document guide where I can setup a 2-node OpenVMS cluster? Hope someone have a step by step procedure. THanks.

[Karl Rohwedder]

Ronald,

be sure to have read the 'Guidelines to cluster' and the 'cluster manual' , which can be found at:
http://h71000.www7.hp.com/doc/os82_index.html

The actions nec. depend on your configuration, but mainly you 1st setup on single node to be a cluster -(bootnode) using the SYS$MANAGER:CLUSTER_CONGIG[-LAN] procedure.
If that is working you add the 2nd node to your config. using the same proc.

regards Kalle

[Robert Gezelter]

Ronald,

I concur with Karl, the manual (available from on the documentation CDROM, and the www site - in both HTML and PDF) is well written.

I also agree with Karl's comment about creating a single system disk and then adding a system root to it.

However, I will add that the precisely correct way to do this depends on your situation. The simple case with a single site and two machines is indeed a matter of a single system disk and two "roots" on that disk (this is about the simplest case and is in the manual).

If you are starting on the road to building a disaster-tolerant configuation, where your cluster nodes are widely separated, the issues take on more texture. In that case, you will need to establish separate system disks. My recommendation is to actually do the preparation as it is done for the straightforward case, and then clone the disks (The first system gets system root "0", and the second system gets system root "1"). This retains your options of moving both systems to the same site on the same disk in some contingencies.

I hope that the above is hepful.

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

[Hakan Zanderau ( Anders]

Ronald,

You want to build a 2-node cluster.
For what purpose ? don't get me wrong here......

To set up a cluster is easy, but there are a lot of things to consider doing it.

Will the two nodes share the same disks ?
Two nodes without common disks is not working very well from a cluster point of view.

regards,

Hakan Andersson

[Jan van den Ende]

Ronald,

basically I agree with the previous answers. but, please realise that in order to have a two-node cluster run in a way that survives failure of either node, DOES require a quorum disk.

IF you intend to use a QDSK, then check the paragraph on that item in the above-given manual carefully.

Espacially CREATING a quorum disk is a chinese puzlle itself, but if you carefully follow the instructions, it will work out fine.

.. and on any question or problem, you can always come back here.

Proost.

Have one on me (maybe at the Bootcamp in Nashua?)

jpe

[Colin Butcher · Accepted solution]

I suggest that you think about the storage and interconnects first, then deal with the nodes themselves. Are you trying to have the nodes adjacent, closely separated on the same site in different locations, or widely separated on different sites?

Sort out what data goes where, who needs access to it from wherever they are or wherever the applications are running, what kind of storage you'll be using, whether you'll be using host-based shadowing or controller-based shadowing, how many interconnects you need and which protocols you want (cluster traffic and external traffic).

Nodes just have CPUs, memory, storage and network interfaces - and a node-specific system root on a system disc. The crucial thing to think through is the likely performance requirement and probably need for expansion in the future. By having as little as possible in the node hardware then it's easy enough to swap it for a bigger box later on without having to undertake major cluster reconfiguration - so you minimise the risk of downtime.

Think about how you plan to upgrade it over time - will a single system disc suffice, or will you need two system discs? With a single disc you have downtime while that disc is updated - with two discs you can do a rolling upgrade and leave one node up, but you've increased the management complexity.

If you're using a quorum disc then be aware that you cannot shadow it with host-based shadowing - you need to refer to a physical device name, so you'll want to have that quorum disc directly attached to both nodes and ideally shadowed by hardware (controller-based shadowing).

Designing a cluster is not a trivial exercise - you need to think a lot of issues through around what the cluster is being used for and what the business impacts are of the way you configure it. Start with the business and application requirements and try to translate those into system requirements (availability, maximum permissible downtime, backup window etc. etc.) and go from there. You don't want to end up trying to run a 24x7 application on a 5x12 infrastructure.

Please consider getting professional assistance if you're not experienced - it's a lot cheaper to make mistakes on paper than to compromise your company's business later on. The imminent advanced technical symposium (www.hp.com/go/openvms/bootcamp) is a great place to meet people who can help you and teach you to do it for yourselves. Maybe see you there.

Hope this helps.
Cheers, Colin.

[Robert Gezelter]

Ronald,

I second Colin's comments. I have assisted more than a few clients over the years in recovering from errors in system configuration. Mis-configured clusters can display all sorts of problems, reduced performance being the least of them.

Both Colin and I agree on the basic approach. Start with a thorough understanding of the business requirements, then identify how the cluster configuration addresses these problems.

I hope that the above is helpful.

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

[IFX_1]

Thank you for all your inputs.