The no-roll patch process lets you install patches on a cluster without performing a rolling upgrade. This chapter provides the following information:
An overview of the no-roll patch process
A step-by-step description of the process as it differs from
a normal
dupatch
session
Throwing the version switch
How to remove patches from a cluster using the no-roll patch method
Note
The no-roll technology is included in Rev. 34-00 and higher of the
dupatch
utility. You can find the revision number on the first output line you see when you rundupatch
(see the example in Section 6.2). The first kit that includes this technology was issued in April 2002.
A rolling upgrade lets you perform a software upgrade on a cluster while maintaining high availability of the cluster. To provide this high availability, a certain amount of setup work is required to build tagged files and to reboot the cluster members to use the tagged files. This can take a considerable amount of time.
However, if you have a mission-critical environment and want to use a patch method that applies patches quickly, minimizes down time of the cluster, and reduces the number of reboots required, you might want to use the no-roll patch process. This process patches your cluster in one operation that requires only one or two reboots of the whole cluster to complete the operation. You will need the second reboot only if you install a patch that contains a version switch (see Section 6.3).
The no-roll patch process is a modification of
dupatch
;
that is, all patches are installed or removed entirely using the
dupatch
utility, as opposed to the
clu_upgrade
and
dupatch
utilities used in the rolling upgrade procedure.
The no-roll process conducts significantly fewer operations than the rolling
upgrade procedure.
While a no-roll patch installation is in progress, no other critical operations should be running on the cluster because the cluster will change state and reboot automatically at various stages of the procedure.
In addition, the no-roll patch procedure employs the use of the Tru64 UNIX
Event Management System (EVM) to send cluster-wide events.
As a result, patches
must be applied to the system in multiuser mode.
If you attempt to use the
no-roll procedure while in single-user mode, you will be advised to change
the cluster to multiuser mode before continuing.
6.2 Steps for Running a No-Roll Procedure
The following steps describe how to patch your cluster using the no-roll procedure.
NOTE
To use the no-roll patch method, you must not use the
clu_upgrade
utility to prepare the cluster, as you would for a rolling upgrade prior to runningdupatch
. If a rolling upgrade is in progress before attempting to rundupatch
, then the no-roll option will not be available until the cluster is restored to the state prior to the roll attempt.
With your system running in multiuser mode, enter the
dupatch
command:
#
dupatch
Tru64 UNIX Patch Utility (Rev. 36-02) ========================== - This dupatch session is logged in /var/adm/patch/log/session.log Main Menu: --------- 1) Patch Installation 2) Patch Deletion 3) Patch Documentation 4) Patch Tracking 5) Patch Baseline Analysis/Adjustment h) Help on Command Line Interface q) Quit Enter your choice:
From the main menu select the patch installation or patch deletion option. (See Section 4.8.1.2.)
If
dupatch
determines it is running on
a cluster that has not been prepared to do a rolling patch, it asks if you
want to do the patch operation without rolling.
You will see a message similar
to the following:
Checking Cluster State...done This system is part of a cluster which has not been prepared to do a rolling patch installation or deletion. Do you wish to perform this patch operation cluster-wide without using the rolling-patch mechanism? Please answer y or n ? [y/n]:
If you choose
yes
,
dupatch
proceeds
by allowing you to do the analysis and selection of patches to be installed
or removed, after which the whole cluster is brought down to
init
level 2 via an Event Management System event.
If you are using
dupatch
from the command line and
do not specify the
-proceed
option, you will need to press
Return in order to transition the cluster from level 3 to level 2.
If the
-proceed
option was set, the transition will occur automatically.
After
dupatch
completes its patch analysis, it will
perform the patch operation on the member on which you ran
dupatch
.
After the patches are installed or removed,
dupatch
will issue a second event to the remaining cluster members that
will instruct them to complete their patch operations in parallel.
The
dupatch
utility then waits a calculated time-out
period for all the other cluster members to complete their operations.
The
time-out period is based on the time it took to perform the patch operation
on the member running
dupatch
.
After the patch operation is completed on all other cluster members,
dupatch
will complete the procedure on the member on which the
dupatch
command was issued.
If a cluster member times out or encounters an error,
dupatch
will report the problem, suspend the process, and send you a message
to check the problematic member in order to resolve the problem.
Once
dupatch
has resumed, it will complete the patch process on the rest
of the cluster.
If a cluster member is known to be down when you issue the
dupatch
command, an
/sbin/it
job will be posted
for the member to run the cluster patch script upon reboot.
(For more information,
see the
it
(8)
Because all patches currently require a reboot, the whole cluster will
reboot after all the members report back.
6.3 Throwing the Version Switch
If a patch applied to the system requires
the use of a version switch, you will see a message similar to the following
at the end of the
dupatch
session:
********************************************************************* Patch OSFPAT00074200510 has been identified as needing a version switch. Once the following reboot is complete, please enter the "/var/adm/patch/noroll/noroll_versw" command from any cluster member. *********************************************************************
As indicated by the message, you must enter the
/var/adm/patch/noroll/noroll_versw
command from any cluster member.
This is a manual operation that
you must perform after the reboot is complete.
All cluster members must be
up prior to running the
noroll_versw
command.
If they are
not, the
noroll_versw
command will fail and the version
switch will not take place.
After issuing the
noroll_versw
command, reboot your
system to ensure system integrity.
6.4 Removing Patches
You can use the no-roll patch process to remove patches from a cluster regardless of whether the patches were installed on the cluster using either the no-roll or the rolling upgrade procedures. However, if the version switch was thrown after the installation of the patches, it is necessary to undo the version switch as described in the instructions in Section 5.7 prior to attempting to remove the patch requiring the version switch.