[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [hobbit] big brother replacement
- To: hobbit (at) hswn.dk
- Subject: Re: [hobbit] big brother replacement
- From: "Josh Luthman" <josh (at) imaginenetworksllc.com>
- Date: Fri, 2 Nov 2007 21:17:10 -0400
- References: <FB13116A8C464943B4A5436A616C95F80BCB0816 (at) rocexu01> <472BB636.3080400 (at) tmsusa.com>
Joe,
Do you have any support to any extent with BB? The main reason I switched
was that there was a mailing list to look to for support. Secondly, it
wasn't BB.
Josh
On 11/2/07, Sloan <joe (at) tmsusa.com> wrote:
>
> Deiss, Mark wrote:
> >
> > For a vanilla BB environment, you can have multiple BBDISPLAY entities
> > but the recommendation is that there is only one BBNET entity. A BBNET
> > server that is generating the pings out to the clients will be sending
> > the ping results to all of the BBDISPLAY entities (as defined on the
> > BBNET host). If you have multiple BBNET entities that ping the same
> > servers, you will be sending duplicated results as far as the
> > individual BBDISPLAY servers are concerned (the connection messages
> > will be renamed to the host being pinged). To support multiple BBNETs
> > in a non-race environment requires additional coding to carefully
> > direct the BBNET results to not trip over each other. The default
> > behavior is to pump them out to whatever BBDISPLAY is listed - you get
> > the race conditions when you want all the BBDISPLAY servers to monitor
> > all of the BBNET hosts (i.e. want BBNET to send their client-side
> > tests to the BBDISPLAY entities - this will result in the BBNET poll
> > messages going out to all the BBDISPLAY entities also).
> >
>
> Interestingly enough, we've been running redundant bb servers for each
> lan, without any concern for race conditions and while that has it's own
> peculiar behavior in corner cases, we've never seen any sort of real,
> intractable problems with it. The general consensus here is that
> redundancy is good, except for the notifications - we don't want to be
> notified twice for every incident, thus the so-called bb "failover"
> capability saves us that annoyance with no extra hacks required.
>
> I probably made it sound a lot more sophisticated than it really is - we
> really just have active/active BBNET/BBDISPLAY servers, with the
> delegation of BBPAGER decided by the failover status.
>
> It looks like Henrik has a good roadmap to get there in 4.3 from what I
> read here, so hopefully we've got our bb replacement at last. The only
> other concern is that we copy all bb notifications as snmp traps to
> netcool, but it looks as though that should be with a hobbit plugin.
>
> Joe
>
> To unsubscribe from the hobbit list, send an e-mail to
> hobbit-unsubscribe (at) hswn.dk
>
>
>
--
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
Those who don't understand UNIX are condemned to reinvent it, poorly.
--- Henry Spencer