You could cluster different versions of VMS, or cluster Alpha VMS with Itanium VMS, or all 3 at once. Alphas and Itaniums can run VAX emulators for legacy compatibility, and the copy of VMS in the emulator can be clustered with the OS on the host machine it's running on.
VMS clusters had uptimes in decades.
Compaq bought DEC. HP bought Compaq. So HP inherited VMS.
When VMS later gained a POSIX mode and TCP/IP it was renamed OpenVMS. VMS Software is now porting VMS to x86-64.
You can port *nix apps to VMS and run them natively. The clustering is still there and still works.
There's a small chance OpenVMS might enjoy a small renaissance, bringing mainframe-like uptime and resilience to commodity x86 hardware, without all that pointless faffing around with VMs and one OS running another different OS inside a VM, with all the duplication and waste that this entails.
Like a lot of people, I really miss filenames with built-in version numbers.
[1] Create a file called `WUMPUS.FOR`
[2] Every time you saved it, the OS automatically incremented the version number: `WUMPUS.FOR;2` and `WUMPUS.FOR;3` and `WUMPUS.FOR;42`.
[3] You could optionally `PURGE WUMPUS.FOR` and all the old versions would be removed, and then the OS would continue making new versions.
With this, who needs a revision control system? For a single user, this is all you need -- you can go back to old versions, copy or rename them to branch, etc.
Unix came along at the same time as this was happening and it never incorporated this functionality, which is why we need clumsy functionality bolted on top, such as Git. The actual versioning info isn't in the filesystem -- it's hidden inside concealed data files.