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 “Throwing the Version Switch”).
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.