[Pacemaker] Getting Started
Andrew Martin
amartin at xes-inc.com
Wed Dec 5 10:17:11 EST 2012
Brett,
The ocf:heartbeat:pingd resource agent is used to monitor network availability. This resource agent
is actually deprecated - the recommended replacement is ocf:pacemaker:pingd.
You can use ocf:pacemaker:pingd with a location constraint to move resources away from a node if it
loses network connectivity. For example, to move the group of resources g_resources away from a node
that loses network connectivity:
primitive p_ping ocf:pacemaker:ping \
params name="p_ping" host_list="192.168.0.11 192.168.0.12" dampen="10s" multiplier="10" \
op start interval="0" timeout="60" \
op monitor interval="10s" timeout="60"
clone cl_ping p_ping \
meta interleave="true"
location loc_run_on_most_connected g_resources \
rule $id="loc_run_on_most_connected-rule" -inf: not_defined p_ping or p_ping lte 0
This location constraint will migrate resources away from a node which can't ping any of the hosts defined in p_ping.
Andrew
----- Original Message -----
> From: "Brett Maton" <brett.maton at googlemail.com>
> To: "The Pacemaker cluster resource manager" <pacemaker at oss.clusterlabs.org>
> Sent: Tuesday, December 4, 2012 5:56:12 AM
> Subject: Re: [Pacemaker] Getting Started
>
> The group master-group has me a bit stumped as I'm not using a VIP
> for replication:
>
> group master-group \
> vip-master \
> vip-rep \
> meta \
> ordered="false"
>
> I'm guessing that I don't need to define the group as it would
> effectively only contain the master VIP?
> Therefore the colocation rule "2" should directly reference
> vip-master:
>
> colocation rsc_colocation-2 inf: vip-master msPostgresql:Master
>
> And the order rules the same:
> order rsc_order-1 0: clnPingCheck msPostgresql
> order rsc_order-2 0: msPostgresql:promote vip-master:start
> symmetrical=false
> order rsc_order-3 0: msPostgresql:demote vip-master:stop
> symmetrical=false
>
> Now ignorance time :)
>
> What's the point of pinging the gateway or am really just being daft
> (I had to change pacemaker to heartbeat here)?
>
> primitive pingCheck ocf:heartbeat:pingd \
> params \
> name="default_ping_set" \
> host_list="192.168.0.254" \
> multiplier="100" \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="10s" on-fail="restart" \
> op stop timeout="60s" interval="0s" on-fail="ignore"
>
> Thanks for your patience,
> Brett
>
> -----Original Message-----
> From: Takatoshi MATSUO [mailto:matsuo.tak at gmail.com]
> Sent: 04 December 2012 00:25
> To: The Pacemaker cluster resource manager
> Subject: Re: [Pacemaker] Getting Started
>
> Hi Brett
>
> Did you see my sample configuration?
> https://github.com/t-matsuo/resource-agents/wiki/Resource-Agent-for-PostgreSQL-9.1-streaming-replication
>
> 2012/12/4 Brett Maton <brett.maton at googlemail.com>:
> >
> > On 3 Dec 2012, at 15:01, Florian Crouzat wrote:
> >
> >> Le 03/12/2012 15:24, Brett Maton a écrit :
> >>> Hi List,
> >>>
> >>> I'm new to corosync / pacemaker so please forgive my ignorance!
> >>>
> >>> I currently have Postgres streaming replication between
> >>> node1(master) and node2(slave, hot standby), the replication
> >>> user authenticates to master using an md5 password.
> >>> All good there...
> >>>
> >>> My goal use pacemaker / heartbeat to move VIP and promote node2
> >>> if node1 fails, without using drdb or pg-pool.
> >>>
> >>> What I'm having trouble with is finding resources for learning
> >>> what I need to configure with regards to corosync / pacemaker
> >>> to implement failover. All of the guides I've found use DRDB
> >>> and/or a much more robust network configuration.
> >>>
> >>> I'm currently using CentOS 6.3 with PostgreSQL 9.2
> >>>
> >>> corosync-1.4.1-7.el6_3.1.x86_64
> >>> pacemaker-1.1.7-6.el6.x86_64
> >>>
> >>> node1 192.168.0.1
> >>> node2 192.168.0.2
> >>> dbVIP 192.168.0.101
> >>>
> >>> Any help and suggested reading appreciated.
> >>>
> >>> Thanks in advance,
> >>> Brett
> >>>
> >>
> >> Well, if you don't need shared storage and only a VIP over which
> >> postgres runs, I guess the official guide should be good:
> >> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/html-single/Clus
> >> ters_from_Scratch/
> >>
> >> Forget the drdb stuff, and base your configuration on the httpd
> >> examples that collocates a VIP and an httpd daemon in an
> >> active/passive two nodes cluster. (Chapter 6).
> >>
> >>
> >> --
> >> Cheers,
> >> Florian Crouzat
> >
> > Thanks for the answers, I'll try again using crm / cman. I've
> > found a pgsql agent patched by Takatoshi Matsuo which should work
> > if I can figure out the configuration!
> >
> > Part of the problem I think is that PostgreSQL streaming
> > replication is kind of active / active insofar as the slave is up
> > and listening (and receiving updates from the master) in read only
> > mode.
> >
> > The default agent from the CentOS repositories kills the slave if
> > the
> > master is up, which means that replication doesn't happen as there
> > is
> > no slave to receive updates :)
> >
> > Thanks,
> > Brett
> >
> >
> > _______________________________________________
> > Pacemaker mailing list: Pacemaker at 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 at 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 at 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
>
More information about the Pacemaker
mailing list