* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [070330 12:47]:
> Use different multicast addresses for each cluster,
> unless you are sure the multicast can't leak
> from 1 cluster to another.


I have -- I've picked 239.2.100.71 (dev nodes), 239.2.101.71 (test
nodes) and 239.2.102.71 (prod nodes).  This differes from pretty much
all other gmond instances that we have floating around as far as I'm
aware.


> Remember that when you list hosts after the data_source
> for gmetad.conf that is for resilience only. You do not have to
> mention all nodes in the cluster there.


Yes -- my intention is to make sure that if the node I'm trying to poll
for data is down, to be able to get info on any other nodes that might
be up by checking them in turn.  At the moment, all of these are 2 or 3
node setups, so this seems to be the best way to manage this at the
moment.


> Given your symptoms it might be something else. I suggest you
> consider using unicast initially rather than multicast until
> you get everything going. (upd_send in gmond.conf pointing to
> a nominated headnode on each cluser, then data_source from that).


So, working with dev (because there's only two nodes, 1003 and 1006),
I'd define my udp_send_channel like this:

udp_send_channel {
  host = lsora1003
  port = 8649
  mcast_if = eth4
}

and then, do I need to do anything for the udp_recv_channel?  Also,
do I need to do anything on the other host (lsora1003) for udp send
or recv channels?


> And netcatting hosts can be very instructive (e.g. nc lsora1006 8649).
> Are all expected hosts listed in the nc output?
> Unexpected hostnames? (gmond does reverse dns lookup to make hostnames).
> Is the cluster name returned by nc different for every cluster?
> (the clustername in gmetad.conf is not used).


When I do this, I can see data, but when I run this from lsora1003
against lsora1006, the timestamps on the XML for lsora1003 doesn't
update very much.  I'm not running iptables or other filtering software
on the nodes, and they're on the same subnet of our network.


-Mike
-- 
Michael Steeves ([EMAIL PROTECTED])

Reply via email to