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?


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
> _______________________________________________
> 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

Reply via email to