 |
Index for
Section 8 |
|
 |
Alphabetical
listing for C |
|
 |
Bottom of
page |
|
clu_upgrade(8)
NAME
clu_upgrade - Perform a cluster rolling upgrade, display the status of a
rolling upgrade
SYNOPSIS
/usr/sbin/clu_upgrade
Stages (in order):
clu_upgrade [-qv] setup lead_memberid [prod_code [prod_code ...]]
clu_upgrade [-qv] preinstall
clu_upgrade [-qv] install
clu_upgrade [-qv] postinstall
clu_upgrade [-fqv] roll
clu_upgrade [-fqv] switch
clu_upgrade [-qv] clean
Undo a stage:
clu_upgrade [-qv] undo stage
clu_upgrade [-qv] undo roll memberid
Status and check options:
clu_upgrade [-qv] status
clu_upgrade [-qv] check [stage]
clu_upgrade [-qv] check roll [memberid]
clu_upgrade [-qv] started [stage]
clu_upgrade [-qv] completed [stage]
Manually check, add, remove, enable, or disable tagged files:
clu_upgrade [-qv] tagged [check] [prod_code [prod_code ...]]
clu_upgrade [-qv] tagged {add | remove} prod_code [prod_code ...]
clu_upgrade [-qv] tagged {enable | disable} memberid [memberid ...]
Miscellaneous:
clu_upgrade help
clu_upgrade log
clu_upgrade version
OPTIONS
Stages:
A rolling upgrade consists of a series of ordered stages. A stage's name is
used either as a direct option to clu_upgrade in order to start the stage,
or as an argument to a clu_upgrade check command in order to determine
whether the cluster is ready to proceed to the specified stage.
The following list provides a synopsis of each stage, in execution order:
setup lead_memberid [prod_code [prod_code ...]]
The setup stage can be run on any cluster member.
The setup stage tests whether the cluster is ready to begin a
rolling upgrade. If so, setup prompts to determine whether you
plan to perform one or more of an update installation, a patch,
or a New Hardware Delivery (NHD) installation (clu_upgrade knows
which combinations of tasks are supported for each release, and
in what order).
If performing a rolling upgrade that includes an update
installation, setup copies the new cluster kit to
/var/adm/update/TruClusterKit (so it is available to the
installupdate command in the install stage), and extracts and
installs the new version of clu_upgrade. This ensures that the
remainder of the rolling upgrade uses the latest available
version of the clu_upgrade command.
If performing a rolling upgrade that includes an NHD
installation, setup copies the NHD kit to /var/adm/update/NHDKit.
The setup stage also checks disk space, creates the mandatory set
of tagged files (copies of existing files with .Old.. prepended
to the file name), and prepares the member specified by
lead_memberid for the preinstall stage. This member, known as the
lead member, will be the first member of the cluster to roll.
If you specify one or more optional three-letter product codes,
setup creates tagged files for those layered products. By
default, tagged files are created during the setup stage only for
products with the following three-letter codes: OSF, TCR, and
IOS. For more information on tagged files, see the tagged
option.
When the setup command completes, all cluster members except the
lead member must be rebooted, one at a time. This reboot is
required for each member that will use tagged files in the
mixed-version cluster. When the reboots complete, all members
except the lead member are using tagged files.
preinstall
The preinstall command must be run on the lead member.
The preinstall command verifies that the cluster is ready for
installation. This means that the lead member is up and not
running on tagged files, and all other members are either down or
running on tagged files. The preinstall command also backs up
member-specific files for the lead member.
install The install command must be run on the lead member.
If performing an update installation, the lead member must be in
single-user mode. If performing a patch or an NHD installation,
the lead member can be in multi-user mode or single-user mode.
Note
To take a cluster member to single-user mode, you must
halt the member and then boot it to single-user mode.
In single-user mode, run init s, bcheckrc, and lmf
reset before updating software.
The install command verifies that this member is the lead member,
and then prompts you to run the appropriate commands:
installupdate, dupatch, or nhd_install. (Refer to the relevant
update installation, patch, or NHD documentation as needed.)
If an NHD installation is part of a rolling upgrade that includes
an update installation of the base operating system, you do not
have to manually run nhd_install; the installupdate command will
install the NHD kit. Otherwise, use the nhd_install command
copied by clu_upgrade during the setup stage:
/var/adm/update/NHDKit/nhd_install.
When the lead member reboots on the updated software, it is the
first member of the cluster to complete its roll.
postinstall
The postinstall command command must be run on the lead member.
The postinstall command verifies that the update installation,
patch procedure, or NHD installation completed successfully. The
cluster now consists of one rolled member, with any remaining
members ready to roll. (In a single-member cluster, postinstall
marks the roll stage as completed for the cluster.)
[-force|-f ] roll
The roll command must be run on the member to be rolled.
The member must be in single-user mode.
Note
To take a cluster member to single-user mode, you must
halt the member and then boot it to single-user mode.
In single-user mode, run init s, bcheckrc, and lmf
reset before running clu_upgrade roll.
In many cluster configurations, you can roll multiple members in
parallel and shorten the time required to upgrade the cluster.
The roll command verifies that the postinstall stage is complete
and that an update installation, patch, or NHD installation has
been performed. It also verifies that rolling the member will not
result in a loss of quorum. If these conditions are met, roll
backs up the member's member-specific files and sets up the it(8)
scripts that will run on reboot to perform the actual roll. It
then prompts for permission to reboot the member.
When the -f (force) option is applied to the roll stage, the
reboot occurs automatically--no reboot prompt is displayed. Use
this option if you are performing parallel rolls.
During the roll-stage reboot, the it scripts roll the member,
build a customized kernel, and reboot with the customized kernel.
[-force|-f ] switch
The switch command can be run on any cluster member. All members
must be up and running in multiuser mode.
The switch command verifies that all members are running the same
versions of the base operating system and cluster software, and
that no members are using the tagged files. If all tests succeed,
switch throws a software switch that turns on any new features
that could not be used until all members were upgraded.
When the -f (force) option is applied to the switch stage, it
overrides the requirement that all members be up and running in
multiuser mode. Even though members can be down, the boot disks
for all members must be accessible in order for the clu_upgrade
-f switch command to succeed.
When the switch command completes, all cluster members must be
rebooted, one at a time.
At this point, the cluster is functionally upgraded.
clean The clean command can be run on any cluster member.
The clean command verifies that the switch stage has completed.
If so, clean deletes all tagged .Old.. files, deletes any on-disk
member-specific backup archives created during the upgrade,
removes status and lock files, and recursively deletes, if
present, the following directories:
/var/adm/update/TruClusterKit, /var/adm/update/OSKit, and
/var/adm/update/NHDKit. In addition, if an update installation
was performed, the clean command gives you the option of running
the Update Administration Utility (updadmin) to manage the files
that were saved during the update installation. Finally, the
clean command creates an archive directory for this upgrade,
/cluster/admin/clu_upgrade/history/base_OS_version, and moves the
clu_upgrade.log file to the archive directory.
Undo a stage:
{undo | -undo | -u} stage
The undo command attempts to undo the specified passed stage.
You can undo any stage except the switch stage and the clean
stage.
An undo of the install stage is performed from any member other
than the lead member. Before attempting to undo the install
stage, the lead member must be halted.
You must undo stages in the reverse order in which they were
performed. For example, if you decide to undo a rolling upgrade
after completing the preinstall stage, you undo the preinstall
stage and then undo the setup
{undo | -undo | -u} roll memberid
The undo roll command attempts to undo the roll stage for the
specified member. The member whose roll stage is being undone
must be halted.
Status and check options:
{status | -status | -s}
Prints the status of the upgrade.
{check | -check | -c} [stage]
Determines whether the status of the current upgrade is such that
the specified stage can be run. If no stage is specified, the
next stage is checked.
{check | -check | -c} roll memberid
Determines whether the specified member has rolled.
{started | -started} stage
Determines whether the specified stage has started.
{completed | -completed} stage
Determines whether the specified stage has completed.
Manually check, add, delete, enable, or disable tagged files:
{tagged | -tagged | -t} [check] [prod_code [prod_code ...]]
The tagged [check] command verifies that the correct set of
tagged files has been created. If one or more three-letter
product codes are specified, clu_upgrade verifies only the tagged
files associated with those products. If no product codes are
specified (clu_upgrade tagged or clu_upgrade tagged check),
clu_upgrade verifies all tagged files in the cluster. When
possible, the command corrects any irregularities it finds.
{tagged | -tagged | -t} {add | remove} prod_code [prod_code ...]
The tagged {add | delete} commands are provided in the unlikely
event that an administrator needs to create or delete tagged
files for a layered product in order to complete a roll.
The first three letters of a subset's name are the product code;
for example, cluster subset names begin with TCR. By default,
tagged files are created during the setup stage only for products
with the following three-letter codes: OSF, TCR, and IOS.
Do not create tagged files for any other layered product unless
you know that the product's vendor supports tagged files during a
roll.
{tagged | -tagged | -t} {enable | disable} memberid [memberid ...]
The tagged {enable | disable} commands let an administrator
manually control whether the member(s) specified by memberid run
with or without tagged files. You cannot specify the lead
member's memberid as an argument to enable or disable. The lead
member never runs with tagged files.
You might have to reboot a member after issuing an enable or
disable command. If so, the command will display a message
telling you which member(s) to reboot.
During normal operation, you should not need to use either the
enable or disable command; clu_upgrade controls when a member
uses tagged files.
However, should you ever need to undo the setup stage, disable is
useful as an alternative to halting all but the lead member. You
can, one at a time, disable tagged files on each member that is
currently running with tagged files. When no members are running
on tagged files, you can then undo the setup stage on the lead
member.
The enable command is provided in case you make a mistake with
the disable command.
Miscellaneous:
help|-help|-h
Displays command syntax.
log|-log|-l
Logs a message to /cluster/admin/clu_upgrade.log. Type in a
message, which can contain multiple lines. When finished, press
<Ctrl-d>. The clu_upgrade command writes the message to the
logfile, printing the host name and date both before and after
the message.
quiet|-quiet|-q
Quiet mode.
verbose|-verbose|-v
Verbose output. The clu_upgrade command prints additional
information to stdout.
version|-version|-V
Print the current version of clu_upgrade.
DESCRIPTION
The clu_upgrade utility performs the administrative tasks associated with a
rolling upgrade.
You must be root to run the clu_upgrade command.
A rolling upgrade is a software upgrade of a cluster that is performed
while the cluster is in operation. After the lead member has been rolled,
one or more members at a time are rolled and returned to operation while
the cluster transparently maintains a mixed-version environment for the
base operating system, cluster, and Worldwide Language Support (WSL)
software. Clients accessing services are not aware that a rolling upgrade
is in progress.
Rolling in a patch or an NHD kit uses the same procedure as rolling in a
new release of the base operating system and cluster software. The only
difference is whether you run one or more of installupdate, dupatch, or
nhd_install during the install stage.
A cluster can continue to operate during a rolling upgrade because there
are two copies of the operating system and cluster software files. (There
is only one copy of shared configuration files so that changes made by any
member are visible to all members.) This approach makes it possible to run
two different versions of the base operating system and the cluster
software at the same time in the same cluster. The trade-off is that,
before you start an upgrade, you must make sure that there is adequate free
space in each of the clusterwide root (/), /usr, /var, and, if there is a
separate domain for the Worldwide Language Support (WLS) subsets, i18n file
systems.
A rolling upgrade has the following disk space requirements:
· At least 50 percent free space in root (/).
· At least 50 percent free space in /usr.
· At least 50 percent free space in /var, plus, for a rolling upgrade,
an additional 425 MB to hold the subsets for the new version of the
base operating system.
· If there is a separate i18n domain, at least 50 percent free space in
that file system.
· No tagged files are placed on member boot partitions. However,
programs might need free space when moving kernels to boot partitions.
It is a good idea to have at least 50 MB free space on each member's
boot partition.
· If installing a patch kit, see the Patch Summary and Release Notes
that came with your patch kit to find the amount of space you will
need to install that kit. If installing an NHD kit, see the NHD
Release Notes and Installation Instructions for any disk space
information.
You can use the clu_upgrade -v check setup lead_memberid command to
determine whether the cluster has enough free disk space and is ready to
start the setup stage. If a file system needs more free space, use AdvFS
utilities such as addvol to add volumes to domains as needed.
Before starting a rolling upgrade, back up the cluster and select one
member to be the first member to roll (the lead member). This member must
have direct access to the root (/), /usr, and /var file systems. The
installupdate or dupatch command is run on this member during the install
stage. If you plan to run the installupdate command during the install
stage, remove any blocking layered products before starting the rolling
upgrade (see the list of blocking products in the TruCluster Server Cluster
Installation manual).
To perform a rolling upgrade, the following clu_upgrade commands are
entered in order:
1. Command:clu_upgrade [-qv] setup lead_memberid [prod_code [prod_code
...]]
On member: Any
Run level: multiuser mode
Where lead_memberid is the member ID of the cluster member where the
installupdate, dupatch, or nhd_install commands will be run. This
member, known as the lead member, is the first member of the cluster
to roll.
Before running the setup stage, clu_upgrade verifies that no rolling
upgrade is in progress and that all cluster members are running the
same versions of the base and cluster software.
When setup completes, reboot all members of the cluster (one at a
time) except the lead member. After the reboot, all members except the
lead member will be using tagged files.
2. Command: clu_upgrade preinstall
On member: The lead member
Run level: multiuser mode
Prepares the cluster for the running of installupdate, dupatch, or
nhd_install.
3. Optional Command: clu_upgrade install
Actual Command: {/sbin/installupdate | /usr/sbin/dupatch |
/var/adm/update/NHDKit/nhd_install}
On member: The lead member
Run level: single-user mode for installupdate
Run level: single-user mode (recommended) or multi-user mode for
dupatch
Run level: single-user mode or multi-user mode for nhd_install
The optional install command displays a message telling the user to
run installupdate, dupatch, or nhd_install.
If performing a rolling upgrade that includes an update installation,
installupdate copies the base operating kit to the
/var/adm/upgrade/OSKit directory.
For information about using the installupdate command, see the Tru64
UNIX Installation Guide. For information about using the dupatch
command, see the Patch Kit Installation Instructions provided with the
patch kit. For information about using nhd_install, see the NHD
Release Notes and Installation Instructions.
Note
When installing an NHD kit during a rolling upgrade, either
installupdate will install the kit (if the rolling upgrade
includes both an update installation and an NHD
installation), or you manually run the
/var/adm/update/NHDKit/nhd_install command.
4. Command: clu_upgrade postinstall
On member: The lead member
Run level: multiuser-mode
Verifies that the lead member has completed an update installation, a
patch, or an NHD installation. If an update installation was
performed, clu_upgrade postinstall verifies that the lead member has
rolled to the new version of the base operating system.
5. Command: clu_upgrade roll
On member: The member to be rolled
Run level: single-user mode
If the cluster has more then one member, the roll command is run on
each remaining member. (Because the lead member is already using the
new software, you do not roll that member with the clu_upgrade roll
command.)
To shorten the time required to upgrade a cluster, you can roll
multiple members in parallel. The number of members rolled
simultaneously is limited only by the requirement that the members not
being rolled (Member state = UP) have sufficient votes to maintain
quorum.
In the case of parallel rolls, when you initiate the roll of a member,
clu_upgrade checks whether the loss of the member's vote in addition
to all the votes of other currently rolling members would result in
the cluster losing quorum. If a loss of quorum would result, then the
roll of the member does not occur and an error message is displayed.
You can roll the member later, after one of the currently rolling
members has rejoined the cluster and its quorum vote is available.
If clu_upgrade determines that it is all right to roll the current
member, it checks whether another member can be rolled without loss of
quorum. If initiating another roll would cause a quorum loss, a
message to that effect is displayed. Otherwise, clu_upgrade displays a
message indicating that you can begin another roll.
When you perform parallel rolls, use the -f (force) option with the
clu_upgrade roll command. This causes the member being rolled
automatically to reboot when the roll stage completes. This saves you
from having to respond to a prompt from clu_upgrade to reboot the
member.
Before running clu_upgrade roll on a member, halt the member and boot
it to single-user mode. In single-user mode, run init s, bcheckrc, and
lmf reset before running clu_upgrade roll.
6. Command: clu_upgrade switch
On member: Any
Run level: multiuser mode
All members must be up and running in multiuser mode before you issue
the clu_upgrade switch command.
After all members have rolled, the switch command turns on any new
features that had been disabled during the upgrade.
Use the -f (force) option to override the requirement that all
members be up and running in multiuser mode. Although members can be
down, the boot disks for all members must be accessible.
When the clu_upgrade switch command completes, reboot all members, one
at a time.
7. Command: clu_upgrade clean
On member: Any
Run level: multiuser mode
Deletes files that are no longer needed.
At each stage, the clu_upgrade command provides the information needed to
prepare for the next stage.
With no arguments, clu_upgrade prints the status of the current rolling
upgrade. The started and completed flags let a user or program determine
whether a specific stage has started or completed.
To determine whether the cluster is ready to perform a stage without
actually performing the stage, use the check flag with the name of the
stage. The clu_upgrade command returns a 0 exit status if the member is
ready to perform the specified stage, and -1 otherwise.
To undo a stage, use the undo option with the stage you want to undo. The
clu_upgrade command will verify that the specified stage is a valid stage
to undo.
Note
Before undoing any stage, we recommend that you read the relevant
version of the TruCluster Server Release Notes to determine
whether there are restrictions related to the undoing of any
stage.
The following list outlines the requirements for undoing a stage:
· To undo the setup stage:
Command: clu_upgrade undo setup
On member: The lead member
Run Level: multiuser mode
You must run this command on the lead member. In addition, no members
can be running on tagged files when you undo the setup stage.
Before undoing the setup stage, use the clu_upgrade -v status command
to determine which members are running on tagged files. Then use the
clu_upgrade tagged disable memberid command to disable tagged files on
any member currently running with tagged files.
When no members are running on tagged files, run the clu_upgrade undo
setup command on the lead member.
· To undo the preinstall stage:
Command: clu_upgrade undo preinstall
On member: The lead member
Run Level: multiuser mode
· To undo the install stage:
Command: clu_upgrade undo install
On member: Any member except the lead member
Run Level: multiuser mode
Halt the lead member. Then run the clu_upgrade undo install command on
any other member that has access to the halted lead member's boot
disk. When the command completes, boot the lead member.
· To undo the postinstall stage:
Command: clu_upgrade undo postinstall
On member: The lead member
Run Level: multiuser mode
· To undo the roll stage for a member:
Command: clu_upgrade undo roll memberid
On member: Any member except the member whose roll stage is being
undone
Run Level: multiuser mode
Halt the member whose roll stage is being undone. Then run the
clu_upgrade undo roll memberid command on any other member that has
access to the halted member's boot disk. When the command completes,
boot the halted member. The member will now be using tagged files.
EXAMPLES
To display the status of a rolling upgrade:
# clu_upgrade -v status
To determine whether the preinstall stage can be run:
# clu_upgrade -c preinstall
To determine whether the preinstall stage has completed:
# clu_upgrade completed preinstall
To determine whether the member whose member ID is 3 has rolled:
# clu_upgrade -c roll 3
FILES
/var/adm/update/TruClusterKit
Location where cluster subsets are copied.
/var/adm/update/OSKit
Location where base subsets are copied.
/var/adm/update/NHDKit
Location where NDH subsets are copied.
/cluster/admin/clu_upgrade.log
Location of the clu_upgrade log file.
RELATED INFORMATION
Commands: installupdate(8), shutdown(8)
TruCluster Server Cluster Installation
Tru64 UNIX Installation Guide
Patch Kit Installation Instructions
NHD Release Notes and Installation Instructions
|
Index for
Section 8 |
|
|
Alphabetical
listing for C |
|
 |
Top of
page |
|