|
>>Oh, you mean the server pool patch we did at OLS 2003?? This is not
>>exactly it, but actually come to think of it, I should maybe drop the
>>hprio scheduler and actually use our old code.
>
> Yeah, I was thinking of that as I haven't actually looked over
> your patch yet.
Hmm, I dug out that code, at least what I found in my mail archives from
around the end of July 2003.
We added the IP_VS_SVC_F_OVERLOAD and the two RS pool destination flags
IP_VS_DEST_F_PERSISTENT and IP_VS_DEST_F_OVERFLOW. I'd like to take up
on this idea and finish my 2.4.x patch as follows:
o Find better naming schemes for the whole extension
o Write a per RS threshold limitation using the active + inactive
connections as a means to count the "sessions". This has no semantic
bearing regarding real sessions but allows one to kind of protect a
(web-)server from too many HTTP/1.0 or HTTP/1.1 hits.
o Add a per template threshold limitation using the amount of templates
as a means to count the "sessions". The semantic of a session here is
that we have sourceIP based sessions. Of course this does not account
for the old proxy problem.
Julian kindly added the IP_VS_CONN_F_TEMPLATE which would allow us to
write a function which iterates over the destinations and counts them
to have a persistent threshold limitation.
o The template threshold limitation superceeds the per RS threshold
limitation if both are enabled, also in case of lower bypassing the
lower bound.
o The expire_nodest_conn flag should be default for template spillover
pool servers.
o The switching of the service pool to the spillover pool must be done
atomically, also the failback to the working service pool. A means to
avoid switching spikes when one RS comes back must be implemented. If
not we get a ping pong behaviour in hype situations. Maybe the EST
scheduler could come in handy or some primitive adaptive algorithm.
o Enhance the reporting for ipvsadm to display flags; ITIM all the
service, connection and destination flags, which can be found in
ip_vs.h starting with IP_VS_*
o more, once I identify it during the tests
All this of course can only be done if I get the time assigned to work
on this. So far only the per RS threshold limitation was approved of the
management, which is crucial for a project we're involved with.
>>>I'll take a look over it and comment, but unfortunately it won't be
>>>for a few days.
>>
>>Take as much time as you need, I'm mostly seeking for obvious coding
>>mistakes and a discussion of the technology.
>
> Thanks, I'm tied up in the fallout from releasing 2.6.14 into Debian.
Good luck.
Best regards,
Roberto Nibali, ratz
--
-------------------------------------------------------------
addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355
http://www.terreactive.com fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG Wir sichern Ihren Erfolg
-------------------------------------------------------------
|
