Scaling Out Web Tiers

Scaling Out Web Tiers – Part II

April 2nd, 2009 by Rich H.

This is Part II of the article “Scaling Out Web Tiers.” Click here for Part I.

Now that you’ve selected a load balancer, it’s time to think about what type of servers will reside behind it.

There are two basic schools of thought when selecting dedicated hosting servers for load balanced traffic: you can go “large” or you can go “wide.” A typical example of going “large” would be two really beefy servers with redundant disks and power supplies, sky-high specs, and prices to match. This will handle a fairly large amount of load, and the redundancies in the hardware prevent a simple power supply or disk failure from halting your server.

The caveat with this configuration is that Web servers fail for a lot of reasons unrelated to hardware. A memory leak/bug in the custom code that drives your site, or the underlying software stack can bring even the most well-spec’d server to a grinding halt. Since you only have two Web servers, when one is down, you’ve lost 50% of your capacity. This could leave your visitors “standing in line” to view your site if the remaining server cannot handle the entire load.

Going “wide” has several key advantages and generally overcomes the caveats of going “large.” An example of going “wide” would be selecting three or more lesser-spec’d servers with little or no hardware redundancy. This keeps the price per server down to more digestible amounts, handles the same load, and the “wide” methodology carries several key technical advantages. With three servers, you only lose 1/3 of your overall capacity during a single failure or ¼ of your overall capacity with four servers. This adds up to higher overall performance and lesser impact for your site visitors.

As you scale “wide” in your web tier, you also open up more options for rolling out new code and security patches. In a Web tier with three or four servers, you could temporarily stop sending load-balanced traffic to one server, update your code base/install patches and perform testing by accessing your site on that server directly to ensure the updates are complete. Once done, you begin sending load-balanced traffic to the server again, and repeat the process for the remaining servers. The entire update/rollout process can be completed with little or no impact to the performance of your site.