There are two types of cluster upgrades: concurrent and rolling.
The type of upgrade you use depends on whether you want to maintain
the availability of the cluster during the upgrade and whether you
have more than one system disk. Review this chapter and then perform
the preliminary tasks for the upgrade procedure (concurrent or rolling)
that best suits your configuration.
Concurrent Upgrade This section describes the following:
How a concurrent upgrade works
Preparing your system for a concurrent upgrade
How a Concurrent
Upgrade Works During a concurrent upgrade, you must shut down the entire
cluster and upgrade each system disk. No one can use the cluster
until you upgrade each system disk and reboot each computer. When
the cluster reboots, each computer will be running the upgraded
version of the OpenVMS operating system.
If all systems in the OpenVMS Cluster environment are booted
from one system disk, you must perform a concurrent upgrade.
Preparing Your System
for a Concurrent Upgrade To prepare for a concurrent upgrade:
Log in locally
to the SYSTEM account. If you have more than one system disk, make sure that you
have performed the preupgrade tasks on each system disk that you
will be upgrading. Then go to
Upgrading the OpenVMS Alpha Operating System and perform an upgrade on each system disk. You
do not have to reboot the operating system CD or DVD for each upgrade.
You only need to choose option 1 from the menu for each upgrade.
Shut down all systems by entering the following
command on each system (satellites first, then the boot nodes):
$ @SYS$SYSTEM:SHUTDOWN
When the procedure asks whether an automatic system
reboot should be performed, enter N (NO) and press Return.
Choose the CLUSTER_SHUTDOWN option.
When the shutdown procedure is finished on all nodes,
halt each system by entering Ctrl/P or by pressing the Halt button.
For more information about halting your Alpha computer, see
Halt, Boot, and Shutdown Procedures for OpenVMS Alpha Systems.
If you have only one system disk for your cluster,
go to
Upgrading the OpenVMS Alpha Operating System to
begin the upgrade procedure. After the upgrade is complete, you are instructed to reboot
each computer in the OpenVMS Cluster environment before beginning
other postupgrade procedures.
Rolling Upgrade This section describes the following:
How a rolling upgrade works
Notes and restrictions
Preparing your system for a rolling upgrade
How a Rolling Upgrade
Works During a rolling upgrade, you upgrade each system disk individually,
allowing old and new versions of the operating system to run together
in the same cluster, creating a mixed-version cluster.
Because rolling upgrades allow mixed-version clusters, the systems
that you are not upgrading remain available. During a rolling upgrade,
you keep some of the computers in the cluster running while you
upgrade others (you must have more than one system disk).
Notes and Restrictions The following restrictions apply to rolling upgrades. Refer
to the HP OpenVMS Version 8.2 Release Notes for additional compatibility
issues and restrictions.
Rolling upgrades are supported from Version 7.3-1
and 7.3-2 of the OpenVMS Alpha operating system. Rolling upgrades
in mixed-architecture OpenVMS Cluster environments are supported
with VAX computers running Versions 7.3 of the OpenVMS VAX operating
system (see
Mixed-Version Support in an OpenVMS Cluster Environment).
The system being upgraded does not attempt to access
any disk that is being accessed by one or more of the remaining
OpenVMS Cluster systems.
The remaining OpenVMS Cluster systems do not attempt
to access the target disk of the system being upgraded. If the target disk being upgraded is locally attached to the
system performing the upgrade, then it is not accessible to the
remaining OpenVMS Cluster systems. (The OpenVMS system booted from
the operating system CD or DVD does not MSCP serve local disks.)
Whenever possible, HP recommends that you perform the upgrade on
a local disk or that you perform a concurrent upgrade. During the upgrade, be sure that the target disk you select,
as well as any disk you access from the DCL menu option, is either
a local disk or one that is not being accessed by any of the remaining
OpenVMS Cluster members.
Any attempt to access the target disk from the remaining
OpenVMS Cluster members will corrupt the target disk in most cases.
Even if the target disk is only mounted by a remaining cluster member,
and no file access is done, the target disk will probably be corrupted.
If a disk is corrupted in this way, the only supported recovery
is to restore the backup copy of the corrupted disk.
HP recommends that all Alpha computers in a cluster
run the same (and preferably the latest) version of the OpenVMS
Alpha operating system.
You cannot perform a rolling upgrade if all systems
boot from a single system disk. Perform a concurrent upgrade instead.
The upgrade procedure affects the queuing system
as follows:
The queuing system is not active on
the system you are upgrading; do not attempt to execute a START/QUEUE/
MANAGER command.
You cannot create a queue database on the operating
system CD or DVD (because it is not writable).
The queue manager process on other nodes in the
cluster can continue to run during the upgrade if the queue database
is not on the disk being upgraded.
Preparing Your System
for a Rolling Upgrade To prepare for a rolling upgrade:
Log in to any
node where the target disk is mounted as a data disk,
rather than as the system disk. (That disk
must be the one on which you already performed the preupgrade tasks
described in
Before Upgrading the OpenVMS Alpha Operating System.)
Check
the votes and make adjustments to maintain the proper quorum so
the cluster can continue to operate throughout the upgrade. (HP OpenVMS Cluster Systems describes
this procedure in detail.)
Use the DCL command DISMOUNT/CLUSTER to dismount
the data disk. (You can also perform this operation using the SYSMAN
utility.) Note that you can ignore messages from nodes where the specified
data disk is being used as the system disk.
Verify that the data disk has been dismounted successfully
by entering the following commands:
$ MCR SYSMANSYSMAN> SET ENVIRONMENT/CLUSTERSYSMAN> DO SHOW DEVICE disk-name
Examine the display to be sure the disk is not mounted on
any nodes as a data disk. Noting the value listed in the Trans Count
field can help you make that determination: A value of less than
50 indicates that the disk is mounted as a data disk rather than
as the system disk; a much larger value (for example, 300) indicates
that the disk most likely is the system disk.
If the disk is still mounted on any nodes as a data
disk, use the SYSMAN utility to dismount the disk; otherwise, exit the
SYSMAN utility.
Use the following command to shut down any nodes
that boot from the system disk you are upgrading (shut down satellite
nodes first):
$ @SYS$SYSTEM:SHUTDOWN
When the procedure asks
whether an automatic system reboot should be performed, enter N
(NO) and press Return.
Choose the REMOVE_NODE option.
If a proper quorum is not maintained at any time during the
upgrade procedure, the shutdown procedure will hang the cluster.
If the cluster hangs during a shutdown, enter the following commands
on the system console of a system that is still a cluster member. These
commands are only for OpenVMS Alpha (or VAX) systems; they cannot
be performed at the console of an OpenVMS I64 system.
During the upgrade it is very important that the
system disk being upgraded is accessed only by
the node on which the upgrade is being performed. If the disk can
be accessed from other nodes in the cluster, for example, through
an HSC or HSJ device, you must ensure that
this does not happen. Even if the disk is only mounted and no file
access is performed, the disk can still become corrupted.
Ensure that any users who might mount disks know that they
must not access the system disk being upgraded. Also make sure that
any procedures that might mount the disk do not run during the upgrade.
If you have automatic procedures that periodically check and remount disks,
it might be wise to disable them during the upgrade.
HP OpenVMS Version 8.2 Upgrade and Installation... 
Preparing to Upgrade in an OpenVMS Cluster Environment
