running perlbal under heartbeat

[andreas....@gmail.com]

Is anybody running perlbal under heartbeat?

In other words: has somebody a good init.d file to share that has a
reliable 'status' function?

In other words: what would be the politically correct way to determine
if perlbal is running and feeling well?

Any other things to share for the combo of heartbeat and perlbal?

Thanks,
--
andreas

[Mark Smith]

> In other words: what would be the politically correct way to determine
> if perlbal is running and feeling well?

I've not heard of anybody doing heartbeat, but status is pretty easy
to obtain. If you've configured the management port, you can do
status checks on just about anything you can think of.

Some potentially useful values:

[dw @ DreamwidthStaging - ~/current/src/perlbal] -> echo "proc" | nc
-q 1 localhost 60000
time: 1233772897
pid: 17994
reqs: 170175 (+242)
.

Note the number of requests - assuming you're getting traffic at
reasonable intervals, you could have your health check be based on
that number of requests being received always increasing.

Also,

[dw @ DreamwidthStaging - ~/current/src/perlbal] -> echo "queues" | nc
-q 1 localhost 60000
dw-normal.age 0
dw-normal.count 0
dw-highpri.age 0
dw-highpri.count 0
dw-lowpri.age 0
dw-lowpri.count 0
.

Shows you queues for services. In this case, I have a "dw" service
defined, and nothing is queued. This is useful in general, maybe not
for a heartbeat (as queues are not Perlbal's fault and restarting
it/failing over won't help).

Anyway, there's other statistics available. socks, state, varsize, etc etc...

Another thing you can do is create a Perlbal service/plugin that just
returns a result to your request, i.e., not actually connecting to a
backend. Then you could healthcheck that to determine if Perlbal
itself is happily running along.

--
Mark Smith / xb95
smi...@gmail.com

[Ask Bjørn Hansen]

On Feb 4, 2009, at 10:33, andreas....@gmail.com wrote:

> Any other things to share for the combo of heartbeat and perlbal?

Just keep perlbal running on both hosts. (You can use heartbeat to
move the IPs if you want). Much easier than keeping track of when it
should run or not run. ("sysctl -w net.ipv4.ip_nonlocal_bind = 1" if
you need to bind to specific IPs). That way you can just keep it
running always under daemontools/supervise, runit or whatever your
preferred "keep it running" tool is.

Or is the trouble that you want to move the IP when perlbal fails? I
don't think I've ever had that happen other than when we messed up the
configuration... But if so then I suspect the most reliable indicator
would be talking to the management port and making sure it's alive
that way and/or setting up a "webserver" port and trying to request
something from there (that's how we monitor perlbal here).

- ask

--
http://develooper.com/ - http://askask.com/