Real World Computing
Spreading the load
As an aside, the Open Systems Interconnection (OSI) model has been pretty much swept aside by the ubiquity of the internet's TCP/IP protocols, but the layer numbers it uses are still useful when describing the different levels of network protocol stack. There are seven layers: Layer 1 is the physical layer (for example, optic fibre or copper cable); Layer 2 is the link layer (how packets are sent between devices on the same physical conductor); and so on up to Layer 7, which describes how applications communicate - for example, via the HTTP web protocol or SMTP mail protocol.
Network-layer load balancing
All internet services have well-known and globally agreed port numbers, and the service can be accessed by connecting to that particular port at a particular IP address. So, for example, the service www.pcpro.co.uk exists at address 194.70.234.209 on port 80. Services may be of two types: TCP connection-based protocols or UDP datagram services. To keep the explanation simple, we're going to concentrate here on TCP connection services such as the HTTP protocol.
Under HTTP, a client - a web browser such as Firefox or Internet Explorer - connects to a web server on port 80 and asks for a web page that's then returned to it. A network-layer load balancer works in this way. A client connects to an address that's actually the load balancer, which knows about a collection of web servers - the load balancer passes the connection (in some way) on to the web server, which returns its response via the load balancer. Simple enough, but the load balancer needs to be smart to make it work well. Obviously, it must know which servers it's switching connections to, but, more importantly, it needs to know whether they can service the requests, which means it needs to monitor their availability. If a server it knows about stops responding, it needs to divert requests away from that machine and switch them back if the server becomes available again.
Also, the load balancer needs to decide how it's going to switch requests to individual servers. The simplest method would be a round-robin algorithm, so with three servers A, B and C it would send a request to A, then one to B, one to C and then back to A again. This strategy works well if all your servers are identical, but if they're not you might want to send more requests to a more powerful server and fewer to a less powerful one. There are more complex strategies still, such as identifying the least busy server by monitoring response times - this is when the balancer times how long each server takes to handle a request, and routes future requests to the one that handles them fastest. This might appear to be an optimal strategy, but it can break down if different requests require different resources, so a machine that was lightly loaded could become overloaded.
Network-level load balancing is fairly simple, but to work well the balancer does need some knowledge of the application. For example, in switching web connections, the balancer needs some way of checking that the web server is there and working, which requires some understanding of the application.
While network layer switching works, much more can be done if the load balancer understands the application, a good example being a web application. Typically, web requests access services via their URLs such as www.pcpro.co.uk/news/ or www.pcpro.co.uk/reviews/. If your load balancer understands the application, it could, for example, route requests for news stories (via /news/) to a different server from reviews (via /reviews/). Moreover, it could monitor where requests come from and switch requests from the same client to the same server. While this may lower the resilience of the solution, in that an individual would always talk to the same server, it may make development simpler if, for example, the web application involves some form of state that may be difficult to share across multiple servers.
