topic Re: VMS versions in a cluster in Operating System - OpenVMS

VMS versions in a cluster

Nigel_18 — Thu, 26 Aug 2004 05:46:00 GMT

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?

Re: VMS versions in a cluster

Volker Halle — Thu, 26 Aug 2004 06:14:42 GMT

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.

Re: VMS versions in a cluster

Ian Miller. — Thu, 26 Aug 2004 07:19:49 GMT

I've got a cluster with Alpha V6.2, V7.3, VAX V6.2 and it works.

Re: VMS versions in a cluster

Willem Grooters — Thu, 26 Aug 2004 08:20:34 GMT

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.

Re: VMS versions in a cluster

Nigel_18 — Thu, 26 Aug 2004 10:25:25 GMT

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

Re: VMS versions in a cluster

Ian Miller. — Thu, 26 Aug 2004 10:39:30 GMT

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.

Re: VMS versions in a cluster

Uwe Zessin — Thu, 26 Aug 2004 12:44:10 GMT

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.

Re: VMS versions in a cluster

Jan van den Ende — Fri, 27 Aug 2004 02:22:08 GMT

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

Re: VMS versions in a cluster

Ian Miller. — Fri, 27 Aug 2004 04:47:24 GMT

ALPCLUSIO062 and prerequites defininately

Re: VMS versions in a cluster

Uwe Zessin — Fri, 27 Aug 2004 04:51:41 GMT

That one is required for Y2K (anybody remember?) anyway ;-)

Re: VMS versions in a cluster

John Gillings — Sun, 29 Aug 2004 16:42:09 GMT

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.