Installation of a newer major version of a package or distribution, which brings new features. See also Offline Migration versus Rolling Upgrade.
4.2 Upgrading your Cluster to the Latest Product Version
Which upgrade path is supported, and how to perform the upgrade depends both on the current product version and on the target version you want to migrate to.
Rolling upgrades are only supported from the GA of a product version to the next service pack, and from one service pack to the next.
Offline migrations are required to upgrade from one major version to the next major version (for example, from SLE HA 11 to SLE HA 12) or from a service pack belonging to one major version to the next major version (for example, from SLE HA 11 SP3 to SLE HA 12).
For information regarding the upgrade of the base system (SUSE Linux Enterprise Server), see the SUSE Linux Enterprise Server Deployment Guide of the target version you want to upgrade to.
The guide is available at http://www.suse.com/documentation/.
Section 4.2.1 gives an overview of the supported upgrade paths for SLE HA (Geo) and the additional documentation to refer to.
Important: No Support for Mixed Clusters and Reversion After Upgrade
Mixed clusters running on SUSE Linux Enterprise High Availability Extension 11/
SUSE Linux Enterprise High Availability Extension 12 are not supported.
After the upgrade process to product version 12, reverting back to product version 11 is not supported.
52 Supported Upgrade Paths for SLE HA and SLE HA Geo SLE HA 12 SP1
4.2.1 Supported Upgrade Paths for SLE HA and SLE HA Geo
Upgrade From ... To Upgrade Path For Details See SLE HA 11 SP3 to
SLE HA (Geo) 12
Offline Migration Base System: SUSE Linux Enterprise Server 12 Deployment Guide, part Updating and Upgrading SUSE Linux Enterprise SLE HA: Performing a Cluster-wide Offline Migration
SLE HA Geo: Geo Clustering for SUSE Linux Enterprise High Availability Extension 12 Quick Start, section Upgrading from SLE HA (Geo) 11 SP3 to SLE HA Geo 12 SLE HA (Geo) 11 SP4
to
SLE HA (Geo) 12 SP1
Offline Migration Base System: SUSE Linux Enterprise Server 12 SP1 Deployment Guide, part Updating and Upgrading SUSE Linux Enterprise
SLE HA: Performing a Cluster-wide Offline Migration
SLE HA Geo: Geo Clustering for SUSE Linux Enterprise High Availability Extension 12 SP1 Quick Start, section Upgrading to the Latest Product Version
53 Required Preparations Before Upgrading SLE HA 12 SP1
Upgrade From ... To Upgrade Path For Details See SLE HA (Geo) 12 to
SLE HA (Geo) 12 SP1
Rolling Upgrade Base System: SUSE Linux Enterprise Server 12 SP1 Deployment Guide, part Updating and Upgrading SUSE Linux Enterprise
SLE HA: Performing a Cluster-wide Rolling Upgrade
SLE HA Geo: Geo Clustering for SUSE Linux Enterprise High Availability Extension 12 SP1 Quick Start, section Upgrading to the Latest Product Version
All documentation listed in the column For Details See is available from http://www.suse.com/
documentation/.
4.2.2 Required Preparations Before Upgrading
Backup
Ensure that your system backup is up to date and restorable.
Testing
Test the upgrade procedure on a staging instance of your cluster setup first, before performing it in a production environment.
This gives you an estimation of the time frame required for the maintenance window. It also helps to detect and solve any unexpected problems that might arise.
4.2.3 Offline Migration
This section applies to the following scenarios:
Upgrading from SLE HA 11 SP3 to SLE HA 12 Upgrading from SLE HA 11 SP4 to SLE HA 12 SP1
54 Offline Migration SLE HA 12 SP1
If your cluster is still based on an older product version than the ones listed above, first upgrade it to a version of SUSE Linux Enterprise Server and SUSE Linux Enterprise High Availability Extension that can be used as a source for upgrading to the desired target version.
The High Availability Extension 12 cluster stack comes with major changes in various components (for example, /etc/corosync/corosync.conf, disk formats of OCFS2).
Therefore, a rolling upgrade from any SUSE Linux Enterprise High Availability Extension 11 version is not supported. Instead, all cluster nodes must be offline and the cluster needs to be migrated as a whole as described in Procedure 4.1, “Performing a Cluster-wide Offline Migration”.
PROCEDURE 4.1: PERFORMING A CLUSTER-WIDE OFFLINE MIGRATION
1. Log in to each cluster node and stop the cluster stack with:
root # rcopenais stop
2. For each cluster node, perform an upgrade to the desired target version of SUSE Linux Enterprise Server and SUSE Linux Enterprise High Availability Extension. If you have an existing Geo cluster setup and want to upgrade it, see the additional instructions in the Geo Clustering for SUSE Linux Enterprise High Availability Extension Quick Start. To find the details for the individual upgrade processes, see Section 4.2.1, “Supported Upgrade Paths for SLE HA and SLE HA Geo”.
3. After the upgrade process has finished, reboot each node with the upgraded version of SUSE Linux Enterprise Server and SUSE Linux Enterprise High Availability Extension.
4. If you use OCFS2 in your cluster setup, update the on-device structure by executing the following command:
root # tunefs.ocfs2 --update-cluster-stack PATH_TO_DEVICE
It adds additional parameters to the disk which are needed for the updated OCFS2 version that is shipped with SUSE Linux Enterprise High Availability Extension 12 and 12 SPx.
5. To update /etc/corosync/corosync.conf for Corosync version 2:
a. Log in to one node and start the YaST cluster module.
b. Switch to the Communication Channels category and enter values for the following new parameters: Cluster Name and Expected Votes. For details, see Procedure 3.5,
“Defining the First Communication Channel”.
55 Offline Migration SLE HA 12 SP1
If YaST should detect any other options that are invalid or missing according to Corosync version 2, it will prompt you to change them.
c. Confirm your changes in YaST. YaST will write them to /etc/corosync/
corosync.conf.
d. If Csync2 is configured for your cluster, use the following command to push the updated Corosync configuration to the other cluster nodes:
root # csync2 -xv
For details on Csync2, see Section 3.5.4, “Transferring the Configuration to All Nodes”. Alternatively, synchronize the updated Corosync configuration by manually copying
/etc/corosync/corosync.conf to all cluster nodes.
6. Log in to each node and start the cluster stack with:
root # systemctl start pacemaker
7. Check the cluster status with crm status or with Hawk.