Product SiteDocumentation Site

7.2. Upgrading Cluster Software

There are three approaches to upgrading a cluster, each with advantages and disadvantages.

Table 7.1. Upgrade Methods

MethodAvailable between all versionsCan be used with Pacemaker Remote nodesService outage during upgradeService recovery during upgradeExercises failover logicAllows change of messaging layer [a]
Complete cluster shutdown
yes
yes
always
N/A
no
yes
Rolling (node by node)
no
yes
always [b]
yes
yes
no
Detach and reattach
yes
no
only due to failure
no
no
yes
[a] Currently, Corosync version 2 and greater is the only supported cluster stack, but other stacks have been supported by past versions, and may be supported by future versions.
[b] Any active resources will be moved off the node being upgraded, so there will be at least a brief outage unless all resources can be migrated "live".

7.2.1. Complete Cluster Shutdown

In this scenario, one shuts down all cluster nodes and resources, then upgrades all the nodes before restarting the cluster.
  1. On each node:
    1. Shutdown the cluster software (pacemaker and the messaging layer).
    2. Upgrade the Pacemaker software. This may also include upgrading the messaging layer and/or the underlying operating system.
    3. Check the configuration with the crm_verify tool.
  2. On each node:
    1. Start the cluster software. Currently, only Corosync version 2 and greater is supported as the cluster layer, but if another stack is supported in the future, the stack does not need to be the same one before the upgrade.
One variation of this approach is to build a new cluster on new hosts. This allows the new version to be tested beforehand, and minimizes downtime by having the new nodes ready to be placed in production as soon as the old nodes are shut down.