Read more
- Community Home
- >
- Servers and Operating Systems
- >
- Operating System - OpenVMS
- >
- VMS versions in a cluster
-
-
Categories
- Topics
- Hybrid IT with Cloud
- Mobile & IoT
- IT for Data & Analytics
- Transformation
- Strategy and Technology
- Products
- Cloud
- Integrated Systems
- Networking
- Servers and Operating Systems
- Services
- Storage
- Company
- Events
- Partner Solutions and Certifications
- Welcome
- Welcome
- Announcements
- Tips and Tricks
- Feedback
-
Blogs
- Alliances
- Around the Storage Block
- Behind the scenes @ Labs
- Converged Data Center Infrastructure
- Digital Transformation
- Grounded in the Cloud
- HPE Careers
- HPE Storage Tech Insiders
- Infrastructure Insights
- Inspiring Progress
- Internet of Things (IoT)
- My Learning Certification
- Networking
- OEM Solutions
- Servers: The Right Compute
- Telecom IQ
- Transforming IT
-
Quick Links
- Community
- Getting Started
- FAQ
- Ranking Overview
- Rules of Participation
- Contact
- Email us
- Tell us what you think
- Information Libraries
- Integrated Systems
- Networking
- Servers
- Storage
- Other HPE Sites
- Support Center
- Enterprise.nxt
- Marketplace
- Aruba Airheads Community
-
Categories
-
Forums
-
Blogs
-
InformationEnglish
VMS versions in a cluster
SOLVED- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-25-2004 10:46 PM
08-25-2004 10:46 PM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-25-2004 11:14 PM
08-25-2004 11:14 PM
Re: VMS versions in a cluster
Re: VMS versions in a cluster
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.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2004 12:19 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2004 01:20 AM
08-26-2004 01:20 AM
Re: VMS versions in a cluster
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2004 03:25 AM
08-26-2004 03:25 AM
Re: VMS versions in a cluster
Re: VMS versions in a cluster
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2004 03:39 AM
08-26-2004 03:39 AM
Re: VMS versions in a cluster
Re: VMS versions in a cluster
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
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2004 05:44 AM
08-26-2004 05:44 AM
Re: VMS versions in a cluster
Re: VMS versions in a cluster
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.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2004 07:22 PM
08-26-2004 07:22 PM
Re: VMS versions in a cluster
Re: VMS versions in a cluster
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
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2004 09:47 PM
08-26-2004 09:47 PM
Re: VMS versions in a cluster
Re: VMS versions in a cluster
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2004 09:51 PM
08-26-2004 09:51 PM
Re: VMS versions in a cluster
Re: VMS versions in a cluster
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-29-2004 09:42 AM
08-29-2004 09:42 AM
Re: VMS versions in a cluster
Re: VMS versions in a cluster
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.
Hewlett Packard Enterprise International
- Communities
- HPE Blogs and Forum
© Copyright 2018 Hewlett Packard Enterprise Development LP