On Sun, Feb 6, 2011 at 11:20 PM, Ronny Lindner <
net-spi...@users.sourceforge.net> wrote:
> > > The first test with 4 hosts and one realm worked just fine. Then I
> > > tried to use two realms, but I didn't get data from the new realm.
> > >
> > > Here is my setup:
> > >
> > > - Loc1 (behind NAT - my home internet line) monitors localhost
> > > (arbiter) and a webserver with public IP
> > > - Loc2 (poller + scheduler on the aforementioned webserver)
> > > monitors 2 servers only visible from this server
> > >
> > > I get data from Loc1, but Loc2 sends no checkresults. The scheduler
> > > for Loc2 received the configuration snipped and the poller made some
> > > checks. There was even a (debug) message that a service in Loc2 had
> > > problems (which was true) - but this status was not submitted to
> > > Loc1.
> > >
> > > There were constant TCP pings from the Loc1 arbiter to the Loc2
> > > scheduler/poller - but it seemed the scheduler sent no check
> > > results. Does it try to communicate directly with the arbiter? Then
> > > what IP address is it using? The arbiter only knows its private LAN
> > > IP address! Forwarding a port from my public IP address to the
> > > arbiter is no problem, but how does the scheduler in Loc2 know this
> > > public address?
>
The connexions will be :
* Arbtier -> all others elements
* Broker -> all other elements (but not the arbtier), if the LOC2 is a
sub-realm (parameter realm_members) of LOC1
* Reactionner -> same than broker
* scheduler1 -> no body :) (it just receive connexions)
* poller1 -> only open connexion to the scheduler1
* scheduler 2 -> same than scehduler1
* poller2 -> only scheduler2
There should not be connexion from LOC2 -> LOC1, only LOC1->LOC2 (if the
LOC1 got as member LOC2, if not, only the arbiter will connect to LOC2, and
the broker and reactionner won't).
So I don't think port forwarding will be useful.
Is LOC2 a sub realm of LOC1? Can you look in the log of the broker. It will
see where it try to connect (all schedulers?). What do you expect in
"problems (which was true) - but this status was not submitted to Loc1" ? Is
it for reactionner/broker? If so, they should be in a higer realm than LOC2,
so LOC2 hould be a realm member of LOC1.
Jean
> >
> > > I hope you understand my problem ;)
> > >
> > In fact all is working if I understand right The arbiter is just here
> > to send configurations. It will not see any "check" nor
> > notifications. What do you have in LOC1? Is there only the arbiter?
> > Or are there a scheduler and a poller?
> >
> > In fact the arbiter is above all realms, so if there are no
> > schedulers/pollers in the LOC1, this realm is void in fact.
> >
> > If there are a scheduler and a poller in it, they should have the
> > hosts that are in LOC1, and the scheduler LOC1 should raise logs
> > about possible service errors if there are.
> >
> > Did I understand it right?
>
> mmm, I don't think so.
>
> Realms: Servers
> -----
> Loc1: s1, s2
> Loc2: s3, s4
>
> on s1: arbiter, scheduler-loc1, poller-loc1, reactionner, broker
> on s2: scheduler-loc2, poller-loc2
>
> s1 is a VM in my LAN with a private IP address
> s2 is a server on the internet
> s3, s4 are also servers on the internet, but only reachable from s2
>
> There is a connection from the arbiter on s1 to scheduler-loc2 and
> poller-loc2.
>
> Does the scheduler-loc2 try to open a connection to arbiter, broker
> or reactionner on s1? This is not possible at the moment, because as I
> said the arbiter only knows its private IP address, not the public
> address of my internet connection. Forwarding some ports at the router
> to s1 is no problem, but how does the scheduler on s2 know the public
> IP address of my internet connection?
>
> Now I think the problem is clearer.
>
> There might be ways around this problem but the layout of the company's
> network is similar to the test configuration I used - just bigger...
>
> Bye, Ronny
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
