 |
Index for
Section 8 |
|
 |
Alphabetical
listing for C |
|
 |
Bottom of
page |
|
clu_upgrade(8)
NAME
clu_upgrade - Perform a cluster rolling upgrade or patch, check the status
of a cluster rolling upgrade or patch
SYNOPSIS
/usr/sbin/clu_upgrade
Stages (in order):
clu_upgrade [-qv] setup 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 or create tagged files:
clu_upgrade [-qv] tagged [check] [prod_code [prod_code ...]]
clu_upgrade [-qv] tagged {add | remove} prod_code [prod_code ...]
Miscellaneous:
clu_upgrade help
clu_upgrade log
clu_upgrade version
OPTIONS
Stages:
A rolling upgrade or patch 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 memberid [prod_code [prod_code ...]]
The setup command can be run on any cluster member.
The setup command checks whether the cluster is ready to begin a
rolling upgrade. If so, setup prompts to determine whether you
plan to perform a rolling upgrade or a rolling patch. Then setup
backs up member-specific files for memberid, checks disk space,
creates the mandatory set of tagged files (copies of existing
files, but with .Old.. prepended to the file name), and prepares
the member specified by 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.
preinstall
The preinstall command must be run on the lead member.
The preinstall command checks 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 rolling 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 checks 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 checks that the postinstall stage is complete
and that an update installation or a patch has been performed. If
so, roll then rolls this member, configures it to not use tagged
files on the next reboot, and reboots the member. When the member
reboots, it is running on the new software.
switch The switch command can be run on any cluster member after all
members have rolled.
The switch command checks that all members are running the new or
patched versions of the software and that no members are using
the tagged files. If all checks succeed, switch throws a software
switch that turns on any new features that could not be used
until all members were upgraded.
At this point, the cluster is functionally upgraded.
clean The clean command can be run on any cluster member.
The clean command checks that the switch stage has completed. If
so, clean deletes all tagged files, deletes any ondisk, member-
specific backups created during the upgrade, removes status and
lock files, and deletes the cluster kit from
/var/adm/update/TruClusterKit.
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]
Checks whether the status of the current upgrade or patch is such
that the specified stage can be run. If no stage is specified,
the next stage is checked.
{check | -check | -c} roll memberid
Checks whether the specified member has rolled.
{started | -started} stage
Checks whether the specified stage has started.
{completed | -completed} stage
Checks whether the specified stage has completed.
Manually check or create tagged files:
{tagged | -tagged | -t} [check] [prod_code [prod_code ...]]
The tagged [check] command checks that the correct set of tagged
files has been created. If one or more three-letter product codes
are specified, clu_upgrade checks only the tagged files
associated with those products. If not product codes are
specified (clu_upgrade tagged or clu_upgrade tagged check),
clu_upgrade checks 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. (Files
associated with blocking layered products never have tagged files
created for them because blocking layered products are
automatically removed during the update installation.)
Do not create tagged files for any other layered product unless
you know that the product's vendor supports tagged files during a
roll.
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
A rolling upgrade is a method for upgrading cluster software while
providing uninterrupted client access to services.
A rolling upgrade and a rolling patch use the same procedure. The only
difference is whether you run installupdate or dupatch during the install
stage.
The clu_upgrade utility performs the administrative tasks associated with a
rolling upgrade or rolling patch. The sequence of tasks for both procedures
is similar. For simplicity, the following description uses the term rolling
upgrade for both types of roll. Any differences for a rolling patch are
explicitly called out.
You must be root to run the clu_upgrade command.
A cluster can continue to operate during a rolling upgrade or a patch
because there are two copies of almost every file. 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 starting an upgrade or patch, you must make sure that there is
adequate free space in each of the clusterwide root /, /usr, and /var 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.
Before starting an upgrade or patch, 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.
To perform a complete rolling upgrade or patch, the following clu_upgrade
commands are entered in order:
1. Command:clu_upgrade [-qv] setup memberid [prod_code [prod_code ...]]
On member: Any
Run level: 3
Where 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 checks that no rolling
upgrade or rolling patch 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: 3
Prepares the cluster for the running of either installupdate or
dupatch. 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: s for installupdate
Run level: 3 or s 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 (run level 3) to single-user mode (run level s. For
example, shutdown now.
4. Command: clu_upgrade postinstall
On member: The lead member
Run level: 3
Runs a series of checks to make sure that the install stage completed
successfully.
5. Command: clu_upgrade roll
On member: On the member to be rolled
Run level: s
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, you must 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: 3
After all members have rolled, the switch command turns on any new
features that had been disabled during the upgrade.
7. Command: clu_upgrade clean
On member: Any
Run level: 3
Deletes files that are no longer needed.
At each stage, the command provides the information needed to prepare for
the next stage.
With no arguments, clu_upgrade prints the status of the current rolling
upgrade or rolling patch. The started and completed flags let a user or
program check whether a specific stage has started or completed.
To check 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 check 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: 3
The clu_upgrade undo setup command must be run on the system where
clu_upgrade setup was run. Halt all other cluster members before
undoing the setup stage. (Only the lead member will be up when you run
the clu_upgrade undo setup command.) Depending on how many members the
cluster has, and how votes are allocated, you might have to use the
clu_quorum command to temporarily adjust votes so the cluster can
operate with only one member up.
When the undo of the setup stage is complete, boot the remaining
members of the cluster. If you adjusted member votes in order to run
the clu_upgrade undo setup command, use the clu_quorum command to
return them to their previous values.
· To undo the preinstall stage:
Command: clu_upgrade undo preinstall
On member: The lead member
Run Level: 3
· To undo the install stage:
Command: clu_upgrade undo install
On member: Any member except the lead member
Run Level: 3
Halt the lead member. 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: 3
· 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: 3
Halt the member whose roll stage is being undone. 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 check the status of a rolling upgrade or patch:
# clu_upgrade status
To check whether the preinstall stage can be run:
# clu_upgrade -c preinstall
To check whether the preinstall stage has completed:
# clu_upgrade completed preinstall
To check whether the member whose memberid is 3 has rolled:
# clu_upgrade -c roll 3
FILES
/var/adm/update/TruClusterKit
Location where new cluster subsets are loaded.
/var/adm/update/OSKit
Location where new base subsets are loaded.
/cluster/admin/clu_upgrade.log
Location of the clu_upgrade log file.
RELATED INFORMATION
Commands: clu_quorum(8), installupdate(8), shutdown(8)
Patch Kit Installation Instructions
|
Index for
Section 8 |
|
|
Alphabetical
listing for C |
|
 |
Top of
page |
|