Hi Adrian,
Looks like the mcast configuration you are intending to use, should work.
Besides the number of nodes, its the number of metrics from each node and
overall, the payload per metric data that should also be taken into
consideration.
Also, as I said, I would use a mix and match of deaf/listener gmond nodes
so you do not really have to tax all the gmond instances for unnecessary
processing of the metric data.
Let me know how it goes, I would be interested to know your setup
challenges.
You may also want to look at considering rrdcached if that helps with some
of the disk contention issues, however after rolling out the initial layout
and observing for any performance issues. rrdcached requires to be at only
gmetad/web, so thats a simple change to do.
On Fri, Jul 26, 2013 at 5:48 PM, Adrian Sevcenco <adrian.sevce...@cern.ch>wrote:
> On 07/25/2013 07:37 PM, Nikhil wrote:
> > gmond aggregator is the node which has all the metrics (all the
> > gmond instances send the metrics to this gmond node), it need not be
> > restarted every time a reporting node(clients) are added/removed. The
> > problem happens when the aggregator node goes down; clients will not
> > be able to send the metrics then, so the choice would be to configure
> > multiple aggregators(lets say 2) and have them listed in
> > udp_send_channels of gmond configuration of every node. This means
> > all gmond clients will be sending the metrics simultaneously to both
> > the aggregators. Looking around got me got this links for better
> > explanation with pictures.
> >
> >
> http://books.google.co.in/books?id=X9haRQi85hkC&lpg=PA21&ots=n531RMIaSr&dq=ganglia%20unicast%20topology&pg=PA22#v=onepage&q=ganglia%20unicast%20topology&f=false
> thanks for info! I just ordered locally this book :)
>
> > These aggregators can then be used as source for metric data by
> > gmetad.conf. Since both nodeA and nodeB both have the same view of
> > the entire cluster metric, they would serve each other as a backup
> > copy.
> >
> > for example: data_source clusterC nodeAipaddress:<gmondport>
> > nodeBipaddress:<gmondport>
> >
> > gmetad always tries to connect only one node at a time and polls for
> > the metric data on tcp. If nodeAipaddress goes down or is not
> > reachable, gmetad will try the next node in the series that is nodeB,
> > for redundancy.
> k great!
>
> > You may want to read this thread also to get an idea for you to
> > consider the unicast topology you want to consider
> >
> >
> http://www.mail-archive.com/ganglia-general@lists.sourceforge.net/msg07265.html
> interesting mail (too bad that it didn't got an answer)
>
> At this point i am thinking to have a layers of aggregators (at the edge
> of clusters).. i would make the cluster gmonds (usually the gmonds on
> the torque and slurm servers) to join another multicast address than the
> one used inside the clusters together with 1 or 2 central gmonds (as
> datasurces to gmetad) to create a separate layer of traffic.
>
> I have only 100+ servers and in the near future i will not go over 200..
> Could the mcast chatter be a problem for the network?
> gmond estimate a bandwidth of 60 bytes/s per node and i have 3 clusters
> and a few separate nodes .. i would estimate in the upper gmond layer an
> chatter at the level of tens of k...
> Is this workable and efficient?
>
> Thanks a lot for your help!
> Adrian
>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
