|
"Andreas J. Koenig" wrote:
>
> >>>>> On Sat, 15 Jul 2000 17:19:24 -0700, Horms <horms@xxxxxxxxxxxx> said:
>
> > What you describe is layer 7 switching - in this case switching
> > at the HTTP protocol layer. The LVS kernel patches do layer 4
> > switching - that is swiching at the IP protocol layer.
>
> > Wensong was working on some code a while back to do layer
> > 7 switching but I don't think any progress has been made on this
> > recently. Certainly it is code that needs to be written as
> > there seems to be a fair amount of interest in layer 7 switching.
>
> I have already said it the last time it came up: I guess the code you
> mean is just a combination of LVS with squid boxes. Squid does all you
> need with all the intricacies of the HTTP protocol addressed (and if
> you want ICP) and it has many years of experience. In squid
> terminology this is called a redirector
As you stated this only works for HTTP, and an L7 server can be very
valuable for a lot of other functions (including load balancing a farm
of squids in a more intelligent manner). I, for one, would love to see
application level features in the LVS code...and if it had handles to
user-space tools, then I would simply be in heaven.
A little discussion about why this could be such a grand thing:
The web-server case has already been touched on briefly in the original
mail that brought this up (and there is a lot to be said for being able
to balance among several different servers such that sites 1-50 are on
one server and 51-100 are on another, with no shared data between
servers...a definite cost savings and allows true persistence).
But the cache case is something I can talk a little more about:
Imagine, if you will...A farm of Squids serving a 100Mbit backbone link
(that could take about 5-10 very well configured and highly tuned high
end boxen). But now imagine that only potentially cacheable content
ever sees the cache? I.e. our director directly sends SSL, uncacheable
cgi, etc. without a Squid being involved. That immediately takes about
20-30% load off of our Squid boxen...so one or two boxes become
unnecessary. Next imagine that we have a user-space daemon that talks
to the director code and finds out what is being requested...it checks
against a cache digest for each Squid so the director will know if any
of our caches has the page, so that request goes to the right Squid
instead of the next Squid in the list. Suddenly we've removed the load
of each squid having to handle redirecting 80% of cache hits to another
cache. Now we can drop yet another cache out of our farm, and improve
response time to boot. Finally...sites that prove unviewable through
Squid can be routed past the Squid boxen at the URL level (currently one
must modify an IPChains rule or a policy router rule to not redirect
those problem sites at the IP level, thereby making uncacheable any site
found on the IP...possibly hundreds of virtual hosts). There, we've
just created a better than Cisco WCCP v2 router using free tools. I
love it when Linux out-Ciscos Cisco. Woohoo! ;-)
Of course...this is also the idea behind the CSS (Central Squid Server)
though I think it's development has slowed or stopped. And it also
lacks some of the more interesting features of using LVS such as the
hard bypass for specific sites mentioned above. And, as far I know, one
cannot use the CSS server as another Squid in the farm, as can be done
with LVS. Finally, CSS has the same flaws as Squid...like very hard
limits on performance and that some network things that run on port 80
(a particular stock ticker comes to mind) just will not work through a
Squid.
Lots of good and interesting things could be done with app level
switching. Half of the effectiveness in the above scenario would be a
Cache Digests and/or ICP enabled daemon...but without the kernel level
code to talk to, it just isn't possible.
Ok...I'm done rambling and fantasizing now. Going back to work. I just
wanted to put in my two cents about L7 switching.
--
Joe Cooper <joe@xxxxxxxxxxxxx>
Affordable Web Caching Proxy Appliances
http://www.swelltech.com
|
