The following sections describe the supported update methods for each Oracle Solaris OS version and platform, provided that all other requirements for the method are met. Check the documentation of other products in the cluster, such as volume management software and other applications, for any additional update requirements or restrictions.
Choose from the following methods to update your Oracle Solaris Cluster 4.4 cluster software:
For overview information about planning your Oracle Solaris Cluster 4.4 configuration, see Chapter 1, Planning the Oracle Solaris Cluster Configuration in Installing and Configuring an Oracle Solaris Cluster 4.4 Environment.
A standard update updates a cluster to a new release and updates the Oracle Solaris OS to the latest compatible version. You do not need to place the cluster in noncluster mode before performing this update because the update always occurs in the new boot environment (BE) and the existing BE remains unchanged. You can specify a name for the new BE or you can use the auto-generated name. All cluster nodes must be rebooted into the updated BE at the same time.
Any time you update the Oracle Solaris Cluster software, by default you also update the data services and Disaster Recovery Framework software. However, if you want to update the data services separately, see Overview of the Installation and Configuration Process in Planning and Administering Data Services for Oracle Solaris Cluster 4.4. If you want to update Oracle Solaris Cluster Disaster Recovery Framework separately, see the Installing and Configuring the Disaster Recovery Framework for Oracle Solaris Cluster 4.4.
For complete instructions on performing a standard update, see Performing a Standard Update.
The cluster outage is limited to the amount of time that is needed to reboot all cluster nodes into the updated BE.
In a dual-partition update, you divide the cluster into two groups of nodes. You bring down one group of nodes and update those nodes. The other group of nodes continues to provide services. After you complete update of the first group of nodes, you switch services to those updated nodes. You then update the remaining nodes and boot them back into the rest of the cluster.
The cluster outage time is limited to the amount of time that is needed for the cluster to switch over services to the updated partition.
Observe the following additional restrictions and requirements for the dual-partition update method:
Data format changes – Do not use the dual-partition update method if you intend to update an application that requires that you change its data format during the application update. The dual-partition update method is not compatible with the extended downtime that is needed to perform data transformation.
Location of application software – Applications must be installed on nonshared storage. Shared storage is not accessible to a partition that is in noncluster mode. Therefore, it is not possible to update application software that is located on shared storage.
Division of storage – Each shared storage device must be connected to a node in each group.
Single-node clusters – Dual-partition update is not available to update a single-node cluster. Use the standard update method instead.
Failover zone update – You cannot update failover zones if you are using the dual-partition update method. You can only update failover zones if you are using the standard update or rolling update method.
Configuration changes – Do not make cluster configuration changes that are not documented in the update procedures. Such changes might not be propagated to the final cluster configuration. Also, validation attempts of such changes would fail because not all nodes are reachable during a dual-partition update.
In a rolling update, you update software to an update release, such as from Oracle Solaris 11.3 to Oracle Solaris 11.4, or from Oracle Solaris Cluster version 4.3 to version 4.4 or to a version 4.3 SRU. You perform the update on one node at a time. Services continue on the other nodes except for the time it takes to switch services from a node to be updated to a node that will remain in service.
Observe the following additional restrictions and requirements for the rolling update method:
Oracle Solaris update paths – You can update the Oracle Solaris OS only to a new SRU or an update version of the same release. For example, you can perform a rolling update from Oracle Solaris 11.4 to a later compatible Oracle Solaris 11 release, but you cannot perform a rolling update from a version of Oracle Solaris 10.
Hardware configuration changes – Do not change the cluster configuration during a rolling update. For example, do not add to or change the cluster interconnect or quorum devices. If you need to make such a change, do so before you start the rolling update procedure or wait until after all nodes are updated and the cluster is committed to the new software version.
Duration of the update – Limit the amount of time that you take to complete a rolling update of all cluster nodes. After a node is booted into its updated boot environment (BE), boot the next cluster node into its updated BE soon as possible. You can experience performance penalties and other penalties when you run a mixed-version cluster for an extended period of time.
Software configuration changes – Avoid installing new data services or issuing any administrative configuration commands other than those in the update procedure during the update. Do not create or delete resources or resource groups during a rolling update.
New-feature availability – Until all nodes of the cluster are successfully updated and the update is committed, new features that are introduced by the new release might not be available.