[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