Related Articles

By January of 2002, simulation testing and more research led us to revise our plans yet again. Gone were the plans for dedicated main site and forum servers. We were now planning on load balancing the entire site across the applications servers. And we were planning on creating a farm with more systems than was initially intended.

In December we had set up dual systems, but now AMD had their 1800MP chips ready, and our testing showed that we could definitely make use of as much horsepower as was available.

In all, we were to set up a total of 7 servers, including a load balancer to distribute the load between the 5 webservers. The last server was to be a database server. Because we didn’t have all the parts for all 5 webservers, we decided to build out the initial set up first:

3 webservers
1 database server
1 load balancer.

Balancing Act: distributing the load across the web farm

Initially, we were going to go for a software solution to provide for our load balancing needs. We looked at several solutions and one that caught our eyes was Linux Virtual Server. After reading up on this and doing extensive research, we realized that this would not be an easy task to accomplishment. We were entertaining several ideas and other solutions, mainly a hardware solution.

The problem with a hardware load balancer is primarily cost. We had to find a product that was both excellent in quality and price conscious. That’s when we stumbled across RedHill Networks and their Webmux products. The company came highly recommended from several sysadmins. Now, weeks after we first decided to load balance our farm using a Webmux, we know why these balancers come so highly recommended: they simply rock!

Like all load balancers, the Webmux offers an easy to use interface for setup and maintenance of your farms. We have to say, the Webmux truly has a superior web interface. The boys at RedHill Networks really took some thought to make it easy to administer, yet powerful. We can basically take out one of our servers out of the cluster in real time or if we think it’s under too much load, we can easily shift the load onto one of our other servers. Also, if one of servers happens to crash, the Webmux will automatically take it out of the cluster and when the server comes back up, the Webmux will automatically put the server back into the cluster. One great component we like about the Webmux is that it’s actually diskless. Who wants to worry about the hard drive failing on the load balancer? Since the Webmux is the first thing people access when they access the site, it’s best to ensure that the Webmux is up and running with no complications at all times. However, we encountered some initial problems setting up our farms, but tech support was extremely helpful and knowledgeable, even though we presented some unique challenges. After having gone through quite a bit of the hassle to setting up a software based load balancer, it was painfully obvious that the Webmux was a godsend for setup, and ongoing maintenance.

The risk of losing data

In any server crash, the greatest concern for us was loss of data and restoring access for the public.

The webforum applications server would be easily reinstalled in the case of a meltdown – it would store little more then the forum scripts, some easily replaceable graphics, and the forum logs. No irreplaceable or critical data would be on this server.

The database server, however, is constantly being written to. Most of the site exists in the form of database records; and we keep an awful lot of statistics in order to track popularity of forums, products, and product types. We were loathe to lose too much data from this server, so we decided on setting up a large IDE drive to store regular backups of database dumps. This strategy wasn’t foolproof, but we decided we could risk losing half a day’s worth of data.

The main site applications server was in a similar situation. The situation on this server differs from the forum server because we store a lot of graphics on this server – and should the graphics be lost, we would have MANY pages which display broken images, with little chance of ever restoring those images. However, the size of the images repository is significantly larger then database dumps (which we compress), and we could not afford the performance hit of a regularly scheduled backup. The decision was made to equip the main webserver with an IDE drive that would maintain backups at reasonable periods of time.