date:20151109

Re: [ClusterLabs] பதில்: Re: crm_mon memory leak

2015-11-09 Thread Karthikeyan Ramasamy

Hi Ken,
  The script now exits properly with 'exit 0'.  But it still it creates hanging 
processes, as listed below.

root 13405 1  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 13566 13405  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 13623 13566  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 13758 13566  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 13784 13623  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14146 13566  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14167 13623  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14193 13784  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14284 13758  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14381 13784  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14469 14284  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14589 13405  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14837 14381  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14860 13566  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 14977 14589  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 19816 14167  0 13:43 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html
root 19845 19816  0 13:43 ?00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
/opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
/tmp/ClusterMon_SNMP_10.64.109.36.html

From the above it looks that one crm_mon spawns another crm_mon processes and 
keeps building.

Can you please let us know if there is anything else we have to check or still 
there could be issues with the script?

Thanks,
Karthik.

-Original Message-
From: Ken Gaillot [mailto:kgail...@redhat.com] 
Sent: 02 நவம்பர் 2015 21:21
To: Karthikeyan Ramasamy; users@clusterlabs.org
Subject: Re: பதில்: Re: [ClusterLabs] crm_mon memory leak

On 11/02/2015 09:39 AM, Karthikeyan Ramasamy wrote:
> Yes, Ken.  There were multiple instances of the external script also running. 
>  What do you think could possibly be wrong with the script that triggers the 
> crm_mon process everytime?

It's the other way around, crm_mon spawns the script. So if the script doesn't 
exit properly, neither will crm_mon.

Easy test: put an "exit" at the top of your script. If the problem goes away, 
then it's in the script somewhere. Mostly you want to make sure the script 
completes within your monitoring interval.

> We are on RHEL 6.5.  I am not sure what's the plan for RHEL 6.7 and 7.1.  
> 
> Thanks,
> Karthik.
> 
> -Original Message-
> From: Ken Gaillot [mailto:kgail...@redhat.com]
> Sent: 02 நவம்பர் 2015 21:04
> To: Karthikeyan Ramasamy; users@clusterlabs.org
> Subject: Re: பதில்: Re:

[ClusterLabs] required nodes for quorum policy

2015-11-09 Thread Radoslaw Garbacz

Hi,

I have a question regarding the policy to check for cluster quorum for
corosync+pacemaker.

As far as I know at present it is always (excpected_votes)/2 + 1. Seems
like "qdiskd" has an option to change it, but it is not clear to me if
corosync 2.x supports different quorum device.

What are my options if I wanted to configure cluster with a different
quorum policy (compilation options are acceptable)?

Thanks in advance,

-- 
Best Regards,

Radoslaw Garbacz
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

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

Re: [ClusterLabs] பதில்: Re: crm_mon memory leak

2015-11-09 Thread Ken Gaillot

On 11/09/2015 07:11 AM, Karthikeyan Ramasamy wrote:
> Hi Ken,
>   The script now exits properly with 'exit 0'.  But it still it creates 
> hanging processes, as listed below.
> 
> root 13405 1  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 13566 13405  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 13623 13566  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 13758 13566  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 13784 13623  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14146 13566  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14167 13623  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14193 13784  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14284 13758  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14381 13784  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14469 14284  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14589 13405  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14837 14381  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14860 13566  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 14977 14589  0 13:42 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 19816 14167  0 13:43 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> root 19845 19816  0 13:43 ?00:00:00 /usr/sbin/crm_mon -p 
> /tmp/ClusterMon_SNMP_10.64.109.36.pid -d -i 15 -E 
> /opt/occ/CXP_902_0588_R13B2370/tools/PCSESA.sh -h 
> /tmp/ClusterMon_SNMP_10.64.109.36.html
> 
> From the above it looks that one crm_mon spawns another crm_mon processes and 
> keeps building.
> 
> Can you please let us know if there is anything else we have to check or 
> still there could be issues with the script?
> 
> Thanks,
> Karthik.

That's odd. The ClusterMon resource should spawn crm_mon only once, when
it starts. Does the cluster report any failures for the ClusterMon resource?

I doubt it is the issue in this case, but ClusterMon resources should
not be cloned or duplicated, because it does not monitor the health of
one node but of the entire cluster.

> -Original Message-
> From: Ken Gaillot [mailto:kgail...@redhat.com] 
> Sent: 02 நவம்பர் 2015 21:21
> To: Karthikeyan Ramasamy; users@clusterlabs.org
> Subject: Re: பதில்: Re: [ClusterLabs] crm_mon memory leak
> 
> On 11/02/2015 09:39 AM, Karthikeyan Ramasamy wrote:
>> Yes, Ken.  There were multiple instances of the external script also 
>> running.  What do you think could possibly be wrong with the script that 
>> triggers the crm_mon process everytime?
> 
> It's the other way around, crm_mon spawns

Re: [ClusterLabs] Loadbalancing using Pacemaker

2015-11-09 Thread Ken Gaillot

On 11/08/2015 11:29 AM, didier tanti wrote:
> Thank You Michael,
> In fact I spent some more time looking at documentions and indeed Pacemaker 
> is only used for resource control and management. To have my HA solution I 
> will need to use Corosync directly as well. The OpenAIS API is pretty well 
> described and I am starting to understand what must be done (basically link 
> my binaries with corosync and use the messages and other APIs to have a 
> accurate states of remote objects/services). 
> As for the Virtual IP I believe it makes more sense to use it in case of 
> Active/Standby services. In my case B services being both active i would need 
> to implement the load balancing within service A (using openAIS/Corosync API 
> to be updated of service B state changes and how to reach the service B I 
> have elected through round robin). For those specific components I don't 
> foreseen the need of Virtual IP. However I may use VIP for my service A and 
> other components!

Hi,

You may also want to look at Pacemaker's notification capability to call
an external script for node/resource changes. The latest upstream code
(which will be part of 1.1.14) has some new built-in notification
functionality, which is event-driven.

For prior versions, you can use the ClusterMon resource with -E in the
extra_options to achieve the same effect, but that is polling at regular
intervals rather than truly event-driven:
http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm231308442928

> Thanks, 
> 
> 
>  Le Dimanche 8 novembre 2015 16h24, Michael Schwartzkopff  
> a écrit :
>
> 
>  Am Samstag, 7. November 2015, 09:40:47 schrieb didier tanti:
>> Hello, i am new to Pacemaker and have a question concerning how to have my
>> cluster services aware of the state and location of the other services in
>> the cluster.  Example:
>> Service A is running on Host XService B1 is running on Host XService B2 is
>> running on Host Y Which API would allow my Service A to send IPC messages
>> to services B1 and B2 in a round robin manner?(for example how Service A
>> would be aware of which B is up and active (B1, B2 or both), and how A
>> would even be able to know on which host B1 or B2 is running?) It looks
>> very basic but i cannot find information on this on clusterlabs.org Is
>> there basic tutorial that would explain how to achieve this ? (I guess i
>> would need to link my service binaries with some pacemaker /corosync libs
>> and use some API ?) Thanks for helping out,
> 
> Hi,
> 
> this task is beyond the ability of pacemaker. Your application has to know 
> how 
> to handle that.
> 
> Best solution would be to use virtual IP addresses for services B1 and B2. 
> make sure that the IP addresses run together with the services. Now you 
> service A only has to talk to the IP addresses, no matter on which host they 
> run.
> 
> pacemaker could take care that they run on different hosts is possible.
> 
> Mit freundlichen Grüßen,
> 
> Michael Schwartzkopff


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

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

Re: [ClusterLabs] move service basing on both connection status and hostname

2015-11-09 Thread Ken Gaillot

On 11/09/2015 10:02 AM, Stefano Sasso wrote:
> Hi Guys,
>   I am having some troubles with the location constraint.
> 
> In particular, what I want to achieve, is to run my service on a host; if
> the ip interconnection fails I want to migrate it to another host, but on
> IP connectivity restoration the resource should move again on the primary
> node.
> 
> So, I have this configuration:
> 
> primitive vfy_ether ocf:pacemaker:l2check \
>> params nic_list="eth1 eth2" debug="false" dampen="1s" \
>> op monitor interval="2s"
>> clone ck_ether vfy_ether
>> location cli-ethercheck MCluster \
>> rule $id="cli-prefer-rule-ethercheck" -inf: not_defined l2ckd or
>> l2ckd lt 2
>> location cli-prefer-masterIP MCluster \
>> rule $id="cli-prefer-rule-masterIP" 50: #uname eq GHA-MO-1
> 
> 
> when the connectivity fails on the primary node, the resource is correctly
> moved to the secondary one.
> But, on IP connectivity restoration, the resource stays on the secondary
> node (and does not move to the primary one).
> 
> How can I solve that?
> Any hint? :-)
> 
> thanks,
>   stefano

Mostly likely, you have a default resource-stickiness set. That tells
Pacemaker to keep services where they are if possible. You can either
delete the stickiness setting or make sure it has a lower score than
your location preference.

Alternatively, are you sure l2ckd is <2 after connectivity is restored?

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

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

Re: [ClusterLabs] move service basing on both connection status and hostname

2015-11-09 Thread Stefano Sasso

Hi Ken,
  thanks for your reply.

the problem was the resource-stickiness. thank you very much!

bests
stefano



2015-11-09 17:27 GMT+01:00 Ken Gaillot :

> On 11/09/2015 10:02 AM, Stefano Sasso wrote:
> > Hi Guys,
> >   I am having some troubles with the location constraint.
> >
> > In particular, what I want to achieve, is to run my service on a host; if
> > the ip interconnection fails I want to migrate it to another host, but on
> > IP connectivity restoration the resource should move again on the primary
> > node.
> >
> > So, I have this configuration:
> >
> > primitive vfy_ether ocf:pacemaker:l2check \
> >> params nic_list="eth1 eth2" debug="false" dampen="1s" \
> >> op monitor interval="2s"
> >> clone ck_ether vfy_ether
> >> location cli-ethercheck MCluster \
> >> rule $id="cli-prefer-rule-ethercheck" -inf: not_defined l2ckd or
> >> l2ckd lt 2
> >> location cli-prefer-masterIP MCluster \
> >> rule $id="cli-prefer-rule-masterIP" 50: #uname eq GHA-MO-1
> >
> >
> > when the connectivity fails on the primary node, the resource is
> correctly
> > moved to the secondary one.
> > But, on IP connectivity restoration, the resource stays on the secondary
> > node (and does not move to the primary one).
> >
> > How can I solve that?
> > Any hint? :-)
> >
> > thanks,
> >   stefano
>
> Mostly likely, you have a default resource-stickiness set. That tells
> Pacemaker to keep services where they are if possible. You can either
> delete the stickiness setting or make sure it has a lower score than
> your location preference.
>
> Alternatively, are you sure l2ckd is <2 after connectivity is restored?
>
> ___
> Users mailing list: Users@clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>



-- 
Stefano Sasso
http://stefano.dscnet.org/
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

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

Re: [ClusterLabs] required nodes for quorum policy

2015-11-09 Thread Andrei Borzenkov

On Tue, Nov 10, 2015 at 1:20 AM, Radoslaw Garbacz
 wrote:
> Hi,
>
> I have a question regarding the policy to check for cluster quorum for
> corosync+pacemaker.
>
> As far as I know at present it is always (excpected_votes)/2 + 1. Seems like
> "qdiskd" has an option to change it, but it is not clear to me if corosync
> 2.x supports different quorum device.
>
> What are my options if I wanted to configure cluster with a different quorum
> policy (compilation options are acceptable)?
>

If I understand the question correctly and you want cluster to
continue even when less than majority nodes are left - I would say pn
pacemaker level you could simply set no-quorum-policy=ignore and rely
on fencing for resource migration and on corosync 2.x level you could
set last_man_standing so corosync re-evaluates majority every time
nodes come and go (may be with combination with auto_tie_breaker).

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

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

Re: [ClusterLabs] Howto use ocf:heartbeat:nginx check level > 0

2015-11-09 Thread Ken Gaillot

On 11/08/2015 04:46 AM, user.clusterlabs@siimnet.dk wrote:
> 
>> On 8. nov. 2015, at 10.26, user.clusterlabs@siimnet.dk wrote:
>>
>> Setting up my first pacemaker cluster, I’m trying to grasp howto make 
>> ocf:heartbeat:nginx monitor with check levels > 0.
>>
>> Got this so far:
>>
>> [root@afnA ~]# pcs resource
>>  Resource Group: afnGroup
>>  afnVIP (ocf::heartbeat:IPaddr2):   Started afnA 
>>  afnNGinx   (ocf::heartbeat:nginx): Started afnA 
>>
>> [root@afnA ~]# pcs resource show afnNGinx
>>  Resource: afnNGinx (class=ocf provider=heartbeat type=nginx)
>>   Attributes: configfile=/opt/imail/nginx/conf/nginx.conf port=8080 
>> httpd=/opt/imail/nginx/sbin/nginx options="-p /opt/imail/nginx" 
>> status10url=/ping status10regex=".+ is alive\." 
>>   Operations: start interval=0s timeout=60s (afnNGinx-start-interval-0s)
>>   stop interval=0s timeout=60s (afnNGinx-stop-interval-0s)
>>   monitor interval=10s timeout=20s 
>> (afnNGinx-monitor-interval-10s)
>>   monitor interval=60s timeout=20s 
>> (afnNGinx-monitor-interval-60s)
>> [root@afnA ~]# 
>>
>> but I cant verify that pacemaker RA ever calls http://localhost:8080/ping 
>> , why not?
>>
>> Any pointers to info source(s) for better understanding RA configuration and 
>> maybe specially check levels?
> 
> Found this: 
> http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-operation-monitor-multiple.html
>  
> 
> 
> This seemed to work much better:
> 
> [root@afnA ~]# pcs resource show afnNGinx
>  Resource: afnNGinx (class=ocf provider=heartbeat type=nginx)
>   Attributes: configfile=/opt/imail/nginx/conf/nginx.conf port=8080 
> httpd=/opt/imail/nginx/sbin/nginx options="-p /opt/imail/nginx" 
> status10url=http://localhost:8080/ping status10regex="mss[0-9] is alive\." 
>   Meta Attrs: target-role=Started 
>   Operations: start interval=0s timeout=60s (afnNGinx-start-interval-0s)
>   stop interval=0s timeout=60s (afnNGinx-stop-interval-0s)
>   monitor interval=10s timeout=10s (afnNGinx-monitor-interval-10s)
>   monitor interval=120s timeout=30s OCF_CHECK_LEVEL=10 
> (afnNGinx-monitor-interval-120s)
> 
> =>
> 
> 127.0.0.1 - - [08/Nov/2015:11:34:25 +0100] "GET /ping HTTP/1.1" 200 16 "-" 
> "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC 
> zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
> 127.0.0.1 - - [08/Nov/2015:11:36:25 +0100] "GET /ping HTTP/1.1" 200 16 "-" 
> "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC 
> zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
> 127.0.0.1 - - [08/Nov/2015:11:38:25 +0100] "GET /ping HTTP/1.1" 200 16 "-" 
> "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC 
> zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
> 127.0.0.1 - - [08/Nov/2015:11:40:25 +0100] "GET /ping HTTP/1.1" 200 16 "-" 
> "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC 
> zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
> 
> 
> [root@afnA]# pcs --version
> 0.9.139
> 
> https://www.mankier.com/8/pcs  seems to 
> indicate a debug-monitor command only my pcs version doesn’t seem to support 
> this, might it only be in a later version, also I can seem to find ocf-tester 
> from CentOS 6 repository, where might I find ocf-tester rpm?
> 
> /Steffen

Support for debug-monitor was added to pcs upstream in June of this
year; not sure what version that corresponds to.

ocf-tester is part of the upstream resource-agents package
(https://github.com/ClusterLabs/resource-agents). As I understand it, it
is not included in the RHEL/CentOS releases because it has SuSE-specific
code. It could be made more portable but it's not a high priority.
Patches welcome of course :)


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

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

Re: [ClusterLabs] பதில்: Re: crm_mon memory leak

[ClusterLabs] required nodes for quorum policy

Re: [ClusterLabs] பதில்: Re: crm_mon memory leak

Re: [ClusterLabs] Loadbalancing using Pacemaker

Re: [ClusterLabs] move service basing on both connection status and hostname

Re: [ClusterLabs] move service basing on both connection status and hostname

Re: [ClusterLabs] required nodes for quorum policy

Re: [ClusterLabs] Howto use ocf:heartbeat:nginx check level > 0

8 matches

Site Navigation

Mail list logo

Footer information