Mailing List Archive: Linux-HA: Pacemaker

Pacemaker 0.7.3: How to use pingd clone resource and constraints

Index | Next | Previous | View Threaded

Bruno.Voigt at ic3s

Sep 24, 2008, 1:04 PM

Post #1 of 13 (1798 views)
Permalink

Pacemaker 0.7.3: How to use pingd clone resource and constraints

I defined two ping clone resources,
to be used independently by different resources:

<clone id="clone-pingd-internal">
<primitive id="pingd-internal" provider="pacemaker" class="ocf"
type="pingd">
<instance_attributes id="pingd-internal-ia">
<nvpair id="pingd-internal-ia01" name="name"
value="pingd-internal"/>
<nvpair id="pingd-internal-ia02" name="dampen" value="5s"/>
<nvpair id="pingd-internal-ia03" name="multiplier"
value="1000"/>
<nvpair id="pingd-internal-ia04" name="host_list"
value="172.17.32.23 192.168.132.23"/>
</instance_attributes>
</primitive>
</clone>

<clone id="clone-pingd-external">
<primitive id="pingd-external" provider="pacemaker" class="ocf"
type="pingd">
<instance_attributes id="pingd-external-ia">
<nvpair id="pingd-external-ia01" name="name"
value="pingd-external"/>
<nvpair id="pingd-external-ia02" name="dampen" value="5s"/>
<nvpair id="pingd-external-ia03" name="multiplier"
value="1000"/>
<nvpair id="pingd-external-ia04" name="host_list"
value="195.244.97.241"/>
</instance_attributes>
</primitive>
</clone>

I defined a constraint for a resource so that it depends on pingd-internal

<constraints>
<rsc_location id="hbtest1b-connectivity" rsc="hbtest1b">
<rule id="hbtest1b-connectivity-exclude-rule" score="-INFINITY" >
<expression id="hbtest1b-connectivity-exclude"
attribute="pingd-internal" operation="not_defined"/>
</rule>
</rsc_location>
</constraints>

But this causes the resource to be unrunnable on either of my both nodes,

There are as expected 2 pingd daemons running:

root 6132 1 0 21:07 ? 00:00:00 /usr/lib/heartbeat/pingd
-D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a pingd-internal
-d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
root 13142 1 0 21:47 ? 00:00:00 /usr/lib/heartbeat/pingd
-D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a pingd-external
-d 5s -m 1000 -h 195.244.97.241

The problem is, I can't see in the cibadmin -Q output that the pingd
daemons have
have stored their results anywhere..

In the log I see the following output:

Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo (0):
3, code=1, seq=0, id=0, check=24031
Sep 24 22:01:47 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo (0):
3, code=1, seq=0, id=0, check=24031
Sep 24 22:01:48 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo (0):
8, code=0, seq=261, id=0, check=22762
Sep 24 22:01:48 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
8, code=0, seq=263, id=0, check=22250
Sep 24 22:01:50 xen20a pingd: [13142]: info: stand_alone_ping: Node
195.244.97.241 is alive (1)
Sep 24 22:01:50 xen20a pingd: [13142]: info: send_update: 1 active ping
nodes
Sep 24 22:01:51 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
3, code=1, seq=0, id=0, check=24031
Sep 24 22:01:52 xen20a pingd: [6132]: info: stand_alone_ping: Node
172.17.32.23 is alive (3)
Sep 24 22:01:53 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
3, code=1, seq=0, id=0, check=24031
Sep 24 22:01:54 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
3, code=1, seq=0, id=0, check=25823
Sep 24 22:01:55 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
3, code=1, seq=0, id=0, check=24031
Sep 24 22:01:57 xen20a pingd: [6132]: info: stand_alone_ping: Node
192.168.132.23 is alive (2)
Sep 24 22:01:57 xen20a pingd: [6132]: info: send_update: 2 active ping nodes

Where should the current pingd status be located in the cib ?
What is wrong with my setup ?

TIA,
Bruno

Attachments:

signature.asc (0.19 KB)

sergeyfd at gmail

Sep 24, 2008, 1:36 PM

Post #2 of 13 (1559 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

There is a problem with attrd that affects pingd in Pacemeaker
0.7.3/Heartbeat 2.99. I've already created a Bugzilla ticket for it.
You can add your information there:

http://developerbugs.linux-foundation.org/show_bug.cgi?id=1969

On Wed, Sep 24, 2008 at 2:04 PM, Bruno Voigt <Bruno.Voigt[at]ic3s.de> wrote:
> I defined two ping clone resources,
> to be used independently by different resources:
>
> <clone id="clone-pingd-internal">
> <primitive id="pingd-internal" provider="pacemaker" class="ocf"
> type="pingd">
> <instance_attributes id="pingd-internal-ia">
> <nvpair id="pingd-internal-ia01" name="name"
> value="pingd-internal"/>
> <nvpair id="pingd-internal-ia02" name="dampen" value="5s"/>
> <nvpair id="pingd-internal-ia03" name="multiplier"
> value="1000"/>
> <nvpair id="pingd-internal-ia04" name="host_list"
> value="172.17.32.23 192.168.132.23"/>
> </instance_attributes>
> </primitive>
> </clone>
>
> <clone id="clone-pingd-external">
> <primitive id="pingd-external" provider="pacemaker" class="ocf"
> type="pingd">
> <instance_attributes id="pingd-external-ia">
> <nvpair id="pingd-external-ia01" name="name"
> value="pingd-external"/>
> <nvpair id="pingd-external-ia02" name="dampen" value="5s"/>
> <nvpair id="pingd-external-ia03" name="multiplier"
> value="1000"/>
> <nvpair id="pingd-external-ia04" name="host_list"
> value="195.244.97.241"/>
> </instance_attributes>
> </primitive>
> </clone>
>
> I defined a constraint for a resource so that it depends on pingd-internal
>
> <constraints>
> <rsc_location id="hbtest1b-connectivity" rsc="hbtest1b">
> <rule id="hbtest1b-connectivity-exclude-rule" score="-INFINITY" >
> <expression id="hbtest1b-connectivity-exclude"
> attribute="pingd-internal" operation="not_defined"/>
> </rule>
> </rsc_location>
> </constraints>
>
> But this causes the resource to be unrunnable on either of my both nodes,
>
>
> There are as expected 2 pingd daemons running:
>
> root 6132 1 0 21:07 ? 00:00:00 /usr/lib/heartbeat/pingd
> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a pingd-internal
> -d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
> root 13142 1 0 21:47 ? 00:00:00 /usr/lib/heartbeat/pingd
> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a pingd-external
> -d 5s -m 1000 -h 195.244.97.241
>
> The problem is, I can't see in the cibadmin -Q output that the pingd
> daemons have
> have stored their results anywhere..
>
> In the log I see the following output:
>
> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:47 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:48 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo (0):
> 8, code=0, seq=261, id=0, check=22762
> Sep 24 22:01:48 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 8, code=0, seq=263, id=0, check=22250
> Sep 24 22:01:50 xen20a pingd: [13142]: info: stand_alone_ping: Node
> 195.244.97.241 is alive (1)
> Sep 24 22:01:50 xen20a pingd: [13142]: info: send_update: 1 active ping
> nodes
> Sep 24 22:01:51 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:52 xen20a pingd: [6132]: info: stand_alone_ping: Node
> 172.17.32.23 is alive (3)
> Sep 24 22:01:53 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:54 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=25823
> Sep 24 22:01:55 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:57 xen20a pingd: [6132]: info: stand_alone_ping: Node
> 192.168.132.23 is alive (2)
> Sep 24 22:01:57 xen20a pingd: [6132]: info: send_update: 2 active ping nodes
>
> Where should the current pingd status be located in the cib ?
> What is wrong with my setup ?
>
> TIA,
> Bruno
>
>
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker[at]clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>
>

--
Serge Dubrouski.

_______________________________________________
Pacemaker mailing list
Pacemaker[at]clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker

beekhof at gmail

Sep 25, 2008, 3:24 AM

Post #3 of 13 (1533 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

On Sep 24, 2008, at 10:36 PM, Serge Dubrouski wrote:

> There is a problem with attrd that affects pingd in Pacemeaker
> 0.7.3/Heartbeat 2.99. I've already created a Bugzilla ticket for it.
> You can add your information there:
>
> http://developerbugs.linux-foundation.org/show_bug.cgi?id=1969

I'm not so sure this is the same thing.
Those "Bad echo" messages look suspicious

>> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 3, code=1, seq=0, id=0, check=24031

In fact, type=3 is ICMP_DEST_UNREACH - so pingd really is having
trouble contacting that host.

>
>
> On Wed, Sep 24, 2008 at 2:04 PM, Bruno Voigt <Bruno.Voigt[at]ic3s.de>
> wrote:
>> I defined two ping clone resources,
>> to be used independently by different resources:
>>
>> <clone id="clone-pingd-internal">
>> <primitive id="pingd-internal" provider="pacemaker" class="ocf"
>> type="pingd">
>> <instance_attributes id="pingd-internal-ia">
>> <nvpair id="pingd-internal-ia01" name="name"
>> value="pingd-internal"/>
>> <nvpair id="pingd-internal-ia02" name="dampen" value="5s"/>
>> <nvpair id="pingd-internal-ia03" name="multiplier"
>> value="1000"/>
>> <nvpair id="pingd-internal-ia04" name="host_list"
>> value="172.17.32.23 192.168.132.23"/>
>> </instance_attributes>
>> </primitive>
>> </clone>
>>
>> <clone id="clone-pingd-external">
>> <primitive id="pingd-external" provider="pacemaker" class="ocf"
>> type="pingd">
>> <instance_attributes id="pingd-external-ia">
>> <nvpair id="pingd-external-ia01" name="name"
>> value="pingd-external"/>
>> <nvpair id="pingd-external-ia02" name="dampen" value="5s"/>
>> <nvpair id="pingd-external-ia03" name="multiplier"
>> value="1000"/>
>> <nvpair id="pingd-external-ia04" name="host_list"
>> value="195.244.97.241"/>
>> </instance_attributes>
>> </primitive>
>> </clone>
>>
>> I defined a constraint for a resource so that it depends on pingd-
>> internal
>>
>> <constraints>
>> <rsc_location id="hbtest1b-connectivity" rsc="hbtest1b">
>> <rule id="hbtest1b-connectivity-exclude-rule" score="-INFINITY" >
>> <expression id="hbtest1b-connectivity-exclude"
>> attribute="pingd-internal" operation="not_defined"/>
>> </rule>
>> </rsc_location>
>> </constraints>
>>
>> But this causes the resource to be unrunnable on either of my both
>> nodes,
>>
>>
>> There are as expected 2 pingd daemons running:
>>
>> root 6132 1 0 21:07 ? 00:00:00 /usr/lib/heartbeat/
>> pingd
>> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a pingd-
>> internal
>> -d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
>> root 13142 1 0 21:47 ? 00:00:00 /usr/lib/heartbeat/
>> pingd
>> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a pingd-
>> external
>> -d 5s -m 1000 -h 195.244.97.241
>>
>> The problem is, I can't see in the cibadmin -Q output that the pingd
>> daemons have
>> have stored their results anywhere..
>>
>> In the log I see the following output:
>>
>> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 3, code=1, seq=0, id=0, check=24031
>> Sep 24 22:01:47 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 3, code=1, seq=0, id=0, check=24031
>> Sep 24 22:01:48 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 8, code=0, seq=261, id=0, check=22762
>> Sep 24 22:01:48 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 8, code=0, seq=263, id=0, check=22250
>> Sep 24 22:01:50 xen20a pingd: [13142]: info: stand_alone_ping: Node
>> 195.244.97.241 is alive (1)
>> Sep 24 22:01:50 xen20a pingd: [13142]: info: send_update: 1 active
>> ping
>> nodes
>> Sep 24 22:01:51 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 3, code=1, seq=0, id=0, check=24031
>> Sep 24 22:01:52 xen20a pingd: [6132]: info: stand_alone_ping: Node
>> 172.17.32.23 is alive (3)
>> Sep 24 22:01:53 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 3, code=1, seq=0, id=0, check=24031
>> Sep 24 22:01:54 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 3, code=1, seq=0, id=0, check=25823
>> Sep 24 22:01:55 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo
>> (0):
>> 3, code=1, seq=0, id=0, check=24031
>> Sep 24 22:01:57 xen20a pingd: [6132]: info: stand_alone_ping: Node
>> 192.168.132.23 is alive (2)
>> Sep 24 22:01:57 xen20a pingd: [6132]: info: send_update: 2 active
>> ping nodes
>>
>> Where should the current pingd status be located in the cib ?
>> What is wrong with my setup ?
>>
>> TIA,
>> Bruno
>>
>>
>>
>> _______________________________________________
>> Pacemaker mailing list
>> Pacemaker[at]clusterlabs.org
>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>>
>>
>
>
>
> --
> Serge Dubrouski.
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker[at]clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker

_______________________________________________
Pacemaker mailing list
Pacemaker[at]clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker

Bruno.Voigt at ic3s

Sep 25, 2008, 12:19 PM

Post #4 of 13 (1533 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

Hi Andrew,

is pingd doing alive tests differently compared to the normal ping command?
normal & flood ping of these hosts show 0% packet lost from my both nodes.

In the log below pingd - besides the warnings -
states that the node is alive and that it had sent an update,
but it does not show up in the cib.

WR,
Bruno

Andrew Beekhof wrote:
>
> On Sep 24, 2008, at 10:36 PM, Serge Dubrouski wrote:
>
>> There is a problem with attrd that affects pingd in Pacemeaker
>> 0.7.3/Heartbeat 2.99. I've already created a Bugzilla ticket for it.
>> You can add your information there:
>>
>> http://developerbugs.linux-foundation.org/show_bug.cgi?id=1969
>
> I'm not so sure this is the same thing.
> Those "Bad echo" messages look suspicious
>
>>> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>>> (0):
>>> 3, code=1, seq=0, id=0, check=24031
>
> In fact, type=3 is ICMP_DEST_UNREACH - so pingd really is having
> trouble contacting that host.
>
>
>>
>>
>> On Wed, Sep 24, 2008 at 2:04 PM, Bruno Voigt <Bruno.Voigt[at]ic3s.de>
>> wrote:
>>> I defined two ping clone resources,
>>> to be used independently by different resources:
>>>
>>> <clone id="clone-pingd-internal">
>>> <primitive id="pingd-internal" provider="pacemaker" class="ocf"
>>> type="pingd">
>>> <instance_attributes id="pingd-internal-ia">
>>> <nvpair id="pingd-internal-ia01" name="name"
>>> value="pingd-internal"/>
>>> <nvpair id="pingd-internal-ia02" name="dampen" value="5s"/>
>>> <nvpair id="pingd-internal-ia03" name="multiplier"
>>> value="1000"/>
>>> <nvpair id="pingd-internal-ia04" name="host_list"
>>> value="172.17.32.23 192.168.132.23"/>
>>> </instance_attributes>
>>> </primitive>
>>> </clone>
>>>
>>> <clone id="clone-pingd-external">
>>> <primitive id="pingd-external" provider="pacemaker" class="ocf"
>>> type="pingd">
>>> <instance_attributes id="pingd-external-ia">
>>> <nvpair id="pingd-external-ia01" name="name"
>>> value="pingd-external"/>
>>> <nvpair id="pingd-external-ia02" name="dampen" value="5s"/>
>>> <nvpair id="pingd-external-ia03" name="multiplier"
>>> value="1000"/>
>>> <nvpair id="pingd-external-ia04" name="host_list"
>>> value="195.244.97.241"/>
>>> </instance_attributes>
>>> </primitive>
>>> </clone>
>>>
>>> I defined a constraint for a resource so that it depends on
>>> pingd-internal
>>>
>>> <constraints>
>>> <rsc_location id="hbtest1b-connectivity" rsc="hbtest1b">
>>> <rule id="hbtest1b-connectivity-exclude-rule" score="-INFINITY" >
>>> <expression id="hbtest1b-connectivity-exclude"
>>> attribute="pingd-internal" operation="not_defined"/>
>>> </rule>
>>> </rsc_location>
>>> </constraints>
>>>
>>> But this causes the resource to be unrunnable on either of my both
>>> nodes,
>>>
>>>
>>> There are as expected 2 pingd daemons running:
>>>
>>> root 6132 1 0 21:07 ? 00:00:00
>>> /usr/lib/heartbeat/pingd
>>> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a
>>> pingd-internal
>>> -d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
>>> root 13142 1 0 21:47 ? 00:00:00
>>> /usr/lib/heartbeat/pingd
>>> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a
>>> pingd-external
>>> -d 5s -m 1000 -h 195.244.97.241
>>>
>>> The problem is, I can't see in the cibadmin -Q output that the pingd
>>> daemons have
>>> have stored their results anywhere..
>>>
>>> In the log I see the following output:
>>>
>>> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>>> (0):
>>> 3, code=1, seq=0, id=0, check=24031
>>> Sep 24 22:01:47 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>>> (0):
>>> 3, code=1, seq=0, id=0, check=24031
>>> Sep 24 22:01:48 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>>> (0):
>>> 8, code=0, seq=261, id=0, check=22762
>>> Sep 24 22:01:48 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>> 8, code=0, seq=263, id=0, check=22250
>>> Sep 24 22:01:50 xen20a pingd: [13142]: info: stand_alone_ping: Node
>>> 195.244.97.241 is alive (1)
>>> Sep 24 22:01:50 xen20a pingd: [13142]: info: send_update: 1 active ping
>>> nodes
>>> Sep 24 22:01:51 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>> 3, code=1, seq=0, id=0, check=24031
>>> Sep 24 22:01:52 xen20a pingd: [6132]: info: stand_alone_ping: Node
>>> 172.17.32.23 is alive (3)
>>> Sep 24 22:01:53 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>> 3, code=1, seq=0, id=0, check=24031
>>> Sep 24 22:01:54 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>> 3, code=1, seq=0, id=0, check=25823
>>> Sep 24 22:01:55 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>> 3, code=1, seq=0, id=0, check=24031
>>> Sep 24 22:01:57 xen20a pingd: [6132]: info: stand_alone_ping: Node
>>> 192.168.132.23 is alive (2)
>>> Sep 24 22:01:57 xen20a pingd: [6132]: info: send_update: 2 active
>>> ping nodes
>>>
>>> Where should the current pingd status be located in the cib ?
>>> What is wrong with my setup ?
>>>
>>> TIA,
>>> Bruno
>>>
>>
>> --
>> Serge Dubrouski.
>

Attachments:

signature.asc (0.19 KB)

Bruno.Voigt at ic3s

Sep 25, 2008, 12:33 PM

Post #5 of 13 (1521 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

Wow.. these warnings are even shown for 127.0.0.1 ?!
Do I need to finetune the IP stack options somewhere like in sysctl.conf
to have these warnings of pingd fixed?

root[at]xen20b:~# /usr/lib/heartbeat/pingd -V -a pingd-internal -d 5s -m
1000 -h 127.0.0.1
pingd[26741]: 2008/09/25_21:30:04 debug: main: Adding ping host 127.0.0.1
pingd[26741]: 2008/09/25_21:30:04 debug: main: attrd registration attempt: 0
pingd[26741]: 2008/09/25_21:30:09 debug:
init_client_ipc_comms_nodispatch: Attempting to talk on:
/var/run/heartbeat/crm/attrd
pingd[26741]: 2008/09/25_21:30:09 info: main: Starting pingd
pingd[26741]: 2008/09/25_21:30:19 debug: stand_alone_ping: Checking
connectivity
pingd[26741]: 2008/09/25_21:30:19 debug: ping_open: Got address
127.0.0.1 for 127.0.0.1
pingd[26741]: 2008/09/25_21:30:19 debug: ping_open: Opened connection to
127.0.0.1
pingd[26741]: 2008/09/25_21:30:19 debug: ping_write: Sent 39 bytes to
127.0.0.1
pingd[26741]: 2008/09/25_21:30:19 WARN: dump_v4_echo: Bad echo (0): 8,
code=0, seq=5, id=0, check=22763
pingd[26741]: 2008/09/25_21:30:20 debug: ping_write: Sent 39 bytes to
127.0.0.1
pingd[26741]: 2008/09/25_21:30:20 debug: dump_v4_echo: 59 bytes from
127.0.0.1, icmp_seq=5: beekhof-v4
pingd[26741]: 2008/09/25_21:30:21 debug: ping_write: Sent 39 bytes to
127.0.0.1
pingd[26741]: 2008/09/25_21:30:21 WARN: dump_v4_echo: Bad echo (0): 8,
code=0, seq=13138, id=0, check=3000
pingd[26741]: 2008/09/25_21:30:22 debug: ping_write: Sent 39 bytes to
127.0.0.1
pingd[26741]: 2008/09/25_21:30:22 debug: dump_v4_echo: 59 bytes from
10.10.10.167, icmp_seq=13138: beekhof-v4
pingd[26741]: 2008/09/25_21:30:23 debug: ping_write: Sent 39 bytes to
127.0.0.1
pingd[26741]: 2008/09/25_21:30:23 WARN: dump_v4_echo: Bad echo (0): 8,
code=0, seq=8284, id=0, check=459

root[at]xen20b:~# uname -a
Linux xen20b.bb.ic3s.de 2.6.18-6-xen-amd64 #1 SMP Tue Aug 19 06:15:09
UTC 2008 x86_64 GNU/Linux

Bruno Voigt wrote:
> Hi Andrew,
>
> is pingd doing alive tests differently compared to the normal ping command?
> normal & flood ping of these hosts show 0% packet lost from my both nodes.
>
> In the log below pingd - besides the warnings -
> states that the node is alive and that it had sent an update,
> but it does not show up in the cib.
>
> WR,
> Bruno
>
> Andrew Beekhof wrote:
>
>> On Sep 24, 2008, at 10:36 PM, Serge Dubrouski wrote:
>>
>>
>>> There is a problem with attrd that affects pingd in Pacemeaker
>>> 0.7.3/Heartbeat 2.99. I've already created a Bugzilla ticket for it.
>>> You can add your information there:
>>>
>>> http://developerbugs.linux-foundation.org/show_bug.cgi?id=1969
>>>
>> I'm not so sure this is the same thing.
>> Those "Bad echo" messages look suspicious
>>
>>
>>>> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>>>> (0):
>>>> 3, code=1, seq=0, id=0, check=24031
>>>>
>> In fact, type=3 is ICMP_DEST_UNREACH - so pingd really is having
>> trouble contacting that host.
>>
>>
>>
>>> On Wed, Sep 24, 2008 at 2:04 PM, Bruno Voigt <Bruno.Voigt[at]ic3s.de>
>>> wrote:
>>>
>>>> I defined two ping clone resources,
>>>> to be used independently by different resources:
>>>>
>>>> <clone id="clone-pingd-internal">
>>>> <primitive id="pingd-internal" provider="pacemaker" class="ocf"
>>>> type="pingd">
>>>> <instance_attributes id="pingd-internal-ia">
>>>> <nvpair id="pingd-internal-ia01" name="name"
>>>> value="pingd-internal"/>
>>>> <nvpair id="pingd-internal-ia02" name="dampen" value="5s"/>
>>>> <nvpair id="pingd-internal-ia03" name="multiplier"
>>>> value="1000"/>
>>>> <nvpair id="pingd-internal-ia04" name="host_list"
>>>> value="172.17.32.23 192.168.132.23"/>
>>>> </instance_attributes>
>>>> </primitive>
>>>> </clone>
>>>>
>>>> <clone id="clone-pingd-external">
>>>> <primitive id="pingd-external" provider="pacemaker" class="ocf"
>>>> type="pingd">
>>>> <instance_attributes id="pingd-external-ia">
>>>> <nvpair id="pingd-external-ia01" name="name"
>>>> value="pingd-external"/>
>>>> <nvpair id="pingd-external-ia02" name="dampen" value="5s"/>
>>>> <nvpair id="pingd-external-ia03" name="multiplier"
>>>> value="1000"/>
>>>> <nvpair id="pingd-external-ia04" name="host_list"
>>>> value="195.244.97.241"/>
>>>> </instance_attributes>
>>>> </primitive>
>>>> </clone>
>>>>
>>>> I defined a constraint for a resource so that it depends on
>>>> pingd-internal
>>>>
>>>> <constraints>
>>>> <rsc_location id="hbtest1b-connectivity" rsc="hbtest1b">
>>>> <rule id="hbtest1b-connectivity-exclude-rule" score="-INFINITY" >
>>>> <expression id="hbtest1b-connectivity-exclude"
>>>> attribute="pingd-internal" operation="not_defined"/>
>>>> </rule>
>>>> </rsc_location>
>>>> </constraints>
>>>>
>>>> But this causes the resource to be unrunnable on either of my both
>>>> nodes,
>>>>
>>>>
>>>> There are as expected 2 pingd daemons running:
>>>>
>>>> root 6132 1 0 21:07 ? 00:00:00
>>>> /usr/lib/heartbeat/pingd
>>>> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a
>>>> pingd-internal
>>>> -d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
>>>> root 13142 1 0 21:47 ? 00:00:00
>>>> /usr/lib/heartbeat/pingd
>>>> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a
>>>> pingd-external
>>>> -d 5s -m 1000 -h 195.244.97.241
>>>>
>>>> The problem is, I can't see in the cibadmin -Q output that the pingd
>>>> daemons have
>>>> have stored their results anywhere..
>>>>
>>>> In the log I see the following output:
>>>>
>>>> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>>>> (0):
>>>> 3, code=1, seq=0, id=0, check=24031
>>>> Sep 24 22:01:47 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>>>> (0):
>>>> 3, code=1, seq=0, id=0, check=24031
>>>> Sep 24 22:01:48 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
>>>> (0):
>>>> 8, code=0, seq=261, id=0, check=22762
>>>> Sep 24 22:01:48 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>>> 8, code=0, seq=263, id=0, check=22250
>>>> Sep 24 22:01:50 xen20a pingd: [13142]: info: stand_alone_ping: Node
>>>> 195.244.97.241 is alive (1)
>>>> Sep 24 22:01:50 xen20a pingd: [13142]: info: send_update: 1 active ping
>>>> nodes
>>>> Sep 24 22:01:51 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>>> 3, code=1, seq=0, id=0, check=24031
>>>> Sep 24 22:01:52 xen20a pingd: [6132]: info: stand_alone_ping: Node
>>>> 172.17.32.23 is alive (3)
>>>> Sep 24 22:01:53 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>>> 3, code=1, seq=0, id=0, check=24031
>>>> Sep 24 22:01:54 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>>> 3, code=1, seq=0, id=0, check=25823
>>>> Sep 24 22:01:55 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
>>>> 3, code=1, seq=0, id=0, check=24031
>>>> Sep 24 22:01:57 xen20a pingd: [6132]: info: stand_alone_ping: Node
>>>> 192.168.132.23 is alive (2)
>>>> Sep 24 22:01:57 xen20a pingd: [6132]: info: send_update: 2 active
>>>> ping nodes
>>>>
>>>> Where should the current pingd status be located in the cib ?
>>>> What is wrong with my setup ?
>>>>
>>>> TIA,
>>>> Bruno
>>>>
>>>>
>>> --
>>> Serge Dubrouski.
>>>
>
>

Attachments:

signature.asc (0.19 KB)

beekhof at gmail

Sep 26, 2008, 12:37 AM

Post #6 of 13 (1507 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

Most likely you've found a bug :-(
Would you be able to create a bugzilla entry for this?

On Sep 25, 2008, at 9:33 PM, Bruno Voigt wrote:

> Wow.. these warnings are even shown for 127.0.0.1 ?!
> Do I need to finetune the IP stack options somewhere like in
> sysctl.conf
> to have these warnings of pingd fixed?
>
> root[at]xen20b:~# /usr/lib/heartbeat/pingd -V -a pingd-internal -d 5s -
> m 1000 -h 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:04 debug: main: Adding ping host
> 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:04 debug: main: attrd registration
> attempt: 0
> pingd[26741]: 2008/09/25_21:30:09 debug:
> init_client_ipc_comms_nodispatch: Attempting to talk on: /var/run/
> heartbeat/crm/attrd
> pingd[26741]: 2008/09/25_21:30:09 info: main: Starting pingd
> pingd[26741]: 2008/09/25_21:30:19 debug: stand_alone_ping: Checking
> connectivity
> pingd[26741]: 2008/09/25_21:30:19 debug: ping_open: Got address
> 127.0.0.1 for 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:19 debug: ping_open: Opened
> connection to 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:19 debug: ping_write: Sent 39 bytes
> to 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:19 WARN: dump_v4_echo: Bad echo (0):
> 8, code=0, seq=5, id=0, check=22763
> pingd[26741]: 2008/09/25_21:30:20 debug: ping_write: Sent 39 bytes
> to 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:20 debug: dump_v4_echo: 59 bytes from
> 127.0.0.1, icmp_seq=5: beekhof-v4
> pingd[26741]: 2008/09/25_21:30:21 debug: ping_write: Sent 39 bytes
> to 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:21 WARN: dump_v4_echo: Bad echo (0):
> 8, code=0, seq=13138, id=0, check=3000
> pingd[26741]: 2008/09/25_21:30:22 debug: ping_write: Sent 39 bytes
> to 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:22 debug: dump_v4_echo: 59 bytes from
> 10.10.10.167, icmp_seq=13138: beekhof-v4
> pingd[26741]: 2008/09/25_21:30:23 debug: ping_write: Sent 39 bytes
> to 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:23 WARN: dump_v4_echo: Bad echo (0):
> 8, code=0, seq=8284, id=0, check=459
>
> root[at]xen20b:~# uname -a
> Linux xen20b.bb.ic3s.de 2.6.18-6-xen-amd64 #1 SMP Tue Aug 19
> 06:15:09 UTC 2008 x86_64 GNU/Linux
>
> Bruno Voigt wrote:
>>
>> Hi Andrew,
>>
>> is pingd doing alive tests differently compared to the normal ping
>> command?
>> normal & flood ping of these hosts show 0% packet lost from my both
>> nodes.
>>
>> In the log below pingd - besides the warnings -
>> states that the node is alive and that it had sent an update,
>> but it does not show up in the cib.
>>
>> WR,
>> Bruno
>>
>> Andrew Beekhof wrote:
>>
>>> On Sep 24, 2008, at 10:36 PM, Serge Dubrouski wrote:
>>>
>>>
>>>> There is a problem with attrd that affects pingd in Pacemeaker
>>>> 0.7.3/Heartbeat 2.99. I've already created a Bugzilla ticket for
>>>> it.
>>>> You can add your information there:
>>>>
>>>> http://developerbugs.linux-foundation.org/show_bug.cgi?id=1969
>>>>
>>> I'm not so sure this is the same thing.
>>> Those "Bad echo" messages look suspicious
>>>
>>>
>>>>> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad
>>>>> echo
>>>>> (0):
>>>>> 3, code=1, seq=0, id=0, check=24031
>>>>>
>>> In fact, type=3 is ICMP_DEST_UNREACH - so pingd really is having
>>> trouble contacting that host.
>>>
>>>
>>>
>>>> On Wed, Sep 24, 2008 at 2:04 PM, Bruno Voigt <Bruno.Voigt[at]ic3s.de>
>>>> wrote:
>>>>
>>>>> I defined two ping clone resources,
>>>>> to be used independently by different resources:
>>>>>
>>>>> <clone id="clone-pingd-internal">
>>>>> <primitive id="pingd-internal" provider="pacemaker"
>>>>> class="ocf"
>>>>> type="pingd">
>>>>> <instance_attributes id="pingd-internal-ia">
>>>>> <nvpair id="pingd-internal-ia01" name="name"
>>>>> value="pingd-internal"/>
>>>>> <nvpair id="pingd-internal-ia02" name="dampen"
>>>>> value="5s"/>
>>>>> <nvpair id="pingd-internal-ia03" name="multiplier"
>>>>> value="1000"/>
>>>>> <nvpair id="pingd-internal-ia04" name="host_list"
>>>>> value="172.17.32.23 192.168.132.23"/>
>>>>> </instance_attributes>
>>>>> </primitive>
>>>>> </clone>
>>>>>
>>>>> <clone id="clone-pingd-external">
>>>>> <primitive id="pingd-external" provider="pacemaker"
>>>>> class="ocf"
>>>>> type="pingd">
>>>>> <instance_attributes id="pingd-external-ia">
>>>>> <nvpair id="pingd-external-ia01" name="name"
>>>>> value="pingd-external"/>
>>>>> <nvpair id="pingd-external-ia02" name="dampen"
>>>>> value="5s"/>
>>>>> <nvpair id="pingd-external-ia03" name="multiplier"
>>>>> value="1000"/>
>>>>> <nvpair id="pingd-external-ia04" name="host_list"
>>>>> value="195.244.97.241"/>
>>>>> </instance_attributes>
>>>>> </primitive>
>>>>> </clone>
>>>>>
>>>>> I defined a constraint for a resource so that it depends on
>>>>> pingd-internal
>>>>>
>>>>> <constraints>
>>>>> <rsc_location id="hbtest1b-connectivity" rsc="hbtest1b">
>>>>> <rule id="hbtest1b-connectivity-exclude-rule" score="-
>>>>> INFINITY" >
>>>>> <expression id="hbtest1b-connectivity-exclude"
>>>>> attribute="pingd-internal" operation="not_defined"/>
>>>>> </rule>
>>>>> </rsc_location>
>>>>> </constraints>
>>>>>
>>>>> But this causes the resource to be unrunnable on either of my both
>>>>> nodes,
>>>>>
>>>>>
>>>>> There are as expected 2 pingd daemons running:
>>>>>
>>>>> root 6132 1 0 21:07 ? 00:00:00
>>>>> /usr/lib/heartbeat/pingd
>>>>> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a
>>>>> pingd-internal
>>>>> -d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
>>>>> root 13142 1 0 21:47 ? 00:00:00
>>>>> /usr/lib/heartbeat/pingd
>>>>> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a
>>>>> pingd-external
>>>>> -d 5s -m 1000 -h 195.244.97.241
>>>>>
>>>>> The problem is, I can't see in the cibadmin -Q output that the
>>>>> pingd
>>>>> daemons have
>>>>> have stored their results anywhere..
>>>>>
>>>>> In the log I see the following output:
>>>>>
>>>>> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad
>>>>> echo
>>>>> (0):
>>>>> 3, code=1, seq=0, id=0, check=24031
>>>>> Sep 24 22:01:47 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad
>>>>> echo
>>>>> (0):
>>>>> 3, code=1, seq=0, id=0, check=24031
>>>>> Sep 24 22:01:48 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad
>>>>> echo
>>>>> (0):
>>>>> 8, code=0, seq=261, id=0, check=22762
>>>>> Sep 24 22:01:48 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad
>>>>> echo (0):
>>>>> 8, code=0, seq=263, id=0, check=22250
>>>>> Sep 24 22:01:50 xen20a pingd: [13142]: info: stand_alone_ping:
>>>>> Node
>>>>> 195.244.97.241 is alive (1)
>>>>> Sep 24 22:01:50 xen20a pingd: [13142]: info: send_update: 1
>>>>> active ping
>>>>> nodes
>>>>> Sep 24 22:01:51 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad
>>>>> echo (0):
>>>>> 3, code=1, seq=0, id=0, check=24031
>>>>> Sep 24 22:01:52 xen20a pingd: [6132]: info: stand_alone_ping: Node
>>>>> 172.17.32.23 is alive (3)
>>>>> Sep 24 22:01:53 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad
>>>>> echo (0):
>>>>> 3, code=1, seq=0, id=0, check=24031
>>>>> Sep 24 22:01:54 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad
>>>>> echo (0):
>>>>> 3, code=1, seq=0, id=0, check=25823
>>>>> Sep 24 22:01:55 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad
>>>>> echo (0):
>>>>> 3, code=1, seq=0, id=0, check=24031
>>>>> Sep 24 22:01:57 xen20a pingd: [6132]: info: stand_alone_ping: Node
>>>>> 192.168.132.23 is alive (2)
>>>>> Sep 24 22:01:57 xen20a pingd: [6132]: info: send_update: 2 active
>>>>> ping nodes
>>>>>
>>>>> Where should the current pingd status be located in the cib ?
>>>>> What is wrong with my setup ?
>>>>>
>>>>> TIA,
>>>>> Bruno
>>>>>
>>>>>
>>>> --
>>>> Serge Dubrouski.
>>>>
>>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker[at]clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker

beekhof at gmail

Sep 26, 2008, 7:42 AM

Post #7 of 13 (1540 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

On Fri, Sep 26, 2008 at 09:37, Andrew Beekhof <beekhof[at]gmail.com> wrote:
> Most likely you've found a bug :-(
> Would you be able to create a bugzilla entry for this?
> On Sep 25, 2008, at 9:33 PM, Bruno Voigt wrote:
>
> Wow.. these warnings are even shown for 127.0.0.1 ?!
> Do I need to finetune the IP stack options somewhere like in sysctl.conf
> to have these warnings of pingd fixed?

I looked into this, and for localhost the cause is me not filtering
out the ICMP_ECHO packet.
I'll patch that now.

For remote hosts, there seems to be something else going on

> root[at]xen20b:~# /usr/lib/heartbeat/pingd -V -a pingd-internal -d 5s -m 1000
> -h 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:04 debug: main: Adding ping host 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:04 debug: main: attrd registration attempt: 0
> pingd[26741]: 2008/09/25_21:30:09 debug: init_client_ipc_comms_nodispatch:
> Attempting to talk on: /var/run/heartbeat/crm/attrd
> pingd[26741]: 2008/09/25_21:30:09 info: main: Starting pingd
> pingd[26741]: 2008/09/25_21:30:19 debug: stand_alone_ping: Checking
> connectivity
> pingd[26741]: 2008/09/25_21:30:19 debug: ping_open: Got address 127.0.0.1
> for 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:19 debug: ping_open: Opened connection to
> 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:19 debug: ping_write: Sent 39 bytes to
> 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:19 WARN: dump_v4_echo: Bad echo (0): 8,
> code=0, seq=5, id=0, check=22763
> pingd[26741]: 2008/09/25_21:30:20 debug: ping_write: Sent 39 bytes to
> 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:20 debug: dump_v4_echo: 59 bytes from
> 127.0.0.1, icmp_seq=5: beekhof-v4
> pingd[26741]: 2008/09/25_21:30:21 debug: ping_write: Sent 39 bytes to
> 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:21 WARN: dump_v4_echo: Bad echo (0): 8,
> code=0, seq=13138, id=0, check=3000
> pingd[26741]: 2008/09/25_21:30:22 debug: ping_write: Sent 39 bytes to
> 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:22 debug: dump_v4_echo: 59 bytes from
> 10.10.10.167, icmp_seq=13138: beekhof-v4
> pingd[26741]: 2008/09/25_21:30:23 debug: ping_write: Sent 39 bytes to
> 127.0.0.1
> pingd[26741]: 2008/09/25_21:30:23 WARN: dump_v4_echo: Bad echo (0): 8,
> code=0, seq=8284, id=0, check=459
>
> root[at]xen20b:~# uname -a
> Linux xen20b.bb.ic3s.de 2.6.18-6-xen-amd64 #1 SMP Tue Aug 19 06:15:09 UTC
> 2008 x86_64 GNU/Linux
>
> Bruno Voigt wrote:
>
> Hi Andrew,
>
> is pingd doing alive tests differently compared to the normal ping command?
> normal & flood ping of these hosts show 0% packet lost from my both nodes.
>
> In the log below pingd - besides the warnings -
> states that the node is alive and that it had sent an update,
> but it does not show up in the cib.
>
> WR,
> Bruno
>
> Andrew Beekhof wrote:
>
>
> On Sep 24, 2008, at 10:36 PM, Serge Dubrouski wrote:
>
>
>
> There is a problem with attrd that affects pingd in Pacemeaker
> 0.7.3/Heartbeat 2.99. I've already created a Bugzilla ticket for it.
> You can add your information there:
>
> http://developerbugs.linux-foundation.org/show_bug.cgi?id=1969
>
>
> I'm not so sure this is the same thing.
> Those "Bad echo" messages look suspicious
>
>
>
> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
> (0):
> 3, code=1, seq=0, id=0, check=24031
>
>
> In fact, type=3 is ICMP_DEST_UNREACH - so pingd really is having
> trouble contacting that host.
>
>
>
>
> On Wed, Sep 24, 2008 at 2:04 PM, Bruno Voigt <Bruno.Voigt[at]ic3s.de>
> wrote:
>
>
> I defined two ping clone resources,
> to be used independently by different resources:
>
> <clone id="clone-pingd-internal">
> <primitive id="pingd-internal" provider="pacemaker" class="ocf"
> type="pingd">
> <instance_attributes id="pingd-internal-ia">
> <nvpair id="pingd-internal-ia01" name="name"
> value="pingd-internal"/>
> <nvpair id="pingd-internal-ia02" name="dampen" value="5s"/>
> <nvpair id="pingd-internal-ia03" name="multiplier"
> value="1000"/>
> <nvpair id="pingd-internal-ia04" name="host_list"
> value="172.17.32.23 192.168.132.23"/>
> </instance_attributes>
> </primitive>
> </clone>
>
> <clone id="clone-pingd-external">
> <primitive id="pingd-external" provider="pacemaker" class="ocf"
> type="pingd">
> <instance_attributes id="pingd-external-ia">
> <nvpair id="pingd-external-ia01" name="name"
> value="pingd-external"/>
> <nvpair id="pingd-external-ia02" name="dampen" value="5s"/>
> <nvpair id="pingd-external-ia03" name="multiplier"
> value="1000"/>
> <nvpair id="pingd-external-ia04" name="host_list"
> value="195.244.97.241"/>
> </instance_attributes>
> </primitive>
> </clone>
>
> I defined a constraint for a resource so that it depends on
> pingd-internal
>
> <constraints>
> <rsc_location id="hbtest1b-connectivity" rsc="hbtest1b">
> <rule id="hbtest1b-connectivity-exclude-rule" score="-INFINITY" >
> <expression id="hbtest1b-connectivity-exclude"
> attribute="pingd-internal" operation="not_defined"/>
> </rule>
> </rsc_location>
> </constraints>
>
> But this causes the resource to be unrunnable on either of my both
> nodes,
>
>
> There are as expected 2 pingd daemons running:
>
> root 6132 1 0 21:07 ? 00:00:00
> /usr/lib/heartbeat/pingd
> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a
> pingd-internal
> -d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
> root 13142 1 0 21:47 ? 00:00:00
> /usr/lib/heartbeat/pingd
> -D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a
> pingd-external
> -d 5s -m 1000 -h 195.244.97.241
>
> The problem is, I can't see in the cibadmin -Q output that the pingd
> daemons have
> have stored their results anywhere..
>
> In the log I see the following output:
>
> Sep 24 22:01:46 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
> (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:47 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
> (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:48 xen20a pingd: [13142]: WARN: dump_v4_echo: Bad echo
> (0):
> 8, code=0, seq=261, id=0, check=22762
> Sep 24 22:01:48 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 8, code=0, seq=263, id=0, check=22250
> Sep 24 22:01:50 xen20a pingd: [13142]: info: stand_alone_ping: Node
> 195.244.97.241 is alive (1)
> Sep 24 22:01:50 xen20a pingd: [13142]: info: send_update: 1 active ping
> nodes
> Sep 24 22:01:51 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:52 xen20a pingd: [6132]: info: stand_alone_ping: Node
> 172.17.32.23 is alive (3)
> Sep 24 22:01:53 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:54 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=25823
> Sep 24 22:01:55 xen20a pingd: [6132]: WARN: dump_v4_echo: Bad echo (0):
> 3, code=1, seq=0, id=0, check=24031
> Sep 24 22:01:57 xen20a pingd: [6132]: info: stand_alone_ping: Node
> 192.168.132.23 is alive (2)
> Sep 24 22:01:57 xen20a pingd: [6132]: info: send_update: 2 active
> ping nodes
>
> Where should the current pingd status be located in the cib ?
> What is wrong with my setup ?
>
> TIA,
> Bruno
>
>
>
> --
> Serge Dubrouski.
>
>
>
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker[at]clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>
>

_______________________________________________
Pacemaker mailing list
Pacemaker[at]clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker

beekhof at gmail

Sep 26, 2008, 1:15 PM

Post #8 of 13 (1503 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

On Fri, Sep 26, 2008 at 16:42, Andrew Beekhof <beekhof[at]gmail.com> wrote:
> On Fri, Sep 26, 2008 at 09:37, Andrew Beekhof <beekhof[at]gmail.com> wrote:
>> Most likely you've found a bug :-(
>> Would you be able to create a bugzilla entry for this?
>> On Sep 25, 2008, at 9:33 PM, Bruno Voigt wrote:
>>
>> Wow.. these warnings are even shown for 127.0.0.1 ?!
>> Do I need to finetune the IP stack options somewhere like in sysctl.conf
>> to have these warnings of pingd fixed?
>
> I looked into this, and for localhost the cause is me not filtering
> out the ICMP_ECHO packet.
> I'll patch that now.
>
> For remote hosts, there seems to be something else going on

In short - pingd in 0.7 is/was completely broken on linux (but worked
great on Darwin).
Sorry :(

The good news is that I have it basically functioning properly now - I
just need to clean up the patch before I commit (which I'll do over
the weekend).

_______________________________________________
Pacemaker mailing list
Pacemaker[at]clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker

Bruno.Voigt at ic3s

Sep 28, 2008, 10:29 AM

Post #9 of 13 (1501 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

Hi Andrew,
thanks a lot for your effort!!

BTW: how often are new builds provided in
http://download.opensuse.org/repositories/server:/ha-clustering:/UNSTABLE/ ?

WR,
Bruno

Attachments:

signature.asc (0.19 KB)

beekhof at gmail

Sep 29, 2008, 3:59 AM

Post #10 of 13 (1495 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

On Sep 28, 2008, at 7:29 PM, Bruno Voigt wrote:

> Hi Andrew,
> thanks a lot for your effort!!
>
> BTW: how often are new builds provided in
> http://download.opensuse.org/repositories/server:/ha-clustering:/UNSTABLE/
> ?

There's no official timeline (like the stable releases), its mostly
whenever I do some testing and things look good enough to update.
I'll update them as soon as I fix pingd

Other than pingd and possibly some CLI tools stuff I haven't found
yet, "UNSTABLE" is proving to be really solid.
CTS simply isn't finding much at all to complain about - I don't think
1.0.0 is going to be far off at all.

_______________________________________________
Pacemaker mailing list
Pacemaker[at]clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker

beekhof at gmail

Oct 6, 2008, 6:29 AM

Post #11 of 13 (1449 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

On Fri, Sep 26, 2008 at 22:15, Andrew Beekhof <beekhof[at]gmail.com> wrote:
> On Fri, Sep 26, 2008 at 16:42, Andrew Beekhof <beekhof[at]gmail.com> wrote:
>> On Fri, Sep 26, 2008 at 09:37, Andrew Beekhof <beekhof[at]gmail.com> wrote:
>>> Most likely you've found a bug :-(
>>> Would you be able to create a bugzilla entry for this?
>>> On Sep 25, 2008, at 9:33 PM, Bruno Voigt wrote:
>>>
>>> Wow.. these warnings are even shown for 127.0.0.1 ?!
>>> Do I need to finetune the IP stack options somewhere like in sysctl.conf
>>> to have these warnings of pingd fixed?
>>
>> I looked into this, and for localhost the cause is me not filtering
>> out the ICMP_ECHO packet.
>> I'll patch that now.
>>
>> For remote hosts, there seems to be something else going on
>
> In short - pingd in 0.7 is/was completely broken on linux (but worked
> great on Darwin).
> Sorry :(
>
> The good news is that I have it basically functioning properly now - I
> just need to clean up the patch before I commit (which I'll do over
> the weekend).
>

Would you be able to verify that pingd in the new packages (0.7.3-2.1)
behaves properly?

Btw. You can also run it from the command line (with no cluster
present) by supplying the -U option.
Instead of trying to update attrd, it will instead output the message
it would have sent.

_______________________________________________
Pacemaker mailing list
Pacemaker[at]clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker

Bruno.Voigt at ic3s

Oct 6, 2008, 3:41 PM

Post #12 of 13 (1438 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

Andrew Beekhof wrote:
>> In short - pingd in 0.7 is/was completely broken on linux (but worked
>> great on Darwin).
>> Sorry :(
>>
>> The good news is that I have it basically functioning properly now - I
>> just need to clean up the patch before I commit (which I'll do over
>> the weekend).
>>
>>
>
> Would you be able to verify that pingd in the new packages (0.7.3-2.1)
> behaves properly?
>
I installed the debian/etch packages from Oct 06 and no longer see "bad
echo" messages:

Oct 7 00:32:33 xen20b attrd_updater: [29206]: info: Invoked:
/usr/sbin/attrd_updater -S status -n cpu_speed -v 4002.38
Oct 7 00:32:33 xen20b attrd_updater: [29209]: info: Invoked:
/usr/sbin/attrd_updater -S status -n cpu_cores -v 2
Oct 7 00:32:33 xen20b attrd_updater: [29214]: info: Invoked:
/usr/sbin/attrd_updater -S status -n cpu_load -v 2.05
Oct 7 00:32:33 xen20b attrd_updater: [29226]: info: Invoked:
/usr/sbin/attrd_updater -S status -n ram_total -v 550
Oct 7 00:32:33 xen20b attrd_updater: [29236]: info: Invoked:
/usr/sbin/attrd_updater -S status -n ram_free -v 100
Oct 7 00:32:33 xen20b attrd_updater: [29246]: info: Invoked:
/usr/sbin/attrd_updater -S status -n root_free -v 40%
Oct 7 00:32:36 xen20b pingd: [12186]: info: stand_alone_ping: Node
195.244.97.241 is alive
Oct 7 00:32:36 xen20b pingd: [12186]: info: send_update: 1 active ping
nodes
Oct 7 00:32:42 xen20b pingd: [12197]: info: stand_alone_ping: Node
172.17.32.23 is alive
Oct 7 00:32:42 xen20b pingd: [12197]: info: stand_alone_ping: Node
192.168.132.23 is alive
Oct 7 00:32:42 xen20b pingd: [12197]: info: send_update: 2 active ping
nodes
Oct 7 00:32:46 xen20b pingd: [12186]: info: stand_alone_ping: Node
195.244.97.241 is alive
Oct 7 00:32:46 xen20b pingd: [12186]: info: send_update: 1 active ping
nodes
Oct 7 00:32:52 xen20b pingd: [12197]: info: stand_alone_ping: Node
172.17.32.23 is alive
Oct 7 00:32:52 xen20b pingd: [12197]: info: stand_alone_ping: Node
192.168.132.23 is alive
Oct 7 00:32:52 xen20b pingd: [12197]: info: send_update: 2 active ping
nodes
Oct 7 00:32:53 xen20b attrd: [3562]: info: attrd_ha_callback: (null)
message from (null)
Oct 7 00:32:53 xen20b attrd: [3562]: info: find_hash_entry: Ignoring
message with no attribute name
Oct 7 00:32:53 xen20b attrd_updater: [29337]: info: Invoked:
/usr/sbin/attrd_updater -S status -n arch -v x86_64
Oct 7 00:32:53 xen20b attrd_updater: [29340]: info: Invoked:
/usr/sbin/attrd_updater -S status -n os -v Linux-2.6.18-6-xen-amd64
Oct 7 00:32:53 xen20b attrd_updater: [29363]: info: Invoked:
/usr/sbin/attrd_updater -S status -n free_swap -v 2050
Oct 7 00:32:53 xen20b attrd_updater: [29370]: info: Invoked:
/usr/sbin/attrd_updater -S status -n cpu_info -v Intel(R) Xeon(R)
CPU 5110 @ 1.60GHz
Oct 7 00:32:53 xen20b attrd_updater: [29371]: info: Invoked:
/usr/sbin/attrd_updater -S status -n cpu_speed -v 4002.38
Oct 7 00:32:53 xen20b attrd_updater: [29372]: info: Invoked:
/usr/sbin/attrd_updater -S status -n cpu_cores -v 2
Oct 7 00:32:53 xen20b attrd_updater: [29377]: info: Invoked:
/usr/sbin/attrd_updater -S status -n cpu_load -v 2.05
Oct 7 00:32:53 xen20b attrd_updater: [29387]: info: Invoked:
/usr/sbin/attrd_updater -S status -n ram_total -v 550
Oct 7 00:32:53 xen20b attrd_updater: [29397]: info: Invoked:
/usr/sbin/attrd_updater -S status -n ram_free -v 100
Oct 7 00:32:53 xen20b attrd_updater: [29407]: info: Invoked:
/usr/sbin/attrd_updater -S status -n root_free -v 40%
Oct 7 00:32:56 xen20b pingd: [12186]: info: stand_alone_ping: Node
195.244.97.241 is alive
Oct 7 00:32:56 xen20b pingd: [12186]: info: send_update: 1 active ping
nodes

But I can't detect in the cibadmin -Q output any trace of the set
attributes!
Where should they be located ?
Do I have to initialize them manually so that pingd can update them? How?
BTW: the output of the SysInfo clone-resource is there:

<node_state uname="xen20b.fqdn" ha="active" in_ccm="true" crmd="online"
join="member" shutdown="0" expected="member"
id="278bebc6-2a59-4fa9-be2f-f6e262ce8936"
crm-debug-origin="do_update_resource">
<transient_attributes id="278bebc6-2a59-4fa9-be2f-f6e262ce8936">
<instance_attributes
id="status-278bebc6-2a59-4fa9-be2f-f6e262ce8936">
<nvpair name="root_free"
id="status-278bebc6-2a59-4fa9-be2f-f6e262ce8936-root_free" value="40%"/>
<nvpair id="status-278bebc6-2a59-4fa9-be2f-f6e262ce8936-os"
name="os" value="Linux-2.6.18-6-xen-amd64"/>
<nvpair id="status-278bebc6-2a59-4fa9-be2f-f6e262ce8936-arch"
name="arch" value="x86_64"/>

# ps -ef | grep pingd
root 6440 1 0 Oct06 ? 00:00:00 /usr/lib/heartbeat/pingd
-D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a pingd-internal
-d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
root 6502 1 0 Oct06 ? 00:00:00 /usr/lib/heartbeat/pingd
-D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a pingd-external
-d 5s -m 1000 -h 195.244.97.241

> Btw. You can also run it from the command line (with no cluster
> present) by supplying the -U option.
> Instead of trying to update attrd, it will instead output the message
> it would have sent.
>
>
/usr/lib/heartbeat/pingd -U -a pingd-internal -d 5s -m 1000 -h 172.17.32.23
does not generate any output on the console.
The -U switch does not appear in pingd --help.

WR,
Bruno

Attachments:

signature.asc (0.19 KB)

beekhof at gmail

Oct 6, 2008, 10:52 PM

Post #13 of 13 (1440 views)
Permalink

Re: Pacemaker 0.7.3: How to use pingd clone resource and constraints [In reply to]

On Oct 7, 2008, at 12:41 AM, Bruno Voigt wrote:

> Andrew Beekhof wrote:
>>
>>> In short - pingd in 0.7 is/was completely broken on linux (but
>>> worked
>>> great on Darwin).
>>> Sorry :(
>>>
>>> The good news is that I have it basically functioning properly now
>>> - I
>>> just need to clean up the patch before I commit (which I'll do over
>>> the weekend).
>>>
>>>
>> Would you be able to verify that pingd in the new packages
>> (0.7.3-2.1)
>> behaves properly?
>>
> I installed the debian/etch packages from Oct 06 and no longer see
> "bad echo" messages:
>
> Oct 7 00:32:33 xen20b attrd_updater: [29206]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n cpu_speed -v 4002.38
> Oct 7 00:32:33 xen20b attrd_updater: [29209]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n cpu_cores -v 2
> Oct 7 00:32:33 xen20b attrd_updater: [29214]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n cpu_load -v 2.05
> Oct 7 00:32:33 xen20b attrd_updater: [29226]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n ram_total -v 550
> Oct 7 00:32:33 xen20b attrd_updater: [29236]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n ram_free -v 100
> Oct 7 00:32:33 xen20b attrd_updater: [29246]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n root_free -v 40%
> Oct 7 00:32:36 xen20b pingd: [12186]: info: stand_alone_ping: Node
> 195.244.97.241 is alive
> Oct 7 00:32:36 xen20b pingd: [12186]: info: send_update: 1 active
> ping nodes
> Oct 7 00:32:42 xen20b pingd: [12197]: info: stand_alone_ping: Node
> 172.17.32.23 is alive
> Oct 7 00:32:42 xen20b pingd: [12197]: info: stand_alone_ping: Node
> 192.168.132.23 is alive
> Oct 7 00:32:42 xen20b pingd: [12197]: info: send_update: 2 active
> ping nodes
> Oct 7 00:32:46 xen20b pingd: [12186]: info: stand_alone_ping: Node
> 195.244.97.241 is alive
> Oct 7 00:32:46 xen20b pingd: [12186]: info: send_update: 1 active
> ping nodes
> Oct 7 00:32:52 xen20b pingd: [12197]: info: stand_alone_ping: Node
> 172.17.32.23 is alive
> Oct 7 00:32:52 xen20b pingd: [12197]: info: stand_alone_ping: Node
> 192.168.132.23 is alive
> Oct 7 00:32:52 xen20b pingd: [12197]: info: send_update: 2 active
> ping nodes
> Oct 7 00:32:53 xen20b attrd: [3562]: info: attrd_ha_callback:
> (null) message from (null)
> Oct 7 00:32:53 xen20b attrd: [3562]: info: find_hash_entry:
> Ignoring message with no attribute name
> Oct 7 00:32:53 xen20b attrd_updater: [29337]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n arch -v x86_64
> Oct 7 00:32:53 xen20b attrd_updater: [29340]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n os -v Linux-2.6.18-6-xen-amd64
> Oct 7 00:32:53 xen20b attrd_updater: [29363]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n free_swap -v 2050
> Oct 7 00:32:53 xen20b attrd_updater: [29370]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n cpu_info -v Intel(R) Xeon(R)
> CPU 5110 @ 1.60GHz
> Oct 7 00:32:53 xen20b attrd_updater: [29371]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n cpu_speed -v 4002.38
> Oct 7 00:32:53 xen20b attrd_updater: [29372]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n cpu_cores -v 2
> Oct 7 00:32:53 xen20b attrd_updater: [29377]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n cpu_load -v 2.05
> Oct 7 00:32:53 xen20b attrd_updater: [29387]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n ram_total -v 550
> Oct 7 00:32:53 xen20b attrd_updater: [29397]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n ram_free -v 100
> Oct 7 00:32:53 xen20b attrd_updater: [29407]: info: Invoked: /usr/
> sbin/attrd_updater -S status -n root_free -v 40%
> Oct 7 00:32:56 xen20b pingd: [12186]: info: stand_alone_ping: Node
> 195.244.97.241 is alive
> Oct 7 00:32:56 xen20b pingd: [12186]: info: send_update: 1 active
> ping nodes

this last line makes it look like things are working... i'll
investigate further

>
>
> But I can't detect in the cibadmin -Q output any trace of the set
> attributes!
> Where should they be located ?

under transient_attributes

>
> Do I have to initialize them manually so that pingd can update them?
> How?
> BTW: the output of the SysInfo clone-resource is there:
>
> <node_state uname="xen20b.fqdn" ha="active" in_ccm="true"
> crmd="online" join="member" shutdown="0" expected="member"
> id="278bebc6-2a59-4fa9-be2f-f6e262ce8936" crm-debug-
> origin="do_update_resource">
> <transient_attributes id="278bebc6-2a59-4fa9-be2f-f6e262ce8936">
> <instance_attributes id="status-278bebc6-2a59-4fa9-be2f-
> f6e262ce8936">
> <nvpair name="root_free" id="status-278bebc6-2a59-4fa9-
> be2f-f6e262ce8936-root_free" value="40%"/>
> <nvpair id="status-278bebc6-2a59-4fa9-be2f-f6e262ce8936-
> os" name="os" value="Linux-2.6.18-6-xen-amd64"/>
> <nvpair id="status-278bebc6-2a59-4fa9-be2f-f6e262ce8936-
> arch" name="arch" value="x86_64"/>
>
> # ps -ef | grep pingd
> root 6440 1 0 Oct06 ? 00:00:00 /usr/lib/heartbeat/
> pingd -D -p /var/run/heartbeat/rsctmp/pingd-pingd-internal:0 -a
> pingd-internal -d 5s -m 1000 -h 172.17.32.23 -h 192.168.132.23
> root 6502 1 0 Oct06 ? 00:00:00 /usr/lib/heartbeat/
> pingd -D -p /var/run/heartbeat/rsctmp/pingd-pingd-external:0 -a
> pingd-external -d 5s -m 1000 -h 195.244.97.241
>
>> Btw. You can also run it from the command line (with no cluster
>> present) by supplying the -U option.
>> Instead of trying to update attrd, it will instead output the message
>> it would have sent.
>>
>>
> /usr/lib/heartbeat/pingd -U -a pingd-internal -d 5s -m 1000 -h
> 172.17.32.23
> does not generate any output on the console.

add -V

>
> The -U switch does not appear in pingd --help.

right - it shouldn't be needed by anyone once pingd works properly

_______________________________________________
Pacemaker mailing list
Pacemaker[at]clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com