[ClusterLabs] Upgrading an Ubuntu 18.04 failover System

Ken Gaillot kgaillot at redhat.com
Tue Jan 31 10:03:19 EST 2023


On Tue, 2023-01-31 at 12:05 +0100, hajo.locke at gmx.de wrote:
> Hello List,
>  
> i have a question about upgrading an Ubuntu 18.04 FailOver System and
> hope to get some good hints.
>  
> - OS Ubuntu 18.04
> - corosync 2.4.3
> - pacemaker 1.1.18
> - haproxy 1.8.8
>  
> I have a quite simple system. 2 members in a failover-cluster.  I
> have 2 primitives configured, thats an IP and haproxy. both are
> grouped to have them active on same member. I followed typical
> webtutorials.
> /etc/corosync/corosync.conf is minimalistic 
> https://pastebin.com/tCLrXYrg
>  
> This works without problems for around 4 years.
> Now i plan to do an OS Upgrade to Ubuntu 20.04 and reuse my
> failovermembers. I could also build a new cluster with new Ubuntu
> 22.04 servers, but i want to try the upgrade first.
>  
> Ubuntu 20.04 would have these versions:
> - pacemaker 2.0.3
> - corosync 3.0.3
> - haproxy 2.0.29
>  
> Version from 18.04 and 20.04 differ considerable. 
>  
> I read this document 
> https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Administration/html/upgrading.html
> But iam still not sure to use the Rolling (7.2.2) or the Detach and
> Reattach (7.2.3) way. May be Detach and Reattach is more appropriate
> to my scenario. 
> The thing is to get the cluster working after 1 node is upgraded to
> make sure primitives/services are able to switch to upgraded host.
>  
> Or do you suggest building a new cluster with new servers, because
> versions from 18.04/20.04 differ to much?
>  
> Thank you,
> Hajo

While the Pacemaker versions support rolling upgrades, those Corosync
versions do not, so you'll have to do the detach-and-reattach method.

The main reason to do a new cluster instead is if you want to do some
testing before making it live.
-- 
Ken Gaillot <kgaillot at redhat.com>



More information about the Users mailing list