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@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 > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
