Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster System Administration Guide Oracle Solaris Cluster |
1. Introduction to Administering Oracle Solaris Cluster
2. Oracle Solaris Cluster and RBAC
3. Shutting Down and Booting a Cluster
4. Data Replication Approaches
5. Administering Global Devices, Disk-Path Monitoring, and Cluster File Systems
7. Administering Cluster Interconnects and Public Networks
10. Configuring Control of CPU Usage
11. Patching Oracle Solaris Cluster Software and Firmware
Patching Oracle Solaris Cluster Software
How to Apply a Rebooting Patch (Node)
How to Apply a Rebooting Patch (Cluster)
How to Apply a Nonrebooting Oracle Solaris Cluster Patch
How to Apply Patches in Single-User Mode to Nodes with Failover Zones
Changing an Oracle Solaris Cluster Patch
How to Remove a Non-Rebooting Oracle Solaris Cluster Patch
How to Remove a Rebooting Oracle Solaris Cluster Patch
12. Backing Up and Restoring a Cluster
13. Administering Oracle Solaris Cluster With the Graphical User Interfaces
Due to the nature of a cluster, all cluster member nodes must be at the same patch level for proper cluster operation. Occasionally, when patching a node with an Oracle Solaris Cluster patch, you might need to temporarily remove a node from cluster membership or stop the entire cluster before installing the patch. This section describes these steps.
Before applying an Oracle Solaris Cluster patch, check the patch's README file. Also, check the upgrade requirements for your storage devices to determine which patch method they require.
Note - For Oracle Solaris Cluster patches, always defer to the patch's README file and to SunSolve for instructions that supersede procedures in this chapter.
Patch installation on all cluster nodes can be described by one of the following scenarios:
A node must be booted to single-user mode, using the command boot -sx or shutdown -g -y -i0, before the patch or firmware can be applied, then rebooted to join the cluster. First you need to put the node into a “quiet” state by switching any resource groups or device groups from the node to be patched to another cluster member. Also, apply the patch or firmware to one cluster node at a time to avoid shutting down the entire cluster.
The cluster itself remains available during this type of patch application, even though individual nodes are temporarily unavailable. A patched node is able to rejoin a cluster as a member node even though other nodes are not yet at the same patch level.
The cluster must be stopped and each node must be booted to single-user mode, using the command boot -sx or shutdown -g -y -i0, to apply the software or firmware patch. Then, reboot the nodes to rejoin the cluster. For this type of patch, the cluster is unavailable during patch application.
A node does not have to be in a “quiet” state (it can still be mastering resource groups or device groups), nor does it have to be or rebooted when applying the patch. However, you should still apply the patch to one node at a time and verify that the patch works before patching another node.
Note - Underlying cluster protocols do not change because of a patch.
Use the patchadd command to apply a patch to the cluster, and patchrm to remove a patch (when possible).
Use the following tips to help you administer Oracle Solaris Cluster patches more efficiently:
Always read the patch README file before applying the patch.
Check the upgrade requirements of your storage devices to determine which patch method they require.
Apply all patches (required and recommended) before running the cluster in a production environment.
Check the hardware firmware levels and install any required firmware updates that might be needed.
All nodes acting as cluster members must have the same patches.
Keep cluster subsystem patches up to date. These patches include, for example, volume management, storage device firmware, and cluster transport.
Review patch reports regularly, such as once a quarter, and patch an Oracle Solaris Cluster configuration by using the recommended patch suite.
Apply selective patches as recommended by Enterprise Services.
Test failover after major patch updates. Be prepared to back out the patch if cluster operation is degraded or impaired.