VMS versions in a cluster

[Nigel_18]

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?

[Volker Halle]

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. · Accepted solution]

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

[Willem Grooters]

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.

[Nigel_18]

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

[Ian Miller.]

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.

[Uwe Zessin]

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]

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

[Ian Miller.]

ALPCLUSIO062 and prerequites defininately

[Uwe Zessin]

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

[John Gillings]

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.