> How can I detect that backhand had failed? Better yet, how
> can I determine if backhand is alive? Sometimes, when a server went
> down for some reason, apache starts ok but backhand don't (child
> can't establish umbilical... etc). I need to know when this happens,
> and raise an alarm (we are monitoring our systems with Whatsup gold)
>
> Any hints?
Only ideas:
<off_topic>libbackhand<drool/></off_topic>
Granted this is hypothetical, but will backhand for apache 2 use
spread? I'm running into an increasingly large number if instances
where I'd like to be able to use mod_backhand with thttpd or be able
to fiddle with the granularity of doing relaying for vhosts (mass
vhosting):
I've given this a little thought (though that's about it) and will
likely implement this as a set of Berkeley databases via spread, but:
*) create libbackhand.so: has all of the nifty proxying bits for doing
relaying, system status information (ariba, ram, cpu, etc), and knows
how to do lookups into the subsequently describe database.
*) Use spread and its rules of subscriptions to msg groups
*) Use one BDB file for each spread group
*) Create a subdatabase called: members that contains the mapping of
spread member to IP/port/ariba.
*) Create a subdatabase called: vhosts that contains the mapping of
vhosts to spread member.
*) Create a utility that would allow for manipulation of this database
via spread.
*) Create the backhand daemon that:
*) sets up a named pipe that apache's children/thttpd use for
getting status information
*) handles sending heartbeat information to the cluster (heartbeat
includes cpu, ram, etc).
*) handles listening to spread msgs and adding data to the database
That setup should be webserver agnostic and should let you put up and
take down webservers/virtual hosts on the fly (it'd also obviate the
problem with having to SIGHUP the apache children after starting up
the daemon). Here's a little dream/idea:
*) incoming requests get tagged based off of the file type
(.rhtml/.rbx = mod_ruby request, .pl = mod_perl, .php = PHP, etc).
*) define resource pools as their own subdatabases that way you could
have a dedicated .cgi server that you wouldn't really care about (ie,
could run potentially insecure cgi scripts). Same logic applies to
vhosts though that way you don't have to rely on the byHostname.so
hack/trick. :~)
I can't think of another webserver that beats thttpd in terms of
scalability for sheer number of connections per webserver and think
that it'd be a phenominal start to a mod_backhand reverse proxy
server/buffer.
-sc
--
Sean Chittenden
> can I determine if backhand is alive? Sometimes, when a server went
> down for some reason, apache starts ok but backhand don't (child
> can't establish umbilical... etc). I need to know when this happens,
> and raise an alarm (we are monitoring our systems with Whatsup gold)
>
> Any hints?
Only ideas:
<off_topic>libbackhand<drool/></off_topic>
Granted this is hypothetical, but will backhand for apache 2 use
spread? I'm running into an increasingly large number if instances
where I'd like to be able to use mod_backhand with thttpd or be able
to fiddle with the granularity of doing relaying for vhosts (mass
vhosting):
I've given this a little thought (though that's about it) and will
likely implement this as a set of Berkeley databases via spread, but:
*) create libbackhand.so: has all of the nifty proxying bits for doing
relaying, system status information (ariba, ram, cpu, etc), and knows
how to do lookups into the subsequently describe database.
*) Use spread and its rules of subscriptions to msg groups
*) Use one BDB file for each spread group
*) Create a subdatabase called: members that contains the mapping of
spread member to IP/port/ariba.
*) Create a subdatabase called: vhosts that contains the mapping of
vhosts to spread member.
*) Create a utility that would allow for manipulation of this database
via spread.
*) Create the backhand daemon that:
*) sets up a named pipe that apache's children/thttpd use for
getting status information
*) handles sending heartbeat information to the cluster (heartbeat
includes cpu, ram, etc).
*) handles listening to spread msgs and adding data to the database
That setup should be webserver agnostic and should let you put up and
take down webservers/virtual hosts on the fly (it'd also obviate the
problem with having to SIGHUP the apache children after starting up
the daemon). Here's a little dream/idea:
*) incoming requests get tagged based off of the file type
(.rhtml/.rbx = mod_ruby request, .pl = mod_perl, .php = PHP, etc).
*) define resource pools as their own subdatabases that way you could
have a dedicated .cgi server that you wouldn't really care about (ie,
could run potentially insecure cgi scripts). Same logic applies to
vhosts though that way you don't have to rely on the byHostname.so
hack/trick. :~)
I can't think of another webserver that beats thttpd in terms of
scalability for sheer number of connections per webserver and think
that it'd be a phenominal start to a mod_backhand reverse proxy
server/buffer.
-sc
--
Sean Chittenden