The following sections describe the supported upgrade methods for each Oracle Solaris OS version and platform, provided that all other requirements for any supported method are met. Check the documentation of other products in the cluster, such as volume management software and other applications, for any additional upgrade requirements or restrictions.
Choose from the following methods to upgrade your Oracle Solaris Cluster 4.3 cluster software:
For overview information about planning your Oracle Solaris Cluster 4.3 configuration, see Chapter 1, Planning the Oracle Solaris Cluster Configuration in Oracle Solaris Cluster 4.3 Software Installation Guide.
A standard upgrade upgrades a cluster to a new release and upgrades the Oracle Solaris OS to the latest compatible version. You do not need to place the cluster in noncluster mode before performing this upgrade because the upgrade 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 upgraded BE at the same time.
Any time you upgrade the Oracle Solaris Cluster software, by default you also upgrade the data services and Geographic Edition software. However, if you want to upgrade the data services separately, see Overview of the Installation and Configuration Process in Oracle Solaris Cluster 4.3 Data Services Planning and Administration Guide. If you want to upgrade Oracle Solaris Cluster Geographic Edition separately, see the Oracle Solaris Cluster 4.3 Geographic Edition Installation and Configuration Guide.
For complete instructions on performing a standard upgrade, see Performing a Standard Upgrade.
The cluster outage is limited to the amount of time that is needed to reboot all cluster nodes into the upgraded BE.
In a dual-partition upgrade, you divide the cluster into two groups of nodes. You bring down one group of nodes and upgrade those nodes. The other group of nodes continues to provide services. After you complete upgrade of the first group of nodes, you switch services to those upgraded nodes. You then upgrade 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 upgraded partition.
Observe the following additional restrictions and requirements for the dual-partition upgrade method:
Data format changes - Do not use the dual-partition upgrade method if you intend to upgrade an application that requires that you change its data format during the application upgrade. The dual-partition upgrade 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 upgrade 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 upgrade is not available to upgrade a single-node cluster. Use the standard upgrade method instead.
Failover zone upgrade – You cannot upgrade failover zones if you are using the dual-partition upgrade method. You can only upgrade failover zones if you are using the standard upgrade or rolling upgrade method.
Configuration changes - Do not make cluster configuration changes that are not documented in the upgrade 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 upgrade.
In a rolling upgrade, you upgrade software to an update release, such as from Oracle Solaris 11.1 to Oracle Solaris 11.2 SRU 13, or from Oracle Solaris Cluster version 4.2 to version 4.3 or to a version 4.2 SRU. You perform the upgrade 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 upgraded to a node that will remain in service.
Observe the following additional restrictions and requirements for the rolling upgrade method:
Oracle Solaris upgrade paths - You can upgrade the Oracle Solaris OS only to a new SRU or an update version of the same release. For example, you can perform a rolling upgrade from Oracle Solaris 11.2 SRU 13 to a later compatible Oracle Solaris 11 release, but you cannot perform a rolling upgrade from a version of Oracle Solaris 10.
Hardware configuration changes - Do not change the cluster configuration during a rolling upgrade. 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 upgrade procedure or wait until after all nodes are upgraded and the cluster is committed to the new software version.
Duration of the upgrade - Limit the amount of time that you take to complete a rolling upgrade of all cluster nodes. After a node is booted into its upgraded boot environment (BE), boot the next cluster node into its upgraded 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 during the upgrade.
New-feature availability - Until all nodes of the cluster are successfully upgraded and the upgrade is committed, new features that are introduced by the new release might not be available.