Lester Vecsey wrote:
----- Original Message -----
From: "Steven Wagner" <[EMAIL PROTECTED]>
Hey, I wonder what would happen if someone specified a non-multicast IP
(running gmond, of course) as the target multicast network... anyone ever
try that? Even if this worked, only the "target" monitoring core would
have all the data (helloooooo, central point of failure), but it seems to
meet your requirements. Or someone could write an "aggregate update" mod
to the monitoring core that requires it to meet a minimum buffer threshold
before sending updates. Or perhaps there's just one or two misbehaving
metrics (run a couple of the monitoring cores on a separate multicast IP
in
debug mode and see what metrics pop up the most often...).
I think whats mentioned above and the ability to toggle gmond so that it can
listen back to its own reports either internally or from the 'target' gmond
that would relay the data back, would be a good approach. Better to go
internally though ;) Also I agree with the usefulness of having a second
administrative interface, although at the expensive of using more ports on a
switch. But the other issue is not so much the switch having to deal with
lots of packets, which as you point out is a low percentage, but that the
receiving computers kernel and networking code also have to deal with the
packets coming in. That in turn could still degrade a machines ability to
process nfs and other activity. Or maybe it isn't all that substantial. I'd
rather err on the side of having a cleaner/simpler running network though!
If memory serves me correctly, the monitoring and multicast listen threads
don't communicate with one another directly, or share a dynamic
metric-related data structure, so if it were transmitting to a unicast
host, the listen thread (and hence, the XML thread, since that *does* share
a data structure with the listen thread) would never see them. So all
you'd get would be a DTD and an empty <CLUSTER> tag from the XML thread, I
guess...
I'm pretty sure the catalyst switches can be set to do multicast more
effeciently by setting 'ip cgmp' on them, though I haven't confirmed this.
With 'ip cgmp' set on, machines can join and leave multicast channels as
they please and the switch will only direct packets to those machines that
need to listen to them. Normally though, the switch is literally just
broadcasting out each and every multicast ip packet to every machine on the
lan/vlan. I don't have direct access to the catalyst switches at work and I
haven't gotten the admin in charge to make the change. So in this way if the
ganglia community just had a quick html page with confirmed tips on switch
configuration it would be a big help.
I'm pretty sure all intelligent switches support this, as it's benefit
number one of multicast versus broadcast - only nodes that *ask* for the
traffic will get it. I am personally a little concerned at passing out
free switch config info when there are so many CCNEs out there collecting
unemployment (plus, it's not like I write the documentation ;) ).
Although, as you say, this does mean they have to process them all. Unless
the listen thread doesn't start ... IIRC it is not necessary to join a
multicast network to send a packet to it...
(you know, at the rate I say "If memory serves me correctly," I should
start referring to myself as the Chairman Kaga of the ganglia lists...)
