|
Wensong,
The reason I asked if the code could be modified to do this:
> look at the start of the TCP data stream, by spoofing the initial
> connection and making load balancing based on what it sees there.
Is to enable us to do this:
1) Spoof the connection until we're able to grab the URL requested in
the HTTP header.
2) Based on that info make a decision as to which server should deal
with the request.
3) Fake the start of a TCP request to that server, making it look like
it's come from the original client, based on the info we got from
the original client in 1) And when we reach the end of the data we
recieved from 1) stop spoofing and hand over the connection.
Boxes like the Arrowpoint CS100/CS800 do this sort of thing, but their
configurable options for 2) isn't complex enough.
We also need to do this:
4) Forward UDP packets after looking inside the payload, seeing if it's
an ICP packet and if so forwarding based on the ICP payload.
The reason for 1,2 & 3 is to have deterministic location of cached data,
to eliminate redundancy in the cache system, and to reduce intra-cache
cluster communication. The reason for 4 is because the clients of our
caches are caches themselves - they're the UK National Academic root level
caches servicing about a 3/4 billion requests per month during peak
periods.
Also 2) can be used in future to implement a cache-digest server to serve
a single cache digest for the entire cluster to eliminate delays for
clients caused by ICP. (During peak periods this is large.)
The boxes from Arrowpint can do 1-3, but not 4 for example, and being
proprietory hardware...
Essentially the ICP+cache digest thing for the cluster is the biggest nut
- squid 2.X in a CARP mode can do something similar to 1,2 & 3, at the
expense of having to handle a large number of TCP streams, but wouldn't
provide a useful ICP service (it would always return ICP MISS), and can't
provide the cache digest service. (Or would at least return empty digests)
Hence the essential point of my question :
Would you be prepared to do any of the following:
- Tell me how difficult you think it might be to modify the LVS code
to do 1-4.
- Write the code to do 1-4 ? (Yes, I am expecting a no here! :-)
- Give me pointers as to the sort of books I should be looking in
order to modify the code myself to do 1-4. (I'm a competent
programmer, but not done a huge amount of 'raw' network coding,
but that sort of thing's never stopped me before :-)
> I have a good solution to use LVS to build a high-performance proxy
> server.
>
> request |-<--fetch objects directly
> | |-----Squid 1---->reply users directly
> |->LinuxDirector ---|
> (VS-TUN/VS-DR) |-----Squid 2
> | ...
> |-----Squid i
Fine (to an extent) for the case where requests are coming from browsers,
but bad where the clients are caches:
* Client sends ICP packet to Linux Director, forwarded to cache X
resulting in a ICP HIT reply, so client sends HTTP request to Linux
Director, which forwards request to cache Y, resulting in a MISS, Y
grabs from X, no major loss.
* However same scenario with X & Y flipped, results in ICP MISS, where
there would've been a cluster hit. Pretty naff really!
It's even worse with cache digests...
We've had to say this sort of thing to people like Alteon, etc too...
(Lots more details in an overview at
http://epsilon3.mcc.ac.uk/~zathras/WIP/Cache_Cooperation/ if you get
bored.)
Thanks for getting back to me, and if you have to time to answer my
questions above, many thanks in advance!
Michael
--
National & Local Web Cache Support R: G117
Manchester Computing E: Michael.Sparks@xxxxxxxxx
University of Manchester T: 0161 275 7195
Manchester UK M13 9PL F: 0161 275 6040
|
