topic Re: Boot in Operating System - OpenVMS

Boot

Mulder_1 — Thu, 12 Feb 2009 13:02:50 GMT

How do I install Open VMS on a SAN disk with multiple root ?

The disk is visible from >>> prompt.

The SAN disk which is also the system disk of Server A will also be shared by Server B,C and D.
The servers will be members of the same cluster.

I need to setup multiple roots on the same disk.

Thanks

Re: Boot

Volker Halle — Thu, 12 Feb 2009 13:14:15 GMT

Mulder,

if the disk is currently 'empty', boot from the OpenVMS operating system CD and install OpenVMS onto the $1$DGAn: disk.

Set up and configure system A. Root will default to [SYS0].

Make the system a cluster member using @CLUSTER_CONFIG_LAN.

Then configure the other systems (roots) from system A by again using @CLUSTER_CONFIG_LAN and adding additional nodes to your system disk.

Once the roots for the other systems have been configured, use WWIDMGR on the other nodes to configure the path to the system disk and make sure to select the correct root in BOOT_OSFLAGS, i.e. BOOT_OSFLAGS 1,0 will boot from [SYS1]

Always be careful to NOT boot any of the other systems with VAXCLUSTER=0, if another system is already running from that disk.

Volker.

Re: Boot

marsh_1 — Thu, 12 Feb 2009 13:17:58 GMT

hi,

clusters are a bit of large topic, see chapter 5 in the vms cluster manual here :-

http://h71000.www7.hp.com/doc/731final/documentation/pdf/ovms_731_cluster_systems.pdf

but a good read of it generally will be useful to you as well as the guidelines for clusters here :-

http://h71000.www7.hp.com/doc/82final/6318/aa-q28lh-tk.pdf

HTH

Re: Boot

Mulder_1 — Thu, 12 Feb 2009 13:33:28 GMT

Hi volker,

Let me give you the entire picture....

The SAN disk is not empty,I need to upgrade the OS to 7.3-2 from 7.3-1 which is having multiple roots and are shared by 4 systems in a cluster.

My question is : How do I upgrade..?

Thanks

Re: Boot

Volker Halle — Thu, 12 Feb 2009 13:38:25 GMT

Mulder,

you cannot upgrade that disk, while other systems are actively running from it.

If you cannot shut down all the system at the same time, you need to perform a 'rolling update':

Make a BACKUP/IMAGE copy of the disk to an empty disk, then upgrade that disk to V7.3-2 (plus patches !) and then boot the other systems from that updated disk.

Easier said than done...

If you have no experience with this kind of operation, consider to get professional help.

Volker.

Re: Boot

Mulder_1 — Thu, 12 Feb 2009 13:56:24 GMT

Thats fine Volker....all systems can be shutdown ...but I need to know how do I upgrade the OS for all servers as while upgrading the OS it queries for disk name but not the root path...as all systems are using 1 system disk.

Thanks

Re: Boot

Joseph Huber_1 — Thu, 12 Feb 2009 14:03:05 GMT

Mulder, the upgrade affects all nodes booting from this disk, therefore it doesn't ask for a specific root.
If there is something to do for the node-specific parts, the upgrade procedure will look into all system roots.

Re: Boot

Volker Halle — Thu, 12 Feb 2009 14:03:36 GMT

Mulder,

an OpenVMS cluster system disk contains only ONE copy of the operating system. The data in the specific roots is just NODE-specific data.

After you've shutdown all your nodes booting from that disk, just boot ONE node (maybe the one which boots from [SYS0]) from the CD and upgrade the system disk. Once you're done, boot that node from the updated disk and also boot all other nodes from that disk. They will run an @AUTOGEN during the first boot and reboot automatically. After that you're done with your cluster upgrade to V7.3-2. Don't forget to install the current patches.

Volker.

Re: Boot

Robert Gezelter — Thu, 12 Feb 2009 14:24:53 GMT

Mulder,

While it is common to update a system volume in-place, it is not the best approach.

As Volker said, far better to create a copy of the system disk, update the copy, and then re-boot each node in turn so that they are operating off of the new version of the system.

OpenVMS has an excellent record for few problems with updates. However, "few" is not the same as "none". On a production system, backups, particularly with the current costs of disks, are far cheaper than the alternatives.

Basically, the best approach is to create two system disk images, ALFA and BRAVO, and see-saw between them as the cluster is upgraded. When the new version is considered sufficiently stable that a retreat is not necessary, reverse the process and have two sets of the current system image.

- Bob Gezelter, http://www.rlgsc.com

Re: Boot

Mulder_1 — Thu, 12 Feb 2009 14:33:54 GMT

Volker ..You mean to say that just by updating the system disk should be enough to take care of the other nodes..?

But,I can find the following :

Directory SYS001:[000000]

SYS1.DIR;1 SYS10.DIR;1 SYS11.DIR;1 SYS12.DIR;1
SYS2.DIR;1 SYS3.DIR;1 SYS4.DIR;1 SYS8.DIR;1
SYS9.DIR;1 SYSLOST.DIR;1 SYS_BATCH.DIR;1

Total of 11 files.

There is no sys0..so if I upgrade the disk it should create sys0 by default which is (I suppose) is going to be a new installation.

Thanks

Re: Boot

Volker Halle — Thu, 12 Feb 2009 14:38:15 GMT

Mulder,

if there is no [SYS0], someone must have removed it. Just use ONE of your systems to upgrade that disk.

All the OpenVMS operating system files are present in the [VMS$COMMON...] directory tree and they will be updated. Files in the specific roots are node-specific files and do not need to be updated.

The upgrade will check for OpenVMS system files in a specific root, which should NOT be there and warn you appropriately.

Volker.

Re: Boot

Joseph Huber_1 — Thu, 12 Feb 2009 14:41:23 GMT

Look into all of the [sys*] roots. You will see a syscommon.dir in all of them, these are alias for the common [vms$system].

There is nothing specific to [sys0], it is just another nodes root, and need not be there, and will not be created by an upgrade.

Re: Boot

Mulder_1 — Thu, 12 Feb 2009 14:47:38 GMT

Make sense....

i'm keeping the thread open ....will let you know the findings..

Thanks

Re: Boot

Richard Brodie_1 — Thu, 12 Feb 2009 15:42:44 GMT

It's not uncommon to omit [SYS0] in a shared disk cluster. It just makes it a little less likely that you boot a system off the wrong root when you have the 'default' root missing.