Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

VMS versions in a cluster

SOLVED
Go to solution
Nigel_18
Occasional Contributor

VMS versions in a cluster

We have the following:-

Alpha V7.1-2
Alpha V6.2
VAX V6.2
Alpha V7.2-1

As anyone any knowledge about a cluster combination as above and then say moving the V7.2-1 Node to V7.3-1 or V7.3-2? I know this is not a supported configuration but will it work?
10 REPLIES
Volker Halle
Honored Contributor

Re: VMS versions in a cluster

Nigel,

as long as the cluster version is the same, cluster communication should work.

$ ANAL/SYS
SDA> exa clu$gb_cluver
CLU$GB_CLUVER: 00000000.00000006 "........"

( VAX V6.2 has CLUVER = 6 - same as Alpha or I64 E8.2)

Happy clustering ;-)

Volker.
Ian Miller.
Honored Contributor
Solution

Re: VMS versions in a cluster

I've got a cluster with Alpha V6.2, V7.3, VAX V6.2 and it works.
____________________
Purely Personal Opinion
Willem Grooters
Honored Contributor

Re: VMS versions in a cluster


I know this is not a supported configuration but will it work?


For VMS, generally spoken "unsupported" is NOT equal to "won't work". For instance, a cluster of Itanium and VAX is "unsupported", but I've seen this type of clusters - even a IA64-AXP-VAX one - at HP-events.

In case it doesn't work, you ARE in trouble since that's what "unsupported" means: "It will (eventually) work; if it does - fine. If is doesn't - you shouldn't have tried in the first place" (Just my interpretation)

So: Simply try it out. Chances are it'll just work.

BUT BEWARE: This may be true for VMS itself (and clustering in particular) but it does not mean that your business software will be happy with this configuration.
Willem Grooters
OpenVMS Developer & System Manager
Nigel_18
Occasional Contributor

Re: VMS versions in a cluster

Thanks for all the replies so far. Ian can you tell me the exact versions of VMS on the nodes (?.?-?) ? Nigel.
Ian Miller.
Honored Contributor

Re: VMS versions in a cluster

Alpha V6.2, V7.3, VAX V6.2 are the exact versions - no -1, etc.
Volker gave the way of checking that the fundemental cluster comms will work. This does not mean everything will work. Hoever the cluster I have has been running for quite a while and seems to be fine.
____________________
Purely Personal Opinion
Uwe Zessin
Honored Contributor

Re: VMS versions in a cluster

Careful, please. There are way more things than the version number of the cluster communications.

We have seen patches for V6.2 to be able to cope with port allocation classes in V7.1 and lock manager changes, for example.
.
Jan van den Ende
Honored Contributor

Re: VMS versions in a cluster

Yes, Uwe, I do remember that too!

Nigel,

Pick up the 6.2 patches, and read thu the release notes.

In the 6.2 time frame there were some patches that needed to be installed BEFORE a mixed version V6 + V7 were possible.

I would give you the specific patch names, but alas, my Prod Hist only reports the amalgamated UPDATE patch, which we apparently installed shortly before (ie, in preparation of) the VMS upgrade.

IIRC, there were some Shadowing issues, and some DECnet V issues (heh, it's been over 5 years, and this IS from human memory, so check it before you take my word for it!)

Success

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Ian Miller.
Honored Contributor

Re: VMS versions in a cluster

ALPCLUSIO062 and prerequites defininately
____________________
Purely Personal Opinion
Uwe Zessin
Honored Contributor

Re: VMS versions in a cluster

That one is required for Y2K (anybody remember?) anyway ;-)
.
John Gillings
Honored Contributor

Re: VMS versions in a cluster

Nigel,

Please remember that mixed version clusters are only ever "migration support". Which means you're only expected to run them for the duration of a rolling upgrade. HP accepts that it may take weeks or even months to complete the upgrade, but, the expectation is that once you've started to upgrade your cluster, you will eventually complete it.

The upshot is, if you report a problem in a mixed version cluster, which is found to be caused by the mismatch, the focus of engineering and services will be on making sure you can get the lagging nodes up to the revision level of the leading nodes.

It all comes down to qualification. The number of version combinations expands exponentially and we simply don't have the resources to qualify all possible cluster permutations. (of course, if you have a specific configuration you NEED to have qualified, please address your truckload of cash to 110 Spit Brook Rd Nashua, NH... :-)

In your case, I'd expect your existing cluster to continue to work, but I think V6.2 and V7.3 are getting too far apart to be worthwhile. The question arises, why would you want to upgrade to V7.3 when the presence of a V6.2 node will prevent you from using most of the new features? No ODS5, no dissimilar shadowing, no dynamic volume expansion, no minicopy, no minimerge, no posix compatibility, etc...

Please think about what you're really trying to achieve. I know it's very cool to have a large cluster with zillion's of versions (guilty m'lud! ;-), but in a real production environment there's no point in pushing the envelope for its own sake. It may make more sense to split the cluster in two and use alternate mechanisms to share data and resources.
A crucible of informative mistakes