Which switch do you have? I'd really like to see the ganglia community take a proactive stance on this and actually suggest / recommend working solutions for gmond being 'friendly' to switches. Also I like the idea of having all the gmonds in a cluster set to unicast their data to just a select few others, with the intention that these select few that would receive them would be redundently set up to be queried by gmetad. Also the gmonds would have to unicast to themselves to have them update themselves again, which would be a gross hack, with the preferred solution to just have it update itself without transmitting in this case. It was an elegant solution to just multicast out and then have it listen back on its own channel for updates, but I think theres a legitimate need here for unicasting out to just a select few gmonds.
By having the option to configure gmonds to unicast their data out to just a select few ips, wouldn't this potentially allow clusters to scale up even larger? Sub-clusters of gmonds would be unicasting, and then the regular 'full blown' gmonds would be queried or set to unicast again out to an even more senior and select group of gmonds.. its these final gmonds that would be then queried by gmetad for clusters stats to be archived away. ----- Original Message ----- From: "Nicholas Henke" <[EMAIL PROTECTED]> > Hello-- > I have installed ganglia on several of our clusters, but it would seem > that the multi-cast channel is pumping a ton of data. On a 96 node > cluster, I am seeing around 20-30Kb/s average data transfer on the > multicast channel ( seen via ntop ). I am _very_ interested in reducing > this, otherwise we will have to remove ganglia. I have seen the 'deaf' > and 'mute' options in gmond.conf, but have not seen a difference while > using them in traffic patterns. > > Is there any way to disable the multicast channel, and just have each > node reports stats to one monitoring server ? >
