On Mon, Mar 14, 2011 at 8:49 PM, g...@desgames.com <g...@desgames.com> wrote:
> That's something I considered, but the ultimate problem is that the backend
> service we're running (gearman) sometimes gets backed up with requests from
> our web servers. In this case, the server still looks 'up' (I *think*) but
> requests from PHP scripts are held up waiting for the gearman server to
> process the request and close the connection. So having the backup server
> option in this case wouldn't work, I don't think, *unless* 'backup' servers
> in haproxy will cut in if the maxconn setting is exceeded. If that's the
> case, then I suppose we could set the maxconn limit to a low setting and
> have the queue option. Do you know if this behaviour exists in haproxy for
> backup servers?
>
check out acl's.
you can create acl's off almost any ruleset. in your frontend(or
listen) stanza, if one acl is true, use your normal backend. if
another is true, use your backup.
there might be better ways to do this in just the backend itself also.
> Thanks,
> Guy
>
> On Mon, Mar 14, 2011 at 5:34 PM, David Birdsong <david.birds...@gmail.com>
> wrote:
>>
>> On Mon, Mar 14, 2011 at 8:15 PM, g...@desgames.com <g...@desgames.com>
>> wrote:
>> > Actually, I should clarify something. We don't really actually want the
>> > 'black hole' situation I described - instead, what we want is for
>> > haproxy to
>> > accept and queue the messages that come in from the requesting server,
>> > but
>> > to still deliver them when a backend server becomes available. In this
>> > way,
>> > the requesting process can continue executing and not having to wait for
>> > a
>> > response. Obviously, we intend to do this only for async type calls.
>>
>> super hacky, but how about setting up an xinetd service as a backup
>> server. haproxy switches connections over only when your service is
>> unavailable.
>>
>> the xinetd service could capture each request and play them back
>> later..this service could be as simple as a script:
>>
>> #!/bin/sh
>> REPLAY_LOG_DIR=/var/replay_logs
>> cat >> ${REPLAY_LOG_DIR}/$(date +%Y_%m_%d)
>>
>>
>> >
>> > On Mon, Mar 14, 2011 at 4:52 PM, g...@desgames.com <g...@desgames.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> We have a tcp service we'd like to proxy requests to, and we were
>> >> investigating haproxy as a possible solution for our requirements. So
>> >> far,
>> >> it doesn't seem like haproxy is suitable but I thought I'd run it by
>> >> the
>> >> community to confirm what I understand to be the case.
>> >>
>> >> What we want is a proxy that will accept tcp connections on a specific
>> >> port and always send a tcp 'ok' response to the requesting process
>> >> whether
>> >> or not there is a backend server available. If a backend server (we
>> >> only
>> >> plan on having one at the moment) is available then we want the request
>> >> passed transparently through to the backend server. If the backend
>> >> server is
>> >> *not* available, then we want haproxy to operate as a kind of 'black
>> >> hole',
>> >> and just accept whatever is sent to it, dumping it to the equivalent of
>> >> /dev/null. Basically, acting as an equivalent of the backend server.
>> >>
>> >> Is the above possible with haproxy? Based on what I've read in the
>> >> configuration documentation, the answer is no. However, there are a
>> >> *lot* of
>> >> options in there so I thought perhaps there's some obscure setting
>> >> which
>> >> would allow this to work.
>> >>
>> >> Alternatively, does anyone know of a utility that could do what we
>> >> want?
>> >>
>> >> Thanks,
>> >> Guy
>> >
>> >
>> >
>> > --
>> > Guy Knights
>> > Systems Administrator
>> > DES Games
>> > www.desgames.com
>> > g...@desgames.com
>> >
>
>
>
> --
> Guy Knights
> Systems Administrator
> DES Games
> www.desgames.com
> g...@desgames.com
>
