[Pacemaker] It affects it that the update of the attribute by attrd is late, and a resource starts with a standby node.

[renayama19661014 at ybb.ne.jp]

Hi Andrew,

> > Step1) 192.168.40.3 addresses invalidate the understanding of ping.
> 
> Not sure I understand this, can you rephrase?

Sorry....

For pingd, we address 2 of the next.

 * 192.168.4.2
 * 192.168.4.3

When one address cannot communicate, this problem occurs.
When cluster can communicate with both addresses, the resource starts in a srv01 node definitely.

Best Regards,
Hideo Yamauchi.


--- Andrew Beekhof <andrew at beekhof.net> wrote:

> On Mon, Nov 29, 2010 at 3:18 AM,  <renayama19661014 at ybb.ne.jp> wrote:
> > Hi,
> >
> > We constituted a cluster by two node constitution.
> > It is constitution complicated slightly that included two pingd in
> > constitution.
> >
> > We confirmed a phenomenon in the next procedure.
> >
> > Step1) 192.168.40.3 addresses invalidate the understanding of ping.
> 
> Not sure I understand this, can you rephrase?
> 
> > Step2) Start two nodes and send trac1383.crm.
> >
> > ============
> > Last updated: Mon Nov 29 10:35:09 2010
> > Stack: Heartbeat
> > Current DC: srv02 (27456b6d-bb8e-445b-9baf-725a6b9417c6) - partition with
> > quorum
> > Version: 1.0.10-b2e39d318fda501e2fcf223c2d039b721f3679a9
> > 2 Nodes configured, unknown expected votes
> > 12 Resources configured.
> > ============
> >
> > Online: [ srv01 srv02 ]
> >
> > �Resource Group: TESTgroup1
> > � � TESTIPaddr (ocf::heartbeat:IPaddr2): � � � Started srv02
> > � � TESTDummy01 � � � �(ocf::pacemaker:Dummy): Started
srv02
> > � � TESTDummy02 � � � �(ocf::pacemaker:Dummy): Started
srv02
> > � � TESTDummy03 � � � �(ocf::pacemaker:Dummy): Started
srv02
> > �Resource Group: groupStonith1
> > � � prmStonithN1-1 � � (stonith:external/stonith-helper): �
� �Started srv02
> > � � prmStonithN1-2 � � (stonith:external/ssh): Started srv02
> > � � prmStonithN1-3 � � (stonith:meatware): � � Started
srv02
> > �Resource Group: groupStonith2
> > � � prmStonithN2-1 � � (stonith:external/stonith-helper): �
� �Started srv01
> > � � prmStonithN2-2 � � (stonith:external/ssh): Started srv01
> > � � prmStonithN2-3 � � (stonith:meatware): � � Started
srv01
> > �Clone Set: clnPingd1
> > � � Started: [ srv01 srv02 ]
> > �Clone Set: clnPingd2
> > � � Started: [ srv01 srv02 ]
> > �Clone Set: clnTESTmssd
> > � � Started: [ srv01 srv02 ]
> > �Clone Set: clnTESTopsc
> > � � Started: [ srv01 srv02 ]
> > �Clone Set: clncrond
> > � � Started: [ srv01 srv02 ]
> > �Clone Set: clnportmap
> > � � Started: [ srv01 srv02 ]
> > �Clone Set: clnsnmpd
> > � � Started: [ srv01 srv02 ]
> > �Clone Set: clnvsftpd
> > � � Started: [ srv01 srv02 ]
> > �Clone Set: clnxinetd
> > � � Started: [ srv01 srv02 ]
> >
> >
> > We hoped that a TESTgroup1 resource started in a node of active node(srv01),
> > but the result was started in the node of the standby(srv02).
> >
> > The problem seems to be caused by the fact that the attribute change of the
> > active node of attrd is late somehow or other.
> >
> > Can we evade this problem by setting?
> >
> > �* hb_report attached it to Bugzilla.
> > �* http://developerbugs.linux-foundation.org/show_bug.cgi?id=2528
> >
> > Best Regards,
> > Hideo Yamauchi.
> >
> > _______________________________________________
> > 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
> >
> 
> _______________________________________________
> 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>