The World's Greatest Unsticky Organic Web Farm
The World's Greatest Unsticky Organic Web Farm
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
Act One: The Pledge
Dear Reader, consider yourself warned! The following paragraphs are not for the faint-hearted. Contained herein lies a feat of daring so bold, so extraordinary, so shocking that it mocks your very understanding of the universe. Best you turn away now, lest the fabric of your reality unravel as so many loose threads; leaving you standing bare and raving mad, forsaken in a wasteland of shattered beliefs.
I'm going to take a run-of-the-mill session-based web application and turn it into a load balanced web farm before your very eyes - all without making a single coding change to the application. That's right ladies and gentlemen, what you're about to witness is a load balancing technique so ingenious, so perfect that the web server - nay the very web application itself will not even know it is part of a web farm.
Each and every web server in the farm will think it alone is communicating with the client. Each and every web server will record a hit not from the load balancer, but from the client itself. And finally each and every web server will respond directly back to the client, utterly bypassing the very load balancer that brokered the request to begin with.
No special software will be installed on the web servers. No ISAPI filters. No plug-ins or other such nonsense will be required.
Understand! This is hardware load balancing I speak of, pure and simple. Hardware load balancing accomplished without the likes of Zeus, Coyote Point or even the F5 BigIP. This is organic web farming; hardware load balancing achieved with nothing more than two ordinary servers. And perhaps, a little bit of magic.
Act Two: The Turn
I have before me two Dell PowerEdge 850s, each with but a single Celeron processor and a mere 512 MB of memory. One could use nearly any kind of hardware. We, of course, have our corporate sponsorships to think of.
With a wave of my magic wand, Debian Sarge is installed on both servers. Do not be deceived by its meek and unassuming nature. Renowed for its robustness to hyperbole and found in all 12 world climate zones, Debian Linux stands ably by to perform any task at my bidding.
After a sprinkle of additions to the source.list file, I shall now utter the magic words to turn these servers into a high availability pair of load directors: apt-get install ultramonkey. Now with another wave of my wand, I apply the necessary configuration elements to enable the fabled load balancing method known as Direct Routing.
Observe! The default gateway of each web server remains unchanged (and it is not the IP address of the load balancer). Our web servers do not even know the load balancer exists. Requests are forwarded with their source IP address intact. Each web server replies directly, bypassing the load balancer entirely.
Act Three: The Prestige
Still not impressed? Take heed, for I have but two words that will surely sway even the most skeptical of skeptics. Listen carefully, for I shall not repeat myself. The words are View State. That's right, I have accomplished the implausible, the unthinkable. You'll find no Apaches in this web farm. I present to you Windows server 2003 and a Microsoft .NET web application.
How many in our audience have tried load balancing a .NET application? If so, then you surely have encountered the dreaded "View State is invalid" error.
If you "fixed" this error by enabling some type of sticky sessions on your load balancer, I applaud you with a tip of my cap and a knowing wink. An honorable mention of your efforts is in order perhaps, but let's be honest. That's not really load balancing is it? In the end each client is bound to a single server. Stickyness is only excusable should your application require SSL.
Behold!
I present to you the World's Greatest Unsticky Organic web Farm. Each incoming request is relayed round-robin style to the next server in the web farm. The View State remains persistent across each different web server, yet no special programming or state handling mechanism was employed. In fact, the application developers themselves do not even know the secret. And should one server be unavailable for whatever reason, our load balancers will automatically detect it and only send requests to the remaining live servers.
Act Four: The Secret
Everyone knows that a good magician guards the secret to his magic. I have guarded mine on our website (sssh, don't tell anyone).
Glen Kendell is a network architect and owner of Release to Production. He publishes a monthly newsletter called In-Production: Achieving True High Availability.