> On Jan 3, 2019, at 1:56 PM, Ken Gaillot <[email protected]> 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 > upgrade. Right. Which *should* be fine. Of course, famous last words... > > For more tips, see: > > http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/#_upgrading > > (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: [email protected] > https://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org _______________________________________________ Users mailing list: [email protected] https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
