hi Florian, thanks for the tip about maintenance mode - i wasn't aware of such possibility. (Thought i'd read the Pacemaker docs enough times, but clearly not! :) In case the dynamic membership solution proves unstable or has some other hidden problems that i'm not aware of yet, it is nice to have an alternative. Thanks. Anton. On Oct 21, 2011, at 2:42 PM, Florian Haas wrote: > Hi Anton, > > I think this is a pretty spiffy idea, although my C-foo is far too > limited to judge the patch quality so I'll leave that to sdake and team. > Just let me pitch in one thought that may make your life easier in the > interim (i.e. while the patch is pending). > > On 2011-10-21 19:46, Anton Jouline wrote: >> We have scripts and outside logic to monitor the state of the cluster >> - in other words, we know when servers were joining and leaving. So >> initially, we took an approach of updating the corosync.conf file and >> restarting corosync service on all machines in the cluster. >> Unfortunately that wasn't good enough, because it meant that >> Pacemaker services needed to be restarted as well, and therefore all >> clustered resources under Pacemaker's control had to be restarted >> too, which meant interruption of service. > > This part is actually not true, as you can modify the cluster > communications layer underneath Pacemaker at will, without causing > service interruption, by putting the cluster into maintenance mode (crm > configure property maintenance-mode=true). One minor downside of > maintenance mode is that it is cluster wide -- but still, that makes it > better than causing a service outage. > > Just my two cents. > > Cheers, > Florian > > -- > Need help with High Availability? > http://www.hastexo.com/now _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
