[ClusterLabs] Upgrading from CentOS 6 to CentOS 7
ibrewster at flyravn.com
Wed Jan 9 16:55:58 UTC 2019
> On Jan 3, 2019, at 1:56 PM, Ken Gaillot <kgaillot at redhat.com> wrote:
> On Thu, 2019-01-03 at 19:40 +0000, Israel Brewster wrote:
>> If I do need to build a new CentOS cluster, how can I get it fully
>> set up with all the resources, but NOT let it start anything until I
>> perform the cutover? Obviously it would be a bad thing for both the
>> CentOS 7 box and the existing CentOS 6 boxes to have the same IP's!
> I'd make the new configuration as identical as possible to the old one,
> but use some test IPs until it's ready to go live.
> You can get the old config with "pcs cluster cib <filename> --config",
> copy that to the new nodes, edit it as needed with "pcs -f <filename>
> ...", then activate it with "pcs cluster cib-push <filename> --config".
Thanks, that worked like a charm. I actually edited the XML file directly to replace all instances of "lsb" with "systemd", and changed the IP addresses to a different subnet, and the edited XML file loaded properly and (upon fixing the launch of a couple of services) everything came up as expected. If I understand things correctly, as I move forward I can simply add new nodes to the cluster, and the config will copy across automatically, so that should be good!
>> Can I copy *any* of the config from the existing CentOS 6 boxes, or
>> do I have to fully re-create all the resources from scratch on the
>> CentOS 7 box? I'm assuming that initially having a "single node"
>> cluster (until I can rebuild the other CentOS 6 box to CentOS 7)
>> won't be an issue.
> Single-node clusters are fine.
> I don't know what your resources are, but you probably have some data
> that will need to be copied from the old to the new when going live.
> (Stop old -> sync data -> start new.)
Actually, the data is all stored on a separate database server, so no issues there. In fact, everything is designed so multiple nodes can use the same data at the same time, so I can have the new one up and running (aside from IP's) at the same time as the old one with no problems.
> Everything will be the same whether you want to upgrade the existing
> cluster one node at a time, or replace it with a new cluster. But one
> node at a time would mean you don't have high availability during the
Right. Which *should* be fine. Of course, famous last words...
> For more tips, see:
> (You're stuck with the "complete cluster shutdown" method since you're
> updating the OS and changing corosync major versions.)
Thanks. Good information.
>> Thanks for any input you can provide!
>> Israel Brewster
>> Systems Analyst II
>> 5245 Airport Industrial Rd
>> Fairbanks, AK 99709
>> (907) 450-7293
> Users mailing list: Users at clusterlabs.org
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
More information about the Users