|
I spent the past week trying to emulate certain aspects of a hardware load
balancer using Apache. It wasn't actually load balancing I was
interested in, but the ability of load balancers to pick URLs apart,
and redirect the client to different servers depending on the contents
of the URL.
At Georgia Tech, we're working with a large Java-based dynamic web
application (Campus Pipeline's Luminis portal software). From our
point of view, one problem with this application is that it's
monolithic: we can't scale it except by buying larger boxes; that
single server is also a single point of failure. To alleviate this
problem, We'd like to be able to front the Java server with static web
servers, which could handle the bits that don't have to be generated
dynamically. We're doing this without the cooperation of the central
application, so the easiest way to do this is by URL inspection by a
device sitting between the client and that server. URLs that indicate
dynamic requests get passed on to the Java-backed web server, while
URLs that can be served statically are redirected to static web
servers. It's something hardware load balancers do very well, but I'm
working at a state-funded university, and state budgets aren't too
good now. Perhaps we'll get what we need in the new year, but right
now, I needed to prototype something that would show that the
application would even work under these circumstances.
In any case, I was able to doing the URL redirection tricks I needed using
Apache's mod_rewrite package. (I'll write that up
another time.) But I had another problem:
the central application serves some things via HTTPS/SSL. Since those
a are a small percentage of the bits served by the application, I didn't need to pick those apart, but I did need to be
able to redirect those on to the Java-based server.
I had a devil of a time figuring out how redirect HTTPS/SSL connections. The mod_rewrite approach doesn't work, because
mod_rewrite works by examining each HTTP request and
changing it or forwarding it. Once an HTTPS connection is set up,
you can't examine the requests: they're encrypted inside an
SSL connection, which is the whole point of HTTPS.
In the end, what I needed was a port-forwarder. A
port-forwarder takes requests on a TCP port on one machine, and
passes them off to a TCP port on another machine. In this case,
I needed to forward all packets coming into port 443 on my pseudo load
balancer, and pass them on to the same port on the application server.
I was building this all under Linux, and Linux has very strong
facilities for routing and forwarding TCP/IP, so I thought that would
be the way to go. I spent many hours chasing that mirage. In the
end, I was convinced that it would be easier to get a Ph.D in physics than it
would be to figure out all the details of Linux routing.
For a time, I was convinced that I could forward HTTPS connection
using Apache's proxying facilities. I found an
intriguing
note that suggested it should be possible. It's possible that
might work, but I wasn't able to figure it out.
In the end, I settled on an open source package called
portfwd. It works on Linux, and claims to work on
Solaris as well. portfwd does exactly what says it does:
given a simple config file, it forwards all packets arriving at one
port on to another port, much like a wormhole out of a Star Trek
show.
With portfwd in place, my SSL connections were quickly
sped on to the appplication server, and all was well.
In the end, through a lot of dead ends, I was able to get what I
wanted done. I have a feeling that it would have been a lot easier
with a piece of hardware. If we can't get a new hardware
load balancer in the budget, perhaps we'll take up a collection
and get one on eBay.
12:07:18 PM 
|
