date:20131209

Re: [Pacemaker] Reg. trigger when node failure occurs

2013-12-09 Thread Michael Schwartzkopff

Am Dienstag, 10. Dezember 2013, 12:19:25 schrieb ESWAR RAO:
> Hi All,
> 
> Can someone please let me know if there is a clean to trigger any script by
> pacemaker if HB on a node has stopped/node failed occurred if I ran
> HB+pacemaker on a 3 node setup??
> 
> Thanks
> Eswar
> 
> On Mon, Dec 9, 2013 at 5:16 PM, ESWAR RAO  wrote:
> > Hi All,
> > 
> > I have a 3 node ( node1, node2, node3 ) setup on which HB+pacemaker runs.
> > I have resources running on clone mode on node1 and node2.
> > 
> > Is there anyway to get a trigger when a node failure occurs i.e., can i
> > trigger any script if the node3 fails (on which no resource runs) ???

Yes. run a ocf:pacemaker:ClusterMon resource and read man crm_mon for the 
additional options to call a script.

-- 
Mit freundlichen Grüßen,

Michael Schwartzkopff

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

signature.asc
Description: This is a digitally signed message part.
___
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: [Pacemaker] Reg. trigger when node failure occurs

2013-12-09 Thread ESWAR RAO

Hi All,

Can someone please let me know if there is a clean to trigger any script by
pacemaker if HB on a node has stopped/node failed occurred if I ran
HB+pacemaker on a 3 node setup??

Thanks
Eswar



On Mon, Dec 9, 2013 at 5:16 PM, ESWAR RAO  wrote:

> Hi All,
>
> I have a 3 node ( node1, node2, node3 ) setup on which HB+pacemaker runs.
> I have resources running on clone mode on node1 and node2.
>
> Is there anyway to get a trigger when a node failure occurs i.e., can i
> trigger any script if the node3 fails (on which no resource runs) ???
>
>
> Thanks
> Eswar
>
___
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] is ccs as racy as it feels?

2013-12-09 Thread Brian J. Murrell

So, I'm trying to wrap my head around this need to migrate to pacemaker
+CMAN. I've been looking at
http://clusterlabs.org/quickstart-redhat.html and
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/

It seems "ccs" is the tool to configure the CMAN part of things.

The first URL talks about using ccs to create a local configuration and
then "copy" that around to the rest of the cluster. Yuck.

The first URL doesn't really cover how one builds up clusters (i.e. over
time) but assumes that you know what your cluster is going to look like
before you build that configuration and says nothing about what to do
when you decide to add new nodes at some later point. I would guess
more "ccm -f /etc/cluster/cluster.conf" and some more copying around
again. Does anything need to be prodded to get this new configuration
that was just copied? I do hope just "prodding" and not a restart of
all services including pacemaker managed resources.

The second URL talks about ricci for propagating the configuration
around. But it seems to assume that all configuration is done from a
single node and then "sync'd" to the rest of the cluster with ricci in a
"last write wins" sort of work-flow.

So unlike pacemaker itself where any node can modify the configuration
of the CIB (raciness in tools like crm aside), having multiple nodes
using ccs feels quite dangerous in a "last-write-wins" kind of way. Am
I correct?

This makes it quite difficult to dispatch the task of configuring the
cluster out to the nodes that will be participating in the cluster --
having them configure their own participation. This distribution of
configuration tasks all works fine for pacemaker-proper (if you avoid
tools like crm) but feels like it's going to blow up when having
multiple nodes trying to add themselves and their own configuration to
the CMAN configuration -- all in parallel.

Am I correct about all of this? I hope I am not, because if I am this
all feels like a (very) huge step backward from the days where corosync
+pacemaker configuration could be carried out in parallel, on multiple
nodes without having to designate particular (i.e. one per cluster)
nodes as the single configuration point and feeding these designated
nodes the configuration items through a single-threaded work queue all
just to avoid the races that didn't exist using just corosync+pacemaker.

Cheers,
b.

signature.asc
Description: This is a digitally signed message part
___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

44 matches

Mail list logo