I'm wondering what the proper use of backend would be
for my situation in which I want alice to respond to *all*
requests unless she is down, and in that case i'd like bob
to handle all the requests. The config I currently have is:

ListenHTTPS 200.200.200.200,443 /var/www/pound/certs/bob_and_alice.pem
        Alive 15
        UrlGroup ".*"
        BackEnd alice.some.net,80,9,80
        BackEnd bob.some.net,80,1,80
EndGroup

Of course when alice came back online/became available I'd like the requests to
shift
back to her only.

Is there a priority which says never use unless there is nothing better
available?
Does a priority act as a metric?
	--jordan

Jordan Lederman wrote:[...]
 From man:

---cut---
Use the priority to affect  the  load  distribution  among 
unequal-performance servers.
---cut---

Am Mittwoch, 17. November 2004 17:18 schrieb Jordan Lederman:[...]

I would like to have such a feature as well :-)

however, what about providing a different ha_port on each server (i.e. not the 
webservers main port, but one of a little "ha-server"). if alice is alive, 
bob's ha-server should be able to know about this and keeps its ha_port down. 
if alice has a problem, bob's ha-server should be able to see this situation 
and open its ha_port. that way pound uses bob only if alice is down.


Hope it helps,

Sascha

On Wed, Nov 17, 2004 at 05:24:39PM +0100, Maciej Bogucki wrote:[...]
I read that. I was *hoping* that there was a feature of the implementation that
allowed
for transparent failover. Where is the proper place to make a feature request?
I apoligize 
if this information is already shown on the homepage (http://www.apsis.ch/pound/) but the page
won't load for me. It very repeatedly only gets 1/3rd of the page, and stops
right around step 4 or 5
of the installation. I've tried with firefox, opera, and wget with the result
of:

jlederma(at)darkstar:~$ wget http://www.apsis.ch/pound/
--12:24:22--  http://www.apsis.ch/pound/
           => `index.html.3'
Resolving www.apsis.ch... 80.254.173.44
Connecting to www.apsis.ch[80.254.173.44]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33,819 [text/html]

16% [==========>                                                           ]
5,552         13.22K/s

jlederma(at)darkstar:~$ wget http://www.apsis.ch/pound/
--12:24:32--  http://www.apsis.ch/pound/
           => `index.html.4'
Resolving www.apsis.ch... 80.254.173.44
Connecting to www.apsis.ch[80.254.173.44]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33,819 [text/html]

16% [==========>                                                           ]
5,552         13.22K/s
jlederma(at)darkstar:~$


Anyway, if this is the proper place than let me propose the following two
feature requests:

Header additions:
	I'd like [some of] apache's mod_header functionality included in pound which
would allow
arbitrary headers to be added to outgoing backend servers. This would allow,
among other things, easy
proxying of backend applications which depend on a certain Host header.
mod_headers allows for the
actions of 'set', 'append', 'add', and 'unset'. More info here: http://httpd.apache.org/docs/mod/mod_headers.html

Metric Implementation:
	I'd like a metric to be avaialable for use in order to choose between multiple
backend servers. This
would easily allow for transparent failovers.


 	Thanks, 
		--jordan

On Wednesday 17 November 2004 17.18, Jordan Lederman wrote:[...]

To take things in order:

- there is no way to have a fail-over server: all servers defined are used if 
available. The percentage of requests sent to each is defined by the 
priorities.

- you could simulate the desired behaviour: use the HA port and set up an 
additional monitor program. If the main server is not available have it open 
the HA port so that the hot back-up appears to be available. Not clean, but 
works. BTW in your config file the HA port is not required - it is usually 
defined as different from the regular port; Pound will happily monitor just 
the regular HTTP port if no HA port was defined.

Finally, the big question: why? What possible benefit do you get from having a 
server running but not using it (beside the moral satisfaction)? I have asked 
this question several times, but I have yet to get an answer.[...]

On Wednesday 17 November 2004 18.52, Jordan Lederman wrote:[...]

We probably could add a header, but would refrain from changing existing 
stuff: Pound is supposed to be a transparent proxy. I'll put this on the 
wish-list for 2.0.

Headers can already be removed.[...]

On Wed, Nov 24, 2004 at 11:30:10AM +0100, Robert Segall wrote:[...]

The reason why is failover. In my case pound is used to wrap many older, legacy
apps that wouldn't natively work with ssl in ssl. These same applications
wouldn't work in a mux'd enviorment, so what we generally do is build/configure
a hot-standby. A machine just like the primary that gets data updates from the
primary
periodically. The secondary is to be used in the case the primary fails, but
you don't want to distribute requests between them. Having a true metric in
pound would allow this.
	--jordan

On Wednesday 24 November 2004 13.21, Jordan Lederman wrote:[...]

Let me see if I understand correctly: your legacy application can deal with 
the concurrency inherent in being accessed through a Web server (which will 
happily allow any number of concurrent requests) but can't deal with the 
exactly same requests coming from two separate servers? I find it rather 
confusing.

Separate issue: I am not a native English speaker, so may I ask you to explain 
what is it you mean when you say "metric"? For me (and my dictionary) that 
would be "a method of measurement", which doesn't really make sense to me in 
context.[...]

> What possible benefit do you get from having a[...]

I agree it's not necessarily a critical feature, but
I've pondered the question when it has come up before
and I think I understand why people ask, so here's my
crack at it.

Some possible scenarios, in no particular order:

1a. Perhaps there are dedicated image servers that
probably run lighttpd/thttpd/boa/etc, don't log, don't
use database connections, etc. I'd prefer all the
image requests to go the image servers instead of my
Apache/PHP/logging/database-connection-using app
servers, but if the image servers all inexplicably
fail, I'd rather the image requests go directly to my
app servers than nowhere at all.

1b. A variant on #1a is if I have a server dedicated
to pound. In a pinch, if all the backends were down, I
could serve the site off the pound server as well, but
I probably wouldn't want to do that unless there
weren't any other available backends.

2a. Perhaps I generally run production environments on
separate servers from QA & training environments to
keep QA code or unexpected QA load from affecting
production. But if the production servers failed, I'd
rather the qa & training hardware get used than none
at all.

2b. A variant on 2a is if I run a lot of different
non-production environments, each with its own server
to reduce the chances of one test environment
affecting another. For example, if I've got
qa1.blah.com through qa8.blah.com on appserve1 through
appserve8, it might be nice if each of those 8
different qa environments could all failover to
appserve9. That way they'd be redundant if necessary,
but not forced to share any resources the other 99.9%
of the time.

3. Possible you could have customers who have
contracts stating they get X dedicated servers or
something, in which case you would want to be able to
share a failover box across multiple sites and/or
customers without either violating the contract or
having to have an extra server for every
customer/site.

4. Possible that the server I have available for
redundancy is just plain slow. Perhaps it's an older
server, perhaps it's doing something else most the
time (running cron jobs, processing logs, generating
reports, whatever), or maybe it's behind a slower or
more expensive connection for some reason. For
example, a lightly trafficked heavily dynamic site
with a 3ghz server is going to generate certain kinds
of pages much faster than a 300mhz server. In that
situation, someone could want to process requests on
that slow server only if the primary server was down,
instead of having to process 10% of all requests on
the slow server just to be prepared for the <1% chance
the primary server goes down.

5. Possible that for whatever reason your app doesn't
work with more than 1 app/webserver at once (perhaps
writes things out to local files, etc). In that case,
someone might want to use pound just for failover. Of
course there are other ways to do that & that's not
necessarily pound's primary purpose, but pound could
be more elegant if you're managing a lot of such
servers. (Sounds like this could be Jordan Lederman's
situation)

Not necessarily very common scenarios, though I do
deal with some of these. Anyway, as I said, I get by
just fine & it's not a personal concern of mine, but I
figured I might as well pass on what I'd come up with.

- Michael



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com

On Wed, Nov 24, 2004 at 02:01:55PM +0100, Robert Segall wrote:[...]


No, I'm sorry for the confusion. First of all when I say metric what I mean is
something like how a routing metric works. In the world of routing, a metric is
used to find the superior path -- make a choice. The final metric is computed
by the application, in this case pound, and is based upon application
determined values + [not actually addition here] a user inputted number. Pound
would use availability as its part of the equation and factored with the metric
in the Backend directive it would make a choice to use one backends over the
others. It is very similar to the Priority system you have in place.

 What I am saying is I currently have this scenario:


user  --http--> primary legacy application --> primary db
                secondary legacy application --> secondary db


(note 'primary' and 'secondary' means that the secondary is a duplicate of the
first, ready to be used in case the primary is broken)

So now the user is accessing the old legacy application via plain old http. The
secondary db is synced from the primary every so often, and in the case of
a failure in either of the primary systems, we would manually change something
(dns or routing) to make the secondary appear as the primary. As things stand,
putting pound into the mix makes:


user --https--> pound --http--> primary legacy application --> primary
db
                                secondary legacy application --> secondary
db

Which attains my primary goal of securing this communication but my secondary
goal of automating failover to the secondary system is not accomplished
via what pound is currently capable of. With a metric implemented I would be
able to say "If the primary is reachable use it. If not, use the secondary". 
	--jordan

On Wed, 2004-11-24 at 06:01, Robert Segall wrote:[...]

Another issue (to add my log to the fire) might be NFS.  We used it at
my last job to create a cluster of web servers.  Alas, I didn't know
about pound back then, I ended up using LVS.  But NFS isn't without its
quirks and problems, but the alternatives are a) doing an rsync every 15
minutes (bleh), and b) a true cluster filesystem (I have yet to get one
of those to work).  One problem we ran into was users or proprietary
applications (Miva Merchant, I'm looking at you) that used a local file
as a database - intolerably slow over NFS and prone to locking issues
with multiple web servers.

So I can see why someone would *like* to do load-balancing, but facing
problems like these perhaps can't, but would at least like to have high
availability.  Personally, I'm just hoping lustre or opengfs matures
enough to be usable by the time I have more than one server (I use pound
only for the ssl-proxying right now).

Sean

On Wednesday 24 November 2004 15.19, Jordan Lederman wrote:[...]

I find this even more confusing - please help me here.

In routing algorithms there is indeed a "metric", defined as "a commonly 
accepted measure of the cost of sending a packet over a certain link or 
path". This fits my understanding of "metric" as "a method of measurement". 
Funnily enough, a routing algorithm may decide to send a packet over a high 
cost path regardless of how you defined it - exactly like Pound may use a 
low-priority server.
[...]

This also introduces a bunch of other issues: what if you have four "primary" 
and two "secondary" servers? At which point does which secondary come into 
play: when some primary fails or when all the primaries have failed? How many 
secondaries come in at that point? When would they stop being used - when a 
primary is back on-line or when all primaries are back? Now repeat the above 
questions for other numbers.

As an aside - have you considered using something like heartbeat or LVS for 
your switching? They were created precisely for your type of situation.[...]

Thanks for your reply. I agree that some of these scenarios are conceivable 
(though sad - we're talking about raping a perfectly decent reverse proxy 
just to accommodate a bad application design). Now for the big question: what 
should the semantics be?

Assume you have several primary servers and several secondary: when does a 
secondary come on-line (on failure of one primary or failure of several 
primaries or all primaries)? How many of the secondaries come on-line at that 
point (one/several/all)? How long do they stay on (until one/several/all 
primaries are back)?[...]

Robert Segall wrote:[...]

   I would like to add to this as well. I am not a pound user, but am 
following this list because I might become one.

   If my problems can be solved by other means, I'd love to know...

   I also have the desire to use a system with a live server and a hot 
backup that never receives requests unless the live one is down.

   In my case, it is because of heavy caching. The live server is 
serving the results of a lot of complex database queries with a lot of 
processing and caching.

   The live server carries a lot of data in memory, and writes to the 
database every few minutes. Upon writes, some of the cached data is 
recalculated and cache is reloaded. But in general, all the user 
requests to the live server present complex data right out of memory caches.

   The mirror has database replication from the live server (mysql), but 
the replication works one way, and would be very difficult to handle if 
it was coming from either server. The knowledge of when to update the 
memory caches would be very complicated if the database was changing all 
the time from methods other than the web app. (which knows which caches 
need updating)

   What I think I want is just the mirror to sleep until it's needed, 
then as soon as it would receive any requests, it would do a one time 
cache refresh and then consider itself the ONLY server until I get in 
there to repair the dead box.
[...]

On Thu, Nov 25, 2004 at 12:17:21PM +0100, Robert Segall wrote:[...]

How's this sound: Set options fields which have the effect
of value and goal (although these are horrible names to use) which
have the effect of the using backends as needed. The rules would be:

Goals must be identical across backends.
Values must be identical per tier.
tiers are not switched unless no higher tier option exists.

BackEnd address,port,priority[,ha_port][,value,goal]


Primary/Secondary config:

#primary A
BackEnd address,port,priority,80,10,10 
#secondary B
BackEnd address,port,priority,80,1,10

If A dies, B takes over. Goal is not reached so message should be
logged saying so.


Redundant Cluster config:

#primary A
BackEnd address,port,priority,80,5,10 
#primary B
BackEnd address,port,priority,80,5,10 
#secondary C
BackEnd address,port,priority,80,1,10
#secondary D
BackEnd address,port,priority,80,1,10

If A fails, B continues.
If A returns, A and B are now in service.
If A & B fail, C and D take over.
If C Fails, D continues.
If A and/or B returns, C and/or D are pulled out of service and A and/or B are
used.



Hot Spare:

#primary A
BackEnd address,port,priority,80,5,10
#primary B
BackEnd address,port,priority,80,5,10
#primary C
BackEnd address,port,priority,80,5,10
#secondary D
BackEnd address,port,priority,80,1,10
#secondary E
BackEnd address,port,priority,80,1,10

Goal is 10 so only A & B are used by default. 
If A fails, C comes into play and B & C continue. 
If A returns, C leaves play.
If A, B, and C are unavailable, than D and E come into play.


--jordan