Mailing List Archive: How to avoid CRM sending stop when ha.cf gets 2nd node configured

How to avoid CRM sending stop when ha.cf gets 2nd node configured

Nov 7, 2014, 4:58 PM

Post #1 of 3 (849 views)

Hi,
While using heartbeat and pacemaker, is it possible to bringup first node which can go as Master, followed by second node which should go as Slave without causing any issues to the first node? Currently, I see a Â couple of problems in achieving this:1. Assuming I am not using mcast communication, heartbeat is mandating me to configure second node info either in ha.cf or in /etc/hosts file with associated IP address. Why can't it come up by itself as Master to start with?
2. If I update ha.cf with the 2nd node info and use 'heartbeat -r' CRM first sends stop on the Master before sending start.
Appreciate any help or pointers.
Thanks,
Aridbh.

Re: How to avoid CRM sending stop when ha.cf gets 2nd node configured [ In reply to ]

andrew at beekhof

Nov 9, 2014, 7:29 PM

Post #2 of 3 (820 views)

Permalink

> On 8 Nov 2014, at 11:58 am, aridh bose <aridbh@yahoo.com> wrote:
>
> Hi,
>
> While using heartbeat and pacemaker, is it possible to bringup first node which can go as Master, followed by second node which should go as Slave without causing any issues to the first node? Currently, I see a couple of problems in achieving this:
> 1. Assuming I am not using mcast communication, heartbeat is mandating me to configure second node info either in ha.cf or in /etc/hosts file with associated IP address. Why can't it come up by itself as Master to start with?

Because its not using mcast and therefor doesn't know how to talk to other nodes in the future.

>
> 2. If I update ha.cf with the 2nd node info and use 'heartbeat -r' CRM first sends stop on the Master before sending start.
>
> Appreciate any help or pointers.
>
> Thanks,
> Aridbh.
> _______________________________________________
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: How to avoid CRM sending stop when ha.cf gets 2nd node configured [ In reply to ]

lars.ellenberg at linbit

Nov 10, 2014, 4:48 AM

Post #3 of 3 (814 views)

Permalink

On Sat, Nov 08, 2014 at 12:58:36AM +0000, aridh bose wrote:
> Hi,
> While using heartbeat and pacemaker, is it possible to bringup first
> node which can go as Master, followed by second node which should go
> as Slave without causing any issues to the first node? Currently, I
> see a couple of problems in achieving this:1. Assuming I am not using
> mcast communication, heartbeat is mandating me to configure second
> node info either in ha.cf or in /etc/hosts file with associated IP
> address. Why can't it come up by itself as Master to start with?
>
> 2. If I update ha.cf with the 2nd node info and use 'heartbeat -r' CRM
> first sends stop on the Master before sending start.
> Appreciate any help or pointers.

Regardless of what you do there, or why,
or on which communication stack:

how about you first put pacemaker into "maintenance-mode",
then you do your re-archetecturing of your cluster,
and once you are satisfied with the new cluster,
you take it out of maintenance mode again?

At least that is one of the intended use cases
for maintenance mode.

--
: Lars Ellenberg
: http://www.LINBIT.com | Your Way to High Availability
: DRBD, Linux-HA and Pacemaker support and consulting

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org