Le 22/01/2013 01:45, Josh Bowling a écrit : > I guess what I was most worried about was how Pacemaker would respond to > one of the nodes being restarted (assuming one of the updates required a > restart). But if I place the cluster into maintenance-mode beforehand it > shouldn't be flagged as UNCLEAN or anything right? >
It would never do that, even without maintenance-mode. What kind of cluster wouldn't let you restart a node ? You just have to make sure that all the remaining nodes can hosts all the resources (VM) in terms of RAM/CPUs etc. Anyway, you should have calculated that already to create location constraints if that's not the case. > > On Mon, Jan 21, 2013 at 8:40 AM, Florian Crouzat > <[email protected]>wrote: > >> Le 21/01/2013 02:30, Josh Bowling a écrit : >>> Hi all, >>> >>> I have an Ubuntu 12.04 based HA cluster running a few CentOS VMs and was >>> wondering what the best practices are for updating both the host machines >>> and virtual machines that are managed by Corosync + Pacemaker? >>> >>> I was thinking that I would put the cluster into maintenance-mode and >> then >>> update the machines, but what if one of the updates require a machine >>> reboot? I'm just worried that something will cause my cluster, and >>> therefore my services, to go down. >>> >>> Here are the steps I was thinking: >>> 1. put cluster into maintenance-mode >>> 2. update vms >>> 3. update secondary host >>> 4. switch secondary host to primary (moving vms) >>> 5. update host that was primary >> >> This way of performing updates is called "rolling upgrade". >> See http://clusterlabs.org/wiki/Upgrade for other possibilities. >> >>> >>> How does that sound? I'm not sure how switch secondary to primary by >>> command, but I'm sure it's in the documentation somewhere. And I guess >>> when I switch secondary to primary all of the VMs will be down >>> momentarily? What do the professionals do to keep all of their cluster >>> machines up to date without angering the entire customer base? >> >> If you intend to also update your VMs, I guess you will have to reboot >> them on the new kernel, so yes, you have to bring them down anyway, you >> can take this chance to reboot them on the correct node, eg: >> >> 1. maintenance-mode >> 2. move all VMs to a single node, say node2 >> 3. update node1, reboot, rejoin cluster >> 4. For each VM on node2: >> 4.1. Update VM >> 4.3. Shutdown VM (from outside the cluster) >> 4.2. Boot VM on already-up-to-date node1. (from outside the >> cluster) >> (and I'm assuming shared storage of course) >> 5. once node2 is free of VMs, update node2, reboot, rejoin cluster >> 6. all VMs are up-to-date on node1, both nodes are up-to-date >> 7. reprobe/cleanup resources >> 8. disable maintenance-mode. >> >> >> That's only if you /need/ to reboot the VMs, otherwise, there may be >> live migration stuff, I don't use linux-ha with virtualization... >> >> My 2 cents ;) >> >> >> -- >> Cheers, >> Florian Crouzat -- Cheers, Florian Crouzat _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
