|
|
[Running Multiple Lasso Servers in Parallel]
Greg Willits, May 12, 2007 Whether your application needs the capacity of multiple boxes or you simply want multiple machine redundancy for reliability, you can turn a low-cost (or an older) server into an effective load balancer to improve Lasso application performance. Apache 2.1 introduced mod_proxy_balancer which is designed to direct incoming requests to multiple possible target servers. It supports both simple count and more advanced weighted traffic algorithms. The latter one is useful for where servers of various capacities are available, so you can apportion the number of requests that go to your original 1Ghz server and your shiny new multi-core machine. One term to clarify. I am going to use the term parallel instances instead of distributed. This article isn't about distributed Lasso. We're not breaking a large application into pieces to run on multiple boxes. We are taking one instance of an entire application, and duplicating that application on many identically configured boxes. As indicated, you might be doing this to maximize service availability through redundancy, or you might need the processing capacity of several machines. I should also clarify that we'll be focusing on the Lasso layer of all this. If redundancy is your goal, you'll want redundant balancers and databases, but this article focuses only on creating redundant Lasso application code. The others are topics for another day. And now for my usual disclaimer: this technique comes out of the first time I've tried this. There were several little niggles to figure out along the way to accomplish our goals. There may be simpler methods than what I ended up with, but we tried to keep it as simple as possible. Feedback is good, so if you any, let 'er rip. We have several objectives. First, the obvious is to vector requests for a page to one of an arbitrary number of machines that can fulfill it. Second, the not so obvious objective comes from taking an opportunity to separate the delivery of static content from dynamic content. If you look at the figure on page 1, the original page request is going to come into the Balancer. That request is then forwarded to ServerX. We need to use ServerX to process Lasso code, but we don't need ServerX to deliver an image or a pure HTML static page. So, why waste time having those things processed by ServerX? If there's any content which the Balancer can deliver on its own, especially if that content can be cached, then we may as well have Balancer take care of that directly. (Obviously at some point Balancer gets overloaded too, but you'd want more than one Balancer in a fully redundant setup anyway, and at the scale we're talking about for most real-world websites, one or two modern servers delivering images and static HTML can deliver one very serious load of requests). The third objective is that we want to be able to run multiple applications. For example, we'd want to run production and beta versions of a site. Perhaps there's actually more than one application such as a public site and an internal-use-only company site or admin site. The configuration details are designed to take care of all these objectives. Files |
Articles |
Lasso Proxy Balancer