[ClusterLabs] [EXT] Migrating off CentOS

[Windl, Ulrich]

Hi!

I’m no expert, but my guess is that Debian is more conservative than OpenSUSE Leap, which is in turn more conservative than Fedora.
So if you cannot use Fedora (frequent out of support releases), you might consider Leap (15.5) before considering Debian.
I’m not saying anything against Debian, however.
Anyway I doubt that you can do a rolling upgrade while changing the distribution.

Kind reagrds,
Ulrich

From: Users <users-bounces at clusterlabs.org> On Behalf Of Billy Croan
Sent: Saturday, January 13, 2024 4:08 PM
To: users at clusterlabs.org
Subject: [EXT] [ClusterLabs] Migrating off CentOS

I'm planning to migrate a two-node cluster off CentOS 7 this year.  I think I'm taking it to Debian Stable, but open for suggestions if any distribution is better supported by pacemaker.

Have any of you had success doing major upgrades (bullseye to bookworm on Debian) of your physical nodes one at a time while each node is in standby+maintenance, and rolling the vm from one to the other so it doesn't reboot while the hosts are upgraded?  That has worked well for me for minor OS updates, but I'm curious about the majors.

My project this year is even more major, not just upgrading the OS but changing distributions.

I think I have three possible ways I can try this:
1) wipe all server disks and start fresh.

2) standby and maintenance one node, then reinstall it with a new OS and make a New Cluster.  shutdown the vm and copy it, offline, to the new one-node cluster. and start it up there. Then once that's working, wipe and reinstall the other node, and add it to the new cluster.

3) standby and maintenance one node, then Remove it from the cluster.  Then reinstall it with the new distribution's OS.  Then re-add it to the Existing Cluster.  Move the vm resource to it and verify it's working, then do the same with the other physical node, and take it out of standby&maint to finish.

(Obviously any of those methods begin with a full backup to offsite and local media. and end with a verification against that backup.)

#1 would be the longest outage but the "cleanest result"
#3 would be possibly no outage, but I think the least likely to work.  I understand EL uses pcs and debian uses crm for example...
#2 is a compromise that should(tm) have only a few seconds of outage.  But could blow up i suppose.  They all could blow up though so I'm not sure that should play a factor in the decision.

I can't be the first person to go down this path.  So what do you all think?  how have you done it in the past?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20240119/7905450f/attachment.htm>