On 07/25/2013 12:41 PM, Nikhil wrote: > Hi Adrian, Hi! > concerns in the architecture. Ganglia works well with the multicast > configuration as is by default. If the number of nodes in the cluster the thing is that the clusters (the worker nodes) are separated physically or logically (vlans or separate switches) by the rest of the network (access to outside or to storage elements is done via frontend or by having storages be with an interface in the broadcast domain of workernodes) .. so the multicast is usefull only inside the cluster.. but not outside....
> If you are going to follow unicast model for ganglia configuration, it > holds good too. > In unicast model, you do not really need any tinkering with these > options in gmond configuration, as all the metrics are just outbound to > the channel configured in udp_send_channel block. The designated gmond > node can again further be used as a data source by gmetad, since it will > have all the metrics of the cluster nodes send to it(them, dependingly > on number of the udp send channels configured) directly. ok, so i can do some kind of tree of data flow up to a single central gmond where gmetad will take data and arrange it per cluster definition from each gmond data flow? > There is a small gotcha though -- with the use of multicast topology in > ganglia large base installations and use of deaf mode (deaf = yes) > configuration on all nodes combined with a few set of nodes running in > 'deaf = no' mode, the gmond process need not be restarted every time you > add or remove any designated nodes. This can be a good operational win so that means that in unicast mode i have to restart gmond aggregator at each addition of a reporting node??? > With the unicast model, however, with the addition or removal of the > aggregator nodes, gmond process across the cluster have to be restarted > to read the new configuration since all the traffic is outbound via > unicast ipaddress. so given an list of 3 aggregators each with its reporting nodes 1 -> 2 -> 3 -> central any changes in the reporting to an aggregator implies a gmond restart for the coresponding gmond and ALL the upper gmonds??? (lets say a new node report to aggregator 2; this implies restarting 2,3 and central??) Thanks a lot! Adrian > > Thanks, > Nikhil > > On Thu, Jul 25, 2013 at 11:30 AM, Adrian Sevcenco > <adrian.sevce...@cern.ch <mailto:adrian.sevce...@cern.ch>> wrote: > > Hi! It is not clear to me what and how data circulate between gmonds. > So .. so for i understand this (for simplicity lets consider unicast) : > > 1. udp channels are used for actual data traffic (push architecture) > > 1.1 gmond nodes send data with the send parameters from udp_send_channel > > 1.2 the aggregating node receive data on parameters from > udp_recv_channel > > 2. tcp channel is used for interrogation by gmetad about the respective > aggregated cluster (data cluster - as the actual cluster groupping is > given by cluster directive and gmetad will aggregate data corresponding > to that) > > So, i would need some confirmation about my understanding as this info > is not explicitly spelled anywhere... > > And now the subject of the email : deaf and mute options are referring > ONLY to udp channels? > > deaf : do not receive data from other gmonds > mute : do not send data to other gmonds? > > the thing is that if i set deaf = yes there is no longer any listening > port, udp AND tcp ! so gmetad query cannot take place! > > if i set mute = yes, deaf = no the gmond will answer to nc localhost > 8649 (tcp) but will no longer send data to gmetad (host down in web > page) > > So .. what exactly is deaf and mute? > And is it possible to update the gmond.conf with more descriptive > options? (like send_data, receive data, answer_query) > > Thank you! > 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 > <mailto:Ganglia-general@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/ganglia-general > > -- ---------------------------------------------- Adrian Sevcenco, Ph.D. | Institute of Space Science - ISS, Romania | adrian.sevcenco at {cern.ch,spacescience.ro} | ----------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ 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
