Chapter 5 Preparing to Upgrade in an OpenVMS Cluster Environment

5.1 Preupgrade Tasks for OpenVMS Cluster Environments

	NOTE: Be sure you have performed the preupgrade tasks described in Chapter 4 before you upgrade your OpenVMS Cluster system.

Use the checklist in Table 5-1 to ensure that you perform all necessary tasks prior to upgrading your system in an OpenVMS Cluster environment.

5.2 Review OpenVMS Cluster Information

When you upgrade the operating system in an OpenVMS Cluster environment, be sure you review any relevant OpenVMS Cluster information contained in the following documents.

OpenVMS Version 8.3-1H1 Documents

OpenVMS Version 8.3 Documents

Information in the following documents remains valid except where superseded by the OpenVMS documents listed previously.

Earlier OpenVMS Documents

Information in the following documents remains valid except where superseded by the OpenVMS documents listed previously.

5.3 Mixed-Version Support in an OpenVMS Cluster Environment

HP provides two levels of support for mixed-version and mixed-architecture OpenVMS Cluster systems: warranted support and migration support.

Warranted support means that HP has fully qualified two specified versions coexisting in an OpenVMS Cluster and will address all problems identified by customers using these configurations.

Migration support means that HP has qualified the versions for use together in configurations that are migrating in a staged fashion to a newer version of OpenVMS. Problem reports submitted against these configurations will be answered by HP. However, in exceptional cases, HP may request that you move to a warranted configuration as part of the solution. Migration support helps customers move to warranted OpenVMS Cluster pairs.

Warranted cluster support is provided for the combinations shown in Table 5-2.

	NOTE: Only two architectures are supported in the same OpenVMS Cluster: OpenVMS I64 and OpenVMS Alpha, or OpenVMS Alpha and OpenVMS VAX, but not OpenVMS I64 and OpenVMS VAX. System disks are architecture specific and can be shared only by systems of the same architecture. An Alpha and I64 system, or an Alpha and VAX system, cannot boot from the same system disk. However, cross-architecture satellite booting is supported between an Alpha and VAX system. When you configure an OpenVMS Cluster to take advantage of cross-architecture booting, make sure that at least one system from each architecture is configured with a disk that can be used for installations and upgrades. For more information, see the Guidelines for OpenVMS Cluster Configurations and HP OpenVMS Cluster Systems manuals.

Table 5-3 shows the supported migration pairings.

For information about valid upgrade paths, see Section 4.3.1.

For more information, see the OpenVMS Technical Software Support Service website at:

http://www.hp.com/go/openvms/support

In addition, see the following website for the OpenVMS Operating System Support Chart at:

http://www.hp.com/go/openvms/supportchart

Before introducing an OpenVMS Version 8.3-1H1 system into an existing OpenVMS Cluster, you might need to install certain patch kits (also known as remedial kits) on cluster members running earlier versions of OpenVMS. In a mixed-architecture cluster, you need to install an LMF patch on any OpenVMS Version 7.3-2 Alpha members. For a complete list of required patch kits, see the HP OpenVMS Version 8.3-1H1 for Integrity Servers New Features and Release Notes and the HP OpenVMS Version 8.3 Release Notes.

For information about supporting the Performance Data Collector base software (TDC_RT) in OpenVMS Clusters, see Section 7.8.10.5.

5.4 Adding a New System to an OpenVMS Cluster

To add a new OpenVMS Version 8.3-1H1 I64 system to an existing OpenVMS Cluster configuration, all existing Alpha nodes in the cluster must be running OpenVMS Alpha Version 8.3, and all existing OpenVMS I64 nodes must be running OpenVMS I64 Version 8.3 or later. Any node in the cluster that is running an older version of OpenVMS must be upgraded appropriately before you can add a Version 8.3-1H1 node.

Alternatively, any I64 node that needs to be upgraded can be removed temporarily from the cluster and added back after it has been upgraded. This allows you to form a supported cluster immediately, adding nodes back into the cluster as they are upgraded. Note that, depending on the number of nodes being added, you might need to adjust the EXPECTED_VOTES system parameter to reflect the number of voting nodes and any quorum disk votes (if a quorum disk is being used). In addition, for any node being removed from the cluster, you should specify the REMOVE_NODE option during system shutdown so that the quorum for the remaining nodes is correctly adjusted.

5.5 Types of Upgrades

Two types of cluster upgrades are available: a concurrent upgrade and a rolling upgrade. 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 suit your configuration.

5.5.1 Concurrent Upgrade

This section describes the following:

• How a concurrent upgrade works

• Preparing your system for a concurrent upgrade

5.5.1.1 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 run 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.

5.5.1.2 Preparing Your System for a Concurrent Upgrade

To prepare for a concurrent upgrade, follow these steps:

1. 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 are upgrading. Make sure the target system disk is not mounted on any other node in the cluster and remains dismounted during the upgrade. It should be mounted only on the system that is performing the upgrade. (For information about dismounting disks, see Section 5.5.2.3.) Then go to Chapter 6 and perform an upgrade on each system disk. You do not have to reboot the operating system media for each upgrade. You only need to choose option 1 on the menu for each upgrade.

2. Shut down all systems by entering the following command on each system (satellite nodes first, then the boot nodes):

   $ @SYS$SYSTEM:SHUTDOWN

3. When the procedure asks whether an automatic system reboot should be performed, enter N (NO).

4. Choose the CLUSTER_SHUTDOWN option.

5. When the shutdown procedure is finished on all nodes, halt each system by either pressing Ctrl/P or Halt. For more information about halting your Integrity server, see Section A.7.1.

6. If you have only one system disk for your cluster, go to Chapter 6 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.

5.5.2 Rolling Upgrade

This section describes the following:

• How a rolling upgrade works

• Notes and restrictions

• Preparing your system for a rolling upgrade

5.5.2.1 How a Rolling Upgrade Works

A rolling upgrade allows you to have a mixed-version cluster. During a rolling upgrade, you keep some of the computers in the cluster running and available while you upgrade others (you must have more than one system disk). You upgrade each system disk individually, allowing old and new versions of the operating system to run together in the same cluster.

5.5.2.2 Notes and Restrictions

The following restrictions apply to rolling upgrades. For additional compatibility issues and restrictions information, see the HP OpenVMS Version 8.3-1H1 for Integrity Servers New Features and Release Notes and the HP OpenVMS Version 8.3 Release Notes.

• 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 media does not MSCP serve local disks.) HP recommends that, whenever possible, 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. Make sure the target system disk is not mounted on any other node in the cluster and remains dismounted during the upgrade. It should be mounted only on the system that is performing the upgrade. (For information about dismounting disks, see Section 5.5.2.3.)

  	NOTE: Any attempt to access the target system disk from the remaining OpenVMS Cluster members will corrupt the target disk. Even if the target system disk is mounted only by a remaining cluster member and no file access is performed, 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 (preferably the latest) version of the OpenVMS Alpha operating system, and that all Integrity servers run the same version of the OpenVMS I64 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/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.

5.5.2.3 Preparing Your System for a Rolling Upgrade

To prepare for a rolling upgrade, follow these steps:

1. 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 Chapter 4.)

2. 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.)

3. 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.

4. Verify that the data disk has been dismounted successfully by entering the following commands:

   $ MCR SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> 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.

5. 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.

6. 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

   1. When the procedure asks whether an automatic system reboot should be performed, enter N (NO).

   2. Choose the REMOVE_NODE option.

If a proper quorum is not maintained at any time during the upgrade procedure, the shutdown procedure hangs the cluster. If the cluster hangs during a shutdown, you can use the Interrupt Priority C (IPC) facility to adjust quorum from the system console of a system that is still a cluster member.

From an OpenVMS Alpha cluster member, press Ctrl/P. The IPC facility displays help information about IPC commands. Enter the commands at the console:

$ Ctrl/P >>> D SIRR C >>> C Interrupt Priority C Commands: C device Cancel Mount Verification Q Adjust Quorum CTRL-Z Exit IPC CTRL-P Prompt for Crash IPC> Q IPC> Ctrl/Z

From an OpenVMS I64 cluster member, pressing Ctrl/P puts the system directly into the IPC facility, which displays help information about IPC commands. To adjust quorum, enter the commands shown in the following example. Note that if systems are booted with XDELTA, pressing Ctrl/P brings the OpenVMS I64 system into XDELTA. The IPC facility is not available in this case.

$ Ctrl/P Interrupt Priority C Commands: C device Cancel Mount Verification Q Adjust Quorum CTRL-Z Exit IPC CTRL-P Prompt for Crash IPC> Q IPC> Ctrl/Z

You can also adjust quorum using Availability Manager or DECamds. The method is equivalent to that used by IPC except you do not have to use the console (this assumes the Data Analyzer is running on a system outside the OpenVMS Cluster, which is recommended). For more information, see the “Adjust Quorum” section in the Availability Manager User’s Guide or the DECamds User’s Guide. The Availability Manager User’s Guide is available at:

http://www.hp.com/products/openvms/availabilitymanager

After the shutdown procedure is finished on all nodes, go to Chapter 6 to begin the upgrade procedure.

	CAUTION: 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 would be wise to disable them during the upgrade.