[Openais] cpgtool output corosync 1.3.0

Steven Dake sdake at redhat.com
Wed Mar 16 10:47:05 PDT 2011


On 03/14/2011 11:39 AM, dan clark wrote:
> Hello gentle readers!
> 
> Perhaps the corosync-cpgtool is an alternative to examine the status
> of the rings on a corosync system.  The tool provides some excellent
> low level diagnostics as it is, with several useful output formats.
> Thanks!!!
> 

Long term I'd like to put this information in the object database so it
can be queried via the corosync-objctl application.

> When two rings are enabled with different IP subnets the output status
> provides unexpected results for the node IP identifiers.  It appears
> that under the two ring situation one of the rings is arbitrarily
> selected and used to provide the IP address data, concatenated and
> duplicated.  Here is an example of such output:
> 
> % corosync-cpgtool
> Group Name             PID         Node ID
> aGroup\x00
>                       4774       990357696 (10.0.0.110.0.0.1)
>                       4694      1040689344 (10.0.0.110.0.0.1)
>                       4682      1023912128 (10.0.0.110.0.0.1)
> 
> Perhaps there is a simple fix to avoiding the concatenation
> tools/corosync-cpgtool.c -- about line 84  adding a space ater the
> print of the string (or fancier to consider 1 versus 2 rings)
>                         inet_ntop(ss->ss_family, saddr, buf, sizeof(buf));
> <                        fprintf(f, "%s", buf);
>>                        fprintf(f, "%s ", buf);
> 

This still prints the same node ip twice though?

> 
> In the example case above (based on the multiple ip addresses of the
> source nodes) would it be more helpful to accurately represent each of
> the node addresses?    I did not find right away why a single IP
> address was selected of the two which represent each node.
> 
> In the case of this setup I would have expected something like the
> following output which would provide a very powerful diagnostic to
> verify both rings and endpoints!
> 
> % corosync-cpgtool
> Group Name             PID         Node ID
> aGroup\x00
>                       4774       990357696 (192.168.7.59 10.0.0.9)
>                       4694      1040689344 (192.168.7.61 10.0.0.1)
>                       4682      1023912128 (192.168.7.62 10.0.0.2)
> 

Yes I agree, this would be the ideal diagnostic, put into the the object
database, queryable via corosync-objctl.

> What is particularly interesting about the above output is that
> provides a perspective across multiple nodes (given an application
> utilizing a group).
> 
> Perhaps an alternative diagnostic enhancement is providing the
> multiple node perspective from the cfgtool which as seen below only
> shows the current node, but none of the remaining members.
> 
> % corosync-cfgtool -s
> Printing ring status.
> Local node ID 1023912128
> RING ID 0
>         id      = 192.168.7.61
>         status  = ring 0 active with no faults
> RING ID 1
>         id      = 10.0.0.1
>         status  = ring 1 active with no faults

I would like to get rid of corosync-cfgtool -s as well :) (and put into
the object database).  Keep in mind if ring 0 (or 1) is failed on one
node, it is failed on all nodes.

Not exactly what you wanted, but we have this partially implemented:
[root at f14-n2 ~]# corosync-objctl runtime.totem.pg.mrp.srp.members
runtime.totem.pg.mrp.srp.1031448768.ip=r(0) ip(192.168.122.61) r(1)
ip(192.168.123.61)
runtime.totem.pg.mrp.srp.1031448768.join_count=1
runtime.totem.pg.mrp.srp.1031448768.status=joined

> _______________________________________________
> Openais mailing list
> Openais at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/openais



More information about the Openais mailing list