> > Sorry for being confusing. You are correct, the BB server is outside the
> > LVS. The BB client running on the director pings the RIPs using one
> > interface (eth1) and the BB server using the other interface (eth0).
> And the load balanced traffic is routed through both or how do you run
> the LVS, LVS-DR or LVS-NAT?
We do LVS-NAT. VIP on eth0, RIPs on eth1.
> Well, how long did you test with a client not being on a director? I'm
> just asking because further down you mention something like once every
> week it fails.
Our BB display server also makes connection attempts (to other servers) and
it never has a problem.
> > That's my question too. I don't see why it ever fails, but the facts are
> > that runs successfully every 5 minutes, and only once every week or so
> > it get stuck on something.
> Could check your crontabs to see if there is anything that will generate
> a high CPU load when being executed?
As it happens, my system logs were being parsed about the time my last
freeze happened. Unfortunately I didn't record the time previous pings got
hung, but 1) I don't believe it was concurrent with any other processing,
and 2) the system logs on this box are pretty small, and processing hardly
takes any cpu cycles. In fact, my director has never seen more than 5%
sustained load, and I've never seen more than a 10% spike whenever I've
> Do you monitor the in/out bytes on your LVS server? Could you probably
> check that?
Nothing much over a couple hundred KB/sec, and no spikes when my last ping
> > That works fine whenever I try it by hand. And like I said above, it
> > fine for BB most of the time too.
> Strange, strange. Could you tell me again, if BB is spawning a ping
> process for every RS in parallel or is it spawning a ping for the next
> RS after the first one has returned something (serialized monitoring)?
I *believe* BB spawns its pings in serial, but I'm not positive.
Thanks for the help, I'll look into seeing if I can find anything else that
occures at the same time as these glitches.