 |
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 [-qv] roll
clu_upgrade [-qv] 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 command can be run on any cluster member.
The setup command tests whether the cluster is ready to begin a
rolling upgrade. If so, setup prompts to determine whether you
plan to perform an update installation or a patch. Then setup
backs up member-specific files for lead_memberid, 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, is 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. If performing a rolling upgrade, The
preinstall command copies the new cluster kit to
/var/adm/update/TruClusterKit, so it is available to the
installupdate command in the next stage.
install The install command must be run on the lead member.
If performing an update installation, the member must be in
single-user mode. If performing a patch, the member can be in
multi-user mode or single-user mode.
The install command verifies that this member is the lead member,
and then prompts you to run either installupdate or dupatch. When
the lead member reboots, it is running on the new software; it is
the first rolled member.
postinstall
The postinstall command command must be run on the lead member.
The postinstall command verifies that the update installation or
patch procedure 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.)
roll The roll command must be run on the member to be rolled.
The member must be in single-user mode. You must shut the member
down to single-user mode with the shutdown command; for example,
shutdown now. (You cannot boot the member to single-user mode;
you must shut down to single-user mode.) In single-user mode,
run bcheckrc before running clu_upgrade roll.
The roll command verifies that the postinstall stage is complete
and that an update installation or a patch has been performed. If
so, roll then backs up the member's member-specific files, sets
up the it(8) scripts that will run on reboot to perform the roll,
and reboots the member. During this boot, the it scripts roll
the member, build a customized kernel, and reboot with the
customized kernel.
switch The switch command can be run on any cluster member.
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 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 deletes the
/var/adm/update/TruClusterKit and /var/adm/update/OSKit
directories. 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.
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.
{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. One member at a time is 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 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 installupdate or dupatch 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.
· 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.
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
Software 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 or dupatch command 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 either installupdate or
dupatch. If performing a rolling upgrade, copies the cluster subsets
to /var/adm/update/TruClusterKit.
3. Optional Command: clu_upgrade install
Actual Command: {/sbin/installupdate | /usr/sbin/dupatch}
On member: The lead member
Run level: single-user mode for installupdate
Run level: single-user mode (recommended) or multi-user mode for
dupatch
The optional install command displays a message telling the user to
run installupdate or dupatch. Before running the installupdate
command, use the shutdown command to take the lead member from
multiuser mode to single-user mode. For example, shutdown now. (When
taking the system to single-user mode, you must shut the system down
to single-user mode; do not halt the system and then boot it to
single-user mode.)
If performing a rolling upgrade, 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.
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 both. 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, one at a time. (Because the lead member is
already using the new software, you do not have to roll that member.)
Before running clu_upgrade roll on a member, take that member from
multiuser mode to single-user mode with the shutdown command; for
example, shutdown now. (You cannot boot the member to single-user
mode; you must shut down to single-user mode.) Then run bcheckrc
before running the clu_upgrade roll command.
6. Command: clu_upgrade switch
On member: Any
Run level: multiuser mode
After all members have rolled, the switch command turns on any new
features that had been disabled during the upgrade.
When the 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. 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 new cluster subsets are copied.
/var/adm/update/OSKit
Location where new base subsets are copied.
/cluster/admin/clu_upgrade.log
Location of the clu_upgrade log file.
RELATED INFORMATION
Commands: installupdate(8), shutdown(8)
TruCluster Server Software Installation
Tru64 UNIX Installation Guide
Patch Kit Installation Instructions
|
Index for
Section 8 |
|
|
Alphabetical
listing for C |
|
 |
Top of
page |
|