Mailing List Archive

Dejan Macesic wrote:
> Oh well, I guess I will have to wait for Theo to come up with a way to
> do half-proxying so I can be satisfied with the performance scaling :)

I think that "half-proxying," as you call it, is extremely complicated. There
is no way to do it at the application level without fairly sophisticated
kernel support for it. And it won't work at all with HTTP keep-alives.

Resonate and Arrowpoints use this method, but they each take a different
approach. They look at the first packet or so at layer 5 and then drop to
layer 3 to play a routing or a NATting game or a 3-way TCP handshake.

I don't see how it is feasible for mod_backhand to do that. That is something
that needs to be built much closer to the kernel. If I _were_ to implement
it, I would probably start by looking at how to modify the Linux IPVS code to
do my bidding.

Unless someone else knows differently, I don't think TCP/IP session hand-off
is possible (without extremely complicated kernel support) in an application
like mod_backhand -- it only sees the sockets at the application level not
RAW, so it is not exposed to sequence numbers, etc.

One of the most powerful features of mod_backhand is that it can direct
pipelined HTTP requests in the same TCP/IP session to different servers. If I
were to find some way to hand a session off to another machine, that machine
would have to know how to hand it back for the next HTTP request in the stream
-- because it may not be subject to the same load balancing rules.

Now, if you are only using the candidacy functions like byLoad and byAge, etc.
(not any custom ones), it would probably be very easy to expose the "resource
utilization information" (SysV shm segment) to IPVS and rewrite the candidacy
functions to work in IPVS. That way redirection of requests based on all this
information will happen on layer 3 and not layer 5.

You can't do session stickiness or make other complicated resource allocation
decisions, but you get the benefit of kernel space operation and _fast_,
_fast_ proxying (layer 3 NATting actually which should be similar to routing
speed.)

It also would only work on Linux and I know many people use mod_backhand in
clusters with Solaris and BSD machines.

I have no objections to implementing this if it can be done cleanly. Anyone
care to shed some light on how to do this?

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

I hope you aren't thinking I am being too difficult on mod_backhand :) I
did say I was spoiled...

I'll take a look at whatever an IPVS tools out there may offer.

Dejan



"Theo E. Schlossnagle" wrote:
> (snip)
> I don't see how it is feasible for mod_backhand to do that. That is something
> that needs to be built much closer to the kernel. If I _were_ to implement
> it, I would probably start by looking at how to modify the Linux IPVS code to
> do my bidding.
> (snip)