Re: Failover to side B without switch back to side A when it's reachable again.

2010-01-28 Thread Hank A. Paulson

On 1/27/10 9:42 PM, Willy Tarreau wrote:

Hi,

On Wed, Jan 27, 2010 at 04:15:30PM +0100, Franco Imboden wrote:



Hi,



I have a question concerning a failover scenario of a webservice where no
cookies are supported.



as long as nothing happens, all requests should be routed to side A. If side
A is not reachable anymore, the proxy should switch to side B.

so far, everything works fine.

The problem now is, that if side A becomes reachable again, in this specific
scenario all requests should still be routed to side B (and not to side A)
until side B fails.



Is this possible to solve with haproxy without using cookies ?


No I don't see any way to do this because it requires an internal
variable to keep state of whom was alone last. I got this question
6 or 7 years ago, and I wanted to implement a sticky failover,
until I realized that it can make sense only in active-backup
setups, which are the least common ones.

More recently I wanted to implement a feature I called buddy servers.
The idea is that a server could designate which one must take its traffic
when it's down. Most often this will be a backup server. It might be a
good starting point for the feature you need, because we could declare
in the first server that even if it's up again, it must not take traffic
as long as its buddy is there.

Regards,
Willy


You could do it with a separate health check process. Have it know when the 
traffic to its web server stops, then it starts returning down - whatever 
haproxy requires for the health check to return to be understood as down. It 
never changes back to an up response until reset by someone/something.




[ANNOUNCE] haproxy stable 1.3.23

2010-01-28 Thread Willy Tarreau
Hi !

after 3.5 months of minor updates and bugfixes, here comes haproxy 1.3.23.

It fixes a few minor to medium issues :
  - several annoying config parser issues causing incorrect or imprecise
error detection/reporting, as well as one bug when dealing with long lines.

  - a weakness in the request cookie parser, which could make it skip the
persistence cookie if preceeded by a syntactically incorrect one. The
symptom is a loss of persistence when such an incorrect cookie is set
in the browser from some Javascript code (such an incorrect cookie
cannot be learned from a server, the browser would reject it).

  - cookie domain check in the config has been relaxed because many sites don't
work if we strictly apply the RFC, which browsers don't apply at all either.

  - health checks would sometimes detect a failure while it's just that the
server has sent a reset that is reported as an asynchronous error by the
local TCP stack. The check method has been modified so that the error is
only considered if the recv() call fails, thus improving the chances to
get the response in such conditions.

  - the halog tool failed to build on non-x86 machines due to a CPU-specific
optimisation that was left by accident.

  - several doc fixes to more closely match the config parser.

It also brings three new minor features :
  - support for the new request-learn option for appsession cookies. This
allows haproxy to learn a cookie from the request with servers which
recreate the same session ID and do not present one in the response.

  - backport of the force-persist feature. It allows one to define rules
to grant access to a down server. This is especially useful during server
updates, as you want to remotely check your site on the new server as if
you were a normal visitor, without enabling the server for normal visitors.
This can be achieved using force-persist and cookies. Please refer to the
doc for more information.

  - backport of http-check send-state. When set in a backend, haproxy sends
a lot of useful info to the servers while checking them. A header contains
the server's state, its weight, the total farm's weight, the number of
current requests, its queue size, etc... This can be used by a health-check
agent on the server to detect failures, report up-nolb-down transitions to
an operator, decide to allocate more resources or to disable some slow
services, etc...

Since 1.4 is getting closer to a release, it is very probable that no new
features will be added to 1.3 (bugs will still be fixed though). For this
reason it'd be good idea for distros to be released soon to update to this
one as the last 1.3 and only merge bug fixes from now on.

As usual, you can find the whole thing here :
   site index : http://haproxy.1wt.eu/
   sources: http://haproxy.1wt.eu/download/1.3/src/
   changelog  : http://haproxy.1wt.eu/download/1.3/src/CHANGELOG
   binaries   : http://haproxy.1wt.eu/download/1.3/bin/

Of course, if you noticed anything abnormal, please report it here.

Willy




config file simplification?

2010-01-28 Thread duncan hall

Quick question (request) I hope,

I have a backend group of servers containing a 20 servers, eg:

server VM330230a 172.16.10.2:80 cookie A330230a check inter 15s rise 3 
fall 1 slowstart 60s minconn 25 maxconn 50 weight 10
server VM330231a 172.16.10.3:80 cookie A330231a check inter 15s rise 3 
fall 1 slowstart 60s minconn 25 maxconn 50 weight 10

...

would it be possible in future versions to move some of the repeated 
part of the configs into a single line in the back end? In my case it 
would be great to be able to just specify once for the backend the 
following:


check inter 15s
rise 3
fall 1
slowstart 60s

Thanks

Duncan