www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Theo E. Schlossnagle" <je...@omniti.com>
Subject Re: modproxy load balancer
Date Thu, 26 Jun 2003 14:30:25 GMT
Graham Leggett wrote:
> In order to complete the request, a function:
> proxy_run_scheme_handler(r, conf, url, ents[i].hostname, ents[i].port);
> is run. This either connects to hostname and port, and asks for URL 
> (forward proxy), or if hostname and port are NULL, it connects to the 
> host in URL (reverse proxy).

I am not sure how you invision the hooks being loaded at runtime.  If they are 
their own modules, and just place themselves in the mod_proxy chain, then I 
can piggyback on the the builtin module inititalization functions.  Otherwise, 
I need someway to initialize my module.

> I think the hook should go inside the proxy_run_scheme_handler() 
> function, and the hooked code should accept an URL (or a hostname and 
> port) and convert it into a connection, which is passed back to the rest 
> of the code path.

I don't think the hook should be responsible for making the connection.  I 
think the hook should be solely responsible for listing, in order of 
preference, where connections should be established.  In perl syntax:

   { 'protocol' => 'http',
     'IP' => '',
     'port' => '80' },
   { 'protocol' => 'http',
     'IP' => '',
     'port' => '8080' },

then mod_proxy should be responsible for taking that list and making real and 
usable connections out of them.

> The hooked module can then do what it likes with connection failure: 
> retry with a round robin connection, etc until it is happy (or unhappy).
> The existing code can be pulled out of what's there now, and moved into 
> a simple module called "proxy_dns" (or something).
> One other thing that must be looked at is module ordering:
> Take for example the case where you want to support "sticky" 
> connections. You would probably want to watch either a cookie or a 
> request variable called JSESSIONID, and make sure that all requests with 
> that session id go to that server.

mod_backhand can do that now because it has access to the whole request_rec 
structures in 1.3.x.  So, similar access would be very useful.

My approach to mod_backhand 2.0 was to:
   (a) take all systems code, shared segments, etc. and place them in a 
standalone process
   (b) throw out 80% of the code and use mod_proxy :-)
   (c) rewrite the candidacy functions for the new API.

> But what happens if the sticky server is down? The module would say 
> DECLINED and hand it on to the next module, which might be proxy_dns, 
> whatever.

Perfect.  Also, it is important for each "module" or hook to be able to see 
the complete list that resulted from the previous hook.  See this for a clear 
idea of what I mean:


Obviously the API here would need to change a tad, but if the ServerSlot 
structure contained all the information (IP:port) that mod_proxy needed to 
establish a connection, the API actually would pop right in.

Having this ability will allow someone to mix and match modules to recall 
achieve complex proxy decision making that matches their needs.  And if it 
doesn't do _exactly_ what they want, they can write a very small link to put 
in the chain instead of writing a big hook that reinvents a lot of working, 
tested code.

> We need some way though of telling proxy that proxy_sticky comes before 
> proxy_dns.
> Perhaps we can have a directive the same as in mod_cache, which 
> specifies the order in which the backend modules are tried.

This ordering is important for mod_backhand integration.  Most of the 
candidacy functions (that reorder and augment the "list of hosts") are very 
simply and complicated balancing logic is achieved by cascading them -- and 
order matters :-)

Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone:  +1 410 872 4910 x201     Fax:  +1 410 872 4911
1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7

View raw message