Hi,

I'm wondering if pound could help with the following:

- configure two backends
- each backend should be dedicated to particular traffic, for example
  depending on a header or URL match

so far no problem, of course. But know, what happens, if one the 
backends goes down? Then all traffic should go to the alive backend, 
until the dead one comes back. I could play with priorities, of course, 
but than at least 1/9 of the respective dedicated traffic would go to 
the "wrong" server.

Would something like the following for do the trick?

# dedicated backend no. 1
URLGroup ".*"
HeadRequire SomeHeader "Regex1"
BackEnd 192.168.0.1,8080,1
EndGroup

# fallback backend no. 1
URLGroup ".*"
HeadRequire SomeHeader "Regex1"
BackEnd 192.168.0.2,8080,1
EndGroup


# dedicated backend no. 2
URLGroup ".*"
HeadRequire AnotherHeader "Regex2"
BackEnd 192.168.0.2,8080,1
EndGroup

# fallback backend no. 2
HeadRequire AnotherHeader "Regex2"
BackEnd 192.168.0.1,8080,1
EndGroup


That is, would the "fallback" groups ever been inspected, if the backend 
for the "dedicated" group is down? I believe it wouldn't, but is there 
any other approach for this? In case you wonder why I want to do this: 
I would like to direct all traffic from known robots to one backend, 
keeping the others free for human visitors.


Thanks,

Sascha
[...]

On Tuesday 18 May 2004 13.44, Sascha Ottolski wrote:[...]

Ingenious, but no, it doesn't work: the code first selects the correct 
back-end and only then connects (or tries to).[...]

Am Dienstag, 18. Mai 2004 15:16 schrieb Robert Segall:[...]

too sad, but at least it renders the man-page true :-)

how about adding a notion of a zero or negative prioritiy for backends? 
Meaning, backends with a prio of <= 0 would only come into play if all 
backends with a prio >0 are gone. Anyone except me thinks this could be 
useful? :-)


Cheers,

Sascha
[...]

Why not just set the priorities like to 100 for your main, and 1 for your
backend, and set your Alive setting to like 4 or so. This would effectively
most *most* traffic to your main server, and in the event your main dies,
will be diverted to your 'failover' since it's the only BackEnd still alive
in your URLGroup...Might accomplish the same idea?

Corey Sharrah
Chief Systems Specialist I
Internet Commerce Group, Inc.
corey(at)icgcorp.net

----- Original Message -----
From: "Sascha Ottolski" <sascha.ottolski(at)gallileus.de>
To: <pound(at)apsis.ch>
Sent: Tuesday, May 18, 2004 6:37 AM
Subject: Re: dedicated backends and fall-backs possible?


Am Dienstag, 18. Mai 2004 15:16 schrieb Robert Segall:[...]

too sad, but at least it renders the man-page true :-)

how about adding a notion of a zero or negative prioritiy for backends?
Meaning, backends with a prio of <= 0 would only come into play if all
backends with a prio >0 are gone. Anyone except me thinks this could be
useful? :-)


Cheers,

Sascha

--
Gallileus - the power of knowledge

Gallileus GmbH                    http://www.gallileus.info/

Pintschstraße 16                  fon +49-(0)30-41 93 43 43
10249 Berlin                      fax +49-(0)30-41 93 43 45
Germany



++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AKTUELLER HINWEIS (Mai 2004)

Literatur Alerts - Literatursuche (wie) im Schlaf!

Ab jetzt mehr dazu unter:
http://www.gallileus.info/gallileus/about/products/alerts/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Corey Sharrah wrote:[...]

It would come close, as I said. But unfortunately, you can't go better 
than 1:9:

BackEnd address,port,priority[,ha_port]
      Specify  a  backend server: address and port. Priority is 1 to 9
      and defines a weighting - higher priority servers get used  more
      often.  May only be used in an UrlGroup directive. If no servers
      are specified, then the specified URLs will be simply blocked.

And for me, I would prefer 0:9, as long as the "dedicated" backends are 
available.


Thanks anyway :-)

Sascha
[...]

AFAICT, the only way to get the effect that you want is to set up some
secondary HA solution for your back-end servers. The "-1" idea sounds do-able.
Robart can probably think of a logistical reason that it might not be viable. I
wouldn't use it only because, IMO, any webserver that's usable enough to direct
traffic to, even in the event of failure, is worth using in a LB group. It
might be useful for a "We're Down" server ... When we have that happen, we
manually throw a "switch" and reload a "We're Down" config file for Pound which
sends traffic to a catch-all Apache server running on the Pound Server itself
that has a "We're Down" message. 

Go digging in the code. Its /very/ easy to understand. I'd be willing to test
out a Patch. :)

CG

--- Sascha Ottolski <sascha.ottolski(at)gallileus.de> wrote:[...]



	
		[...]

On Tuesday 18 May 2004 22.53, Chris Gamache wrote:[...]

I'm not sure what a "logistical" reason would be. The simple answer is that 
this is a feature which is not really needed - there are ways of achieving 
same with existing means, without making the code base more complex than it 
already is.

The simplest way is to define the "reserve" server with an HA port:

URLGroup ".*"
BackEnd main.server,80,1
BackEnd spare.server,80,1,9080
EndGroup

Make sure nothing listens on spare.server:9080. Start something that accepts 
connections on it only when your main.server goes down (use your normal 
monitoring for that).

In general I agree that it doesn't make much sense to have unused servers - if 
they are good for hot back-up then they are also good enough for load 
balancing.[...]

Am Mittwoch, 19. Mai 2004 13:50 schrieb Robert Segall:[...]

I absolutely agree, and that wasn't my intention. My idea was, to send 
special traffic to somewhat dedicated servers (with all available 
servers being configured as active backends), and that pound had a way 
to change its scheduling, if backends seems to be overloaded or 
unavailable. Than the traffic would be redirected to the still alive of 
lesser loaded servers.

Okay, I'm dreaming, and I understand that you want to keep things 
simple, as well :-)


Cheers,

Sascha
[...]

On Wednesday 19 May 2004 14.23, Sascha Ottolski wrote:[...]

This is not about dreams but rather reality.

It was a conscious design decision to keep Pound simple. By simple I mean "the 
minimal set of features that is useful". Some people like it simple, others 
appreciate the resulting security. Still others use Apache.

Part of this approach was that we don't need dynamic scheduling of back-ends 
and queueing. You may argue that it is necessary (or maybe you would like 
having it), but for the majority of Pound users the current static system 
seems to be good enough. And as the inventor of radar said "best is the enemy 
of good enough".[...]