You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mladen Turk <mt...@apache.org> on 2006/06/19 18:21:43 UTC
mod_proxy_balancer/mod_proxy_ajp TODO
Hi guys,
I'm would like to give few notes on the things I'm
currently working on, so that eventually no duplicate
work is done if someone already have similar things
on his drawing board.
1. Additional by business load balancing method
that will load balance on the actual load of the
beckend servers. The servers that have shorter reply
time will get more load.
2. Hot standby support. Something we have recently added
to the mod_jk that allows to have the 'hot-standby'
backend node, that sits there and does nothing until
all the other nodes fail.
3. CPING/CPONG support for the AJP protocol, for checking
the status of the backend server prior of sending the
data itself.
Comments?
Regards,
Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Mladen Turk <mt...@apache.org>.
Bill Stoddard wrote:
> Mladen Turk wrote:
>
> Once mod_proxy has access to lots of interesting bits, it can be
> programmed to detect and respond to anomalous application behaviors
Huh, the thing you are talking about is some sort of
rule based engine. Without having a virtual file system underneath
the httpd, I'm afraid something like that is impossible, or
at least unefficient. Once when we'll have the entire connection
pool mapped as a file system inside httpd we can do more sophisticated
things with balancing.
Last time I mentioned VFS, the goal was 3.0. I already have some
code inside sourceforge for couple of years, and just waiting the
'need' for it :)
Regards,
Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Bill Stoddard <bi...@wstoddard.com>.
Mladen Turk wrote:
> Bill Stoddard wrote:
>>>
>>> 1. Additional by business load balancing method
>>> that will load balance on the actual load of the
>>> beckend servers. The servers that have shorter reply
>>> time will get more load.
>>
>> +1 on the work, but I question the usefulness of this routing
>> algorithm. Does reply time (from the backend server)correlate with
>> resource utilization on the backend server in any but the most
>> contrived cases?
>>
>
> Yes, the algorithm is the average over the predefined amount of time.
> Further more Rainer Jung (our newest Tomcat commiter) has done a
> great job by rewriting most of the lb algos to be less spiky, so I
> plan to port his work to mod_proxy_balancer.
Ok Mladen, thanks for the info. If the algorithm can account for things like hung applications in the backend
(which would cause the reply time to spike) and place different applications in different balancing pools to
keep one bad application from causing all traffic to be routed away from an otherwise available server, then
it begins to become a usable routing algorithm.
What are some other ways to intuit backend server performance other than 'reply time'? Some thoughts... It
would be pretty slick to drive code into mod_proxy (or mod_lb, whatever) which could cause the server to
'request' performance stats from a backend server; The backend server would have to recognize the 'request'
for performance stats and be able to respond by either adding a HTTP 'performance stat' header to the response
(e.g. X-Performance-Foo: bar) or encase the performance stat data in a multipart mime message along with the
response data. The proxy could gather the performance stat data out of the X-Performance-Foo header (or strip
out the performance part of the multi-part mime response) and use the performance stats any way it wanted.
Yea, I know there are packages out there that use lan multicast to exchange data like this.
Ok, now going completely over the top.... wouldn't it be nice if mod_proxy could request arbitrary meta data
(not just performance data)to be collected from backend servers; the backend servers obviously need to be able
to understand and decode requests. ARM sort of does this for things like response time of every piece of code
in a transaction path. I am thinking even more general. =>Any<= piece of information available to the backend
server could be consolidated in a mod_proxy instance and acted upon at the scope of an entire cluster. Think
debug data, performance data, QoS data, at whatever granularity needed (application, server, cluster).
Once mod_proxy has access to lots of interesting bits, it can be programmed to detect and respond to anomalous
application behaviors (what's considered "anomalous" is tunable and maybe is dynamically adjustable). Maybe it
autonomically collect problem determination data and send alerts to the sys admin when anomalies are detected
or adjusts it's operating characteristics in whatever manner the admin decides is appropriate.
Bill
>
> Regards,
> Mladen.
>
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Mladen Turk <mt...@apache.org>.
Bill Stoddard wrote:
>>
>> 1. Additional by business load balancing method
>> that will load balance on the actual load of the
>> beckend servers. The servers that have shorter reply
>> time will get more load.
>
> +1 on the work, but I question the usefulness of this routing algorithm.
> Does reply time (from the backend server)correlate with resource
> utilization on the backend server in any but the most contrived cases?
>
Yes, the algorithm is the average over the predefined amount of time.
Further more Rainer Jung (our newest Tomcat commiter) has done a
great job by rewriting most of the lb algos to be less spiky, so I
plan to port his work to mod_proxy_balancer.
Regards,
Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Mladen Turk <mt...@apache.org>.
Bill Stoddard wrote:
>>
>> 1. Additional by business load balancing method
>> that will load balance on the actual load of the
>> beckend servers. The servers that have shorter reply
>> time will get more load.
>
> +1 on the work, but I question the usefulness of this routing algorithm.
> Does reply time (from the backend server)correlate with resource
> utilization on the backend server in any but the most contrived cases?
>
Well, this is the only way the balancer can deduct the load
of the backend server. If the backend server is highly loaded
or with lower performance hardware it response time will be lower
compared to the other participants in the cluster, so it will
get less load, and vice versa.
Of course the ultimate thing would be to actually receive the
feedback from the backend server about its actual CPU/memory
utilization, but thats not protocol independent.
Regards,
Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Bill Stoddard <bi...@wstoddard.com>.
Mladen Turk wrote:
> Hi guys,
>
> I'm would like to give few notes on the things I'm
> currently working on, so that eventually no duplicate
> work is done if someone already have similar things
> on his drawing board.
>
> 1. Additional by business load balancing method
> that will load balance on the actual load of the
> beckend servers. The servers that have shorter reply
> time will get more load.
+1 on the work, but I question the usefulness of this routing algorithm. Does reply time (from the backend
server)correlate with resource utilization on the backend server in any but the most contrived cases?
>
> 2. Hot standby support. Something we have recently added
> to the mod_jk that allows to have the 'hot-standby'
> backend node, that sits there and does nothing until
> all the other nodes fail.
Nice.
>
> 3. CPING/CPONG support for the AJP protocol, for checking
> the status of the backend server prior of sending the
> data itself.
Sounds good.
Bill
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Rainer Jung <ra...@kippdata.de>.
Henri Gomez wrote:
>
> For the load-balancing algorythm, do you plan to propose a bunch of
> pre build algos and let users select the right one for their use or
> allow externals modules ? We could see that like mod_jk / mod_proxy
> modules like apache modules does for HTTP...
A pluggable balancing strategy sounds nice. What I'm not sure about, if
the size of problem is big enough to justify the work.
All three existing strategies at the moment are based on the same basic
principles. All strategies use the same unsigned 64Bit to describe the
actual load value and there are three possible places where the values
are adjusted: pre request, post request and during maintenance (called
in regular intervals).
Busyness: increment pre request, decrement post request, no op during
maintenance
Traffic and Requests: increment pre request, no op post request, decay
during maintenance.
Traffic and Requests use different values to increment, Traffic uses the
amount of bytes transmitted, Requests always increments by one.
So to be able to implement interesting balancing strategies, the plugins
would need to be able to use request/response data, like performance,
load, error status etc.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/19/2006 10:37 PM, Mladen Turk wrote:
> Henri Gomez wrote:
>
>>
>> For the load-balancing algorythm, do you plan to propose a bunch of
>> pre build algos and let users select the right one for their use or
>> allow externals modules ? We could see that like mod_jk / mod_proxy
>> modules like apache modules does for HTTP...
>>
>
> Something like that was suggested by Jim Jagielski more then
> a year ago. I think that the problem is that this would be
> a module of a module, and something like that was never done
> for httpd. Not even sure if its possible.
Isn't this already the case right now? AFAIK the current lb algorithms are provider based.
So you can plug them in. From my understanding you can add further algorithms either to mod_proxy_balancer
or you can put them in an separate module that registers them separately.
Regards
Rüdiger
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
>
> For the load-balancing algorythm, do you plan to propose a bunch of
> pre build algos and let users select the right one for their use or
> allow externals modules ? We could see that like mod_jk / mod_proxy
> modules like apache modules does for HTTP...
>
Something like that was suggested by Jim Jagielski more then
a year ago. I think that the problem is that this would be
a module of a module, and something like that was never done
for httpd. Not even sure if its possible.
Regards,
Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Henri Gomez <he...@gmail.com>.
2006/6/19, Mladen Turk <mt...@apache.org>:
> Henri Gomez wrote:
> > Good to see that PING/PONG got such a good response here.
> >
> > When I added this to mod_jk it was just a quick way to detect hang
> > JVMs but it seems to many on the TC-DEV not a very usefull feature :)
> >
>
> And may thanks for such a great idea Henri ;)
> Actually its a great way to detect all those
> busy/broken/hanged/disconnected servers.
>
> I'm not sure how we could add that feature to the
> http/https protocol, the Rudiger suggested.
Well it's not easy to add this to http since HTTP stack could be
consuming but you could imagine some sort of magic URI handled quickly
by remote Tomcat (at the connector http/ajp side), and have some sort
of timeout associated to this request.
For the load-balancing algorythm, do you plan to propose a bunch of
pre build algos and let users select the right one for their use or
allow externals modules ? We could see that like mod_jk / mod_proxy
modules like apache modules does for HTTP...
Re: [info@ch2o.info] Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Mathieu CARBONNEAUX <in...@ch2o.info>.
why not add proxy hook like scheme handler do to that ?
_____
From: Ruediger Pluem [mailto:rpluem@apache.org]
To: dev@httpd.apache.org
Sent: Mon, 19 Jun 2006 23:04:55 +0200
Subject: [info@ch2o.info] Re: mod_proxy_balancer/mod_proxy_ajp TODO
On 06/19/2006 10:23 PM, Mladen Turk wrote:
> Henri Gomez wrote:
>
>> Good to see that PING/PONG got such a good response here.
>>
>> When I added this to mod_jk it was just a quick way to detect hang
>> JVMs but it seems to many on the TC-DEV not a very usefull feature :)
>>
>
> And may thanks for such a great idea Henri ;)
> Actually its a great way to detect all those
> busy/broken/hanged/disconnected servers.
>
> I'm not sure how we could add that feature to the
> http/https protocol, the Rudiger suggested.
To be honest I currently have no generic idea how to do this without
support from the backend. My point was more about that I would love
to see this health check integrated into the generic code of mod_proxy
and its connection pooling and let the protocol modules provide the code
that actually does the dirty work of the protocol specific aspects of such a
health check. This would make it easy to add health checks for other protocols
/ add better ones for protocols with existing ones. As said currently I would
only see two health check providers:
- CPING/CPONG for AJP.
- A generic TCP connection check.
But this would be open to further bright ideas.
Regards
Rüdiger
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/19/2006 10:23 PM, Mladen Turk wrote:
> Henri Gomez wrote:
>
>> Good to see that PING/PONG got such a good response here.
>>
>> When I added this to mod_jk it was just a quick way to detect hang
>> JVMs but it seems to many on the TC-DEV not a very usefull feature :)
>>
>
> And may thanks for such a great idea Henri ;)
> Actually its a great way to detect all those
> busy/broken/hanged/disconnected servers.
>
> I'm not sure how we could add that feature to the
> http/https protocol, the Rudiger suggested.
To be honest I currently have no generic idea how to do this without
support from the backend. My point was more about that I would love
to see this health check integrated into the generic code of mod_proxy
and its connection pooling and let the protocol modules provide the code
that actually does the dirty work of the protocol specific aspects of such a
health check. This would make it easy to add health checks for other protocols
/ add better ones for protocols with existing ones. As said currently I would
only see two health check providers:
- CPING/CPONG for AJP.
- A generic TCP connection check.
But this would be open to further bright ideas.
Regards
Rüdiger
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> Good to see that PING/PONG got such a good response here.
>
> When I added this to mod_jk it was just a quick way to detect hang
> JVMs but it seems to many on the TC-DEV not a very usefull feature :)
>
And may thanks for such a great idea Henri ;)
Actually its a great way to detect all those
busy/broken/hanged/disconnected servers.
I'm not sure how we could add that feature to the
http/https protocol, the Rudiger suggested.
Regards,
Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Henri Gomez <he...@gmail.com>.
Good to see that PING/PONG got such a good response here.
When I added this to mod_jk it was just a quick way to detect hang
JVMs but it seems to many on the TC-DEV not a very usefull feature :)
2006/6/19, Ruediger Pluem <rp...@apache.org>:
>
>
> On 06/19/2006 06:21 PM, Mladen Turk wrote:
> > Hi guys,
> >
> > I'm would like to give few notes on the things I'm
> > currently working on, so that eventually no duplicate
> > work is done if someone already have similar things
> > on his drawing board.
> >
> > 1. Additional by business load balancing method
> > that will load balance on the actual load of the
> > beckend servers. The servers that have shorter reply
> > time will get more load.
>
> Sounds good.
>
> >
> > 2. Hot standby support. Something we have recently added
> > to the mod_jk that allows to have the 'hot-standby'
> > backend node, that sits there and does nothing until
> > all the other nodes fail.
>
> +1
>
> >
> > 3. CPING/CPONG support for the AJP protocol, for checking
> > the status of the backend server prior of sending the
> > data itself.
>
> +1. Just one thought: I think it would be useful to have this 'health check'
> approach somewhat generic so that we can implement the call to it inside mod_proxy
> and its connection pooling itself (e.g. with providers supplied by schema
> handlers / modules). For AJP this would be CPING/CPONG of course and
> mod_proxy itself could offer a generic TCP connection 'health check' provider that simply
> checks the status of a TCP connection as far as this is possible without
> reading or writing data. This would be a very generic provider. Other protocol
> handlers could define other (better) protocol specific providers and
> just plug them in.
>
> Regards
>
> Rüdiger
>
> P.S: Are you in Dublin next week?
>
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/19/2006 06:21 PM, Mladen Turk wrote:
> Hi guys,
>
> I'm would like to give few notes on the things I'm
> currently working on, so that eventually no duplicate
> work is done if someone already have similar things
> on his drawing board.
>
> 1. Additional by business load balancing method
> that will load balance on the actual load of the
> beckend servers. The servers that have shorter reply
> time will get more load.
Sounds good.
>
> 2. Hot standby support. Something we have recently added
> to the mod_jk that allows to have the 'hot-standby'
> backend node, that sits there and does nothing until
> all the other nodes fail.
+1
>
> 3. CPING/CPONG support for the AJP protocol, for checking
> the status of the backend server prior of sending the
> data itself.
+1. Just one thought: I think it would be useful to have this 'health check'
approach somewhat generic so that we can implement the call to it inside mod_proxy
and its connection pooling itself (e.g. with providers supplied by schema
handlers / modules). For AJP this would be CPING/CPONG of course and
mod_proxy itself could offer a generic TCP connection 'health check' provider that simply
checks the status of a TCP connection as far as this is possible without
reading or writing data. This would be a very generic provider. Other protocol
handlers could define other (better) protocol specific providers and
just plug them in.
Regards
Rüdiger
P.S: Are you in Dublin next week?