ROUND ROBIN DNS

People looking to distribute load between two servers on the cheap might implement a Round Robin DNS solution. In Round Robin DNS, traffic is randomly distributed between two or more servers using DNS. This effectively splits up a Website's load, but the problem is, if one of the servers goes down, half of your traffic will see the site as down. There's no intelligence behind the load distribution.

Additional problems may result if you are running a shopping cart or any other session-based function on your site: If the network where your visitor is originating from is not caching DNS, you could find that they get shifted between servers during a single session. While this won't happen in most cases, as DNS caching is the norm, it would make filling out any multiple part forms, such as online order forms, impossible for those visitors. This solution is not recommended for most business uses because it could cause more trouble than it saves you.

LOAD BALANCING

Unlike Round Robin DNS, which randomly sends visitors to two different servers, Load Balancing utilizes either a hardware switch or software to intelligently direct traffic between two or more servers. Traffic can be routed between servers based on which server has a lighter load. More importantly, if one server goes down, a load balancing solution can route all traffic to the servers that are functioning properly.

Software solutions such as Macromedia's ColdFusion ClusterCATS and the Windows 2003 Enterprise operating system offer load balancing, but in my experience a hardware solution, such as a Coyote Point Equalizer load balancer series, operates more efficiently. This is because the Load Balancing process runs on a separate device from the servers, and thus does not generate additional overhead on the servers. This is a good idea since the servers are probably pretty taxed if a Load Balancing solution is under consideration in the first place.

ALTERNATIVE WEB & APPLICATION SCALING OPTIONS

Another option should be considered as an alternative to the two redundancy solutions described above. If distributing load is the goal rather than intelligent server failover, then splitting pieces of a Website onto different servers can be very effective.

By splitting one function onto one server, and another function onto another server, their load can effectively be split without having to invest in a Load Balancing solution. Another nice effect of this solution is that if one of the two servers crash, only part of the site will be impacted.

If one wanted as well, one could keep the code for both applications on each server, so that, in the case of a long server outage, one could activate the currently-down application on the other application's server and run both applications off one server until the downed server gets back online.

The appeal of this method is that it distributes risk. If one part of your site is down, other parts are still available for your customers to use. It's not right for everyone, but it can be a good intermediate step for many businesses, and with additional growth one can always scale the individual separated process to the Load Balancing framework as needed in the future.

DATABASE REPLICATION

Setting up high availability solutions for databases can be a bit more complex than doing so for Web and application servers. Database replication used effectively can be an excellent, low-cost redundancy solution, whether you are working with MySQL or Microsoft SQL databases. Database Replication copies data from one database (the master) to another (the slave) virtually in real-time.

If your primary database server crashes, you'll have a copy of your data on another server. The key thing to understand is that replication will not provide for automatic failover. Until you tell your Web and application servers to look at the secondary database server instead of the primary database server, your database will be unavailable. However, making this change is pretty easy to do, and you can have your database back online in short order.

While Database Replication is naturally only a redundancy solution, one can fashion it into a high-availability solution to provide faster performance for high-load sites. This can be done by having all database writes go to a master and all database reads come off of slave database servers. If properly set up, this will effectively split the database load, and should the master database server go down, one of the slaves can assume its place with a few configuration changes.

TRANSACTION LOG SHIPPING

In the Microsoft SQL world, Transaction Log Shipping is an alternative to replication. The main reason why one would use Transaction Log Shipping is because it puts the load of running the data transfer process on the server receiving the data, rather than the server sending it. Since the server sending the data is already under load as a live server that affects the performance that your customers feel, moving the process to the secondary server is beneficial (though the benefit may only be tangible under extreme high-load conditions). The drawback of Transaction Log Shipping is that it only runs the data transfer process every 15 minutes, so a business that uses this method risks up to a 15-minute loss of data.

DATABASE CLUSTERS

Database Clusters, such as the Microsoft SQL Cluster model, offer failover solutions for databases that can run automatically, as opposed to the replication model described above that required manual intervention. Two or more database servers share one common storage source, and should the primary database server fail, the secondary one will take its place in a heartbeat.

The advantage to a system working this way is obvious: no lost data if the primary database server crashes.

There are two significant drawbacks, however. One is that performance can suffer because the clustered servers cannot utilize processor cache the way a single server can. The primary server in the cluster must constantly be writing all data to disk in case it fails and the secondary server needs to take over for it. The other drawback is that further scaling the solution to handle more load will incur exponential rather than linear costs.

In my experience, Database Clusters are an excellent solution for low-volume but mission-critical setups that require absolutely no downtime, because the performance difference will not be noticeable in such a scenario. For businesses that require fast performance and redundancy, a better place to look would be at the replication model described above that involves splitting database reads between multiple slaves and database writes to a master.

CONCLUSION

Problems caused by growth are generally considered good problems to have. While this is true, snap decisions in crisis can lead to greater expenses and more problems down the road. Many companies will react under pressure of potentially lost revenue and sign up for or internally implement a hosting solution that can handle the load, whether or not that solution is right for their business in the long run.

Even if it functions properly, a solution can still be wrong for a business if it requires an infrastructure growth pattern that will incur diseconomies of scale in terms of cost as their Website is more and more successful. If proper forethought is given to growth before a snap decision is necessary, businesses save money and prevent headaches for their customers and for their employees who will be tasked to solve the problem.

The right growth plan for an individual business is not something that can be genericized in an article like this. It is something that should be developed in consultation with an expert on hosting infrastructure, paying particular attention to the needs and goals of the business in question.

Chris Kivlehan is with INetU Managed Hosting, a Web-hosting provider that specializes in managed dedicated hosting for businesses nationwide. For more information, call 610-266-7441, e-mail chrisk@inetu.net, or visit www.inetu.net.

Publication date: 03/20/2006