For many server deployments, load balancing using basic information about the clients and the services they want to reach is sufficient. See Content Switching for details on what you can do without breaking the bank.

However, as your needs grow more complex, this is no longer enough, and you’re going to have to look at making your load balancing decisions a bit more detailed. This is where we talk about Layer 7 load balancing: reading into the packet payload, rather than just addressing information to determine the best place to send the traffic.

Advantages of Layer 7 load balancing

So why isn’t it enough sometimes to just share traffic over a group of servers? Well, for a start, if all of the servers are equally likely to have to service a request, all the possible content will have to be on every server (or accessible, in the case of backend databases). Because different types of content have different requirements in terms of CPU usage, I/O throughput etc, you can get better efficiencies out of your servers by grouping them so that some handle transactions, while others just act as massive storage systems for serving up static pages, or are optimised for downloading streaming video, for instance.

It’s also unlikely that all your servers will be the same specification - again, this might suit the different types of content you want to serve: you might also want to make sure that some users are directed at higher powered servers, if they are premium customers, or are on your site to place an order rather than just browse.

So if you can place sessions on the best server for the particular transaction being carried out, you’ll be able to optimise resources and provide a better service.

Types of Layer 7 load balancing

To carry out more precise load balancing, the content switch has to be able to look into the payload of the packet. The main decision-making parameters are described below:

URL Parsing: This involves looking at the URL that appears just after the HTTP GET header, and sending the request to one of a group of servers based on that address. You might look for a particular string, so that requests go to one group of high-powered servers, while goes to another (I hesitate to suggest in any way less responsive) one. Or you could use the extension (.asp, .gif, etc) to point traffic at servers that have been optimised for serving that type of traffic.

HTTP Header interrogation: Your content switches can glean a lot of information by looking at the header information. The Host: header is actually the part of the overall HTTP address, and it’s separated from the rest (as of HTTP 1.1) into its own header field. So if you’re hosting multiple companies’ web sites, you don’t have to advertise multiple Virtual IP addresses for each, but just let the content switch direct traffic using the header information.

The User-Agent: header tells the content switch what type of browser your client has, so you can point them at a format that will suit theirs best - useful if you have lots of PDA users, for example.
And if you look after a multinational company, the Accept-Language: header again lets you send users to a server that’s written for them. This might be a nice touch if you’re serving your own company staff - it might be a huge competitive advantage if your servers are serving paying customers.

Cookies: A special case of header information, the cookies sent down from your servers to clients, either temporarily for the duration of that session, or permanently, to be stored on the users’ hard drives, give you more information to make routing decisions on. A cookie value (which can be more or less any string) might indicate that this person has used your site before, so that you can welcome them by name the next time they visit, or if it’s a service they’ve previously subscribed to, you can send them to the servers providing the services they’ve paid for.