[ClusterLabs] Special care needed when upgrading Pacemaker Remote nodes
Ken Gaillot
kgaillot at redhat.com
Sat Oct 29 01:39:15 CEST 2016
Hi all,
See the following wiki page if you are planning a rolling upgrade to
Pacemaker 1.1.15 from an earlier version, and your cluster includes
Pacemaker Remote nodes:
http://clusterlabs.org/wiki/Upgrading_to_Pacemaker_1.1.15_or_later_from_an_earlier_version
Details for anyone interested:
Pacemaker 1.1.15 included an increase in the LRMD protocol version,
which applies to communication between Pacemaker Remote nodes and the
full cluster nodes.
Because that was the first time that had ever happened, the impact on
rolling upgrades was not immediately noticed. I'm surprised we haven't
received any reports of problems since 1.1.15 was released.
Pacemaker 1.1.14 and earlier requires that the LRMD protocol version be
identical between the cluster and remote nodes. Any change means the
remote connection will fail. The workaround (detailed in the wiki page)
is to use constraints to tie older remote nodes to older cluster nodes,
and newer remote nodes to newer cluster nodes, until the rolling upgrade
is complete.
As of Pacemaker 1.1.15, the interpretation was modified so that older
remote nodes may connect to newer cluster nodes. So going forward, it
will be sufficient to upgrade all cluster nodes, then the remote nodes,
in a rolling upgrade. It is even possible to leave the remote nodes on
the older version, which might be useful, for example, if you are using
a remote node to run a legacy application in an older OS environment.
This spurred me to complete a long-planned overhaul of Pacemaker
Explained's "Upgrading" appendix:
http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/_upgrading.html
Feedback is welcome.
--
Ken Gaillot <kgaillot at redhat.com>
More information about the Users
mailing list