Alright, that's what I thought. This is the first cluster I've ever built and managed so I just wanted to be sure.
As for leaving enough nodes up to handle the VMs, it's a primary-secondary setup so I'd only be updating a node when it's set to secondary. What if a new version of Pacemaker/Corosync is included in the updates? I'm sure updating it wouldn't cause any compatibility issues. Don't mind me, I'm known for over-thinking and over-worrying about stuff. On Jan 22, 2013 4:17 PM, "Florian Crouzat" <[email protected]> wrote: > 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 > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
