Spreading the load
A common theme in these columns is whether or not open-source applications represent a viable alternative to commercial solutions. In some cases – web servers, databases, even operating systems – they clearly do, but in other cases such as groupware systems it isn’t quite so obvious. This month, we’re going to look at load balancing – something that’s considered a particularly hard-core networking application – and some of its open-source solutions. We’ll see there are different types of load balancer that operate at different system levels, and we’ll learn the difference between general-purpose load balancers and those for specific applications.
The idea behind load balancing is simple enough. You have a collection of users who want to access a particular resource across a network – the obvious example being access to a website – but other equally valid uses are emailing or downloading files from an FTP server. A number of servers are employed to implement this service, for resilience and scalability, but requests for the service need to be spread around the various servers.
The simplest type of load balancer is called a round-robin DNS, which works by switching internet addresses. The Domain Name Service is the internet service that maps names (say, www.pcpro.co.uk) to numeric IP addresses (say, 188.8.131.52). Sometimes, only a single IP address is associated with a named service, but you can have many addresses mapped to the same name (check the IP addresses for www.microsoft.com for an example).
Let’s say a service has two addresses – A and B – associated with it. Then when the DNS system maps the name to an address, it will serve responses alternately in the order A-B and B-A: that is, clients will either try address A followed by B or B followed by A, which balances the load between the two machines at the two addresses. It isn’t a perfect solution, though, because if machine B were to fail, half the clients would still be trying to connect to it first and only when it fails trying A. Once a client finds that address A works it won’t try B, but the initial connection will be slower.
A number of tricks can be applied to make this work slightly better. If a machine does fail, taking its IP address with it, you could bring up the same IP address on another machine but without the service attached. Then, when a client connects to the “broken” IP address it will receive a “connection refused” response and move on to the next IP address. You can also set up your DNS server with a short Time To Live (TTL) for each address, so that if a machine fails you can take it out of the DNS and know that information will only be live on the internet for a short time.
While DNS load balancing can be a good solution between hosting centres, it isn’t ideal within a cluster, and for that purpose people tend to use a dedicated hardware load balancer that accepts requests from multiple clients, dispatches each to a server and sends the server’s response back to the client. You can think of a hardware load balancer as a network switch that routes traffic based on its properties rather than destination.
This may sound simple, but it’s absolutely essential to understand how these load balancers work so that you can avoid unnecessary problems. Load balancers can work at various network layers – there are load balancers that work at link and even physical level but most of the ones we’re interested in work at the application and the network levels (Layer 3 of the OSI model).