This article describes the basic load balancing scenario used by one of my employers. It’s fairly typical of a modern, high-traffic web site. What follows is a fairly basic description of our load balancing architecture.

There is a complex set of redundant routers and firewalls surrounding this architecture and providing mail and DNS services to the company. I won’t go into that here, because it’s not relevant to the discussion. I do describe the basic structure of the network of hosts that serve HTTP requests from customers. Herein the main web address is referred to as http://company.com/.

When a TCP connection attempt is made to coolcompany.com, port 80 (standard HTTP port), an F5 Networks BigIP load balancer is the machine that services the connection. The BigIP serves two main purposes. It balances the load among several web servers and it handles SSL encryption and decryption.

Load Balancing

The first of these functions is load balancing. Each HTTP request received by the load balancer (the BigIP) is relayed to one of several web servers (referred to as a server pool). There are many ways of choosing which machine in a pool gets to service the response, but we choose a simple round-robin approach: each request in turn is assigned to the next machine in the pool.

Of course, nothing can be as simple as that. In fact, the load balancer does a bit more. First, it looks at the request URI and determines if the request is for a static or a dynamic resource. Static resources are things like images, stylesheets and HTML pages. Dynamic resources are things like JSP pages, Java servlets, and Struts actions. Requests for dynamic resources go to the app server pool, and other requests (static resource requests) go to the static server pool. In our environment, Resin is the HTTP server running on the machines in the app server pool, and Apache is the HTTP server running on the machines in the static server pool.

There’s one more wrinkle in the load balancer’s operation. If a request for a dynamic resource comes in with jsessionid information (either in a cookie or in the URI), then the load balancer sends that request to the same app server machine to which it has sent other requests for the same jsessionid.

SSL Proxy

The other thing the BigIP does is act as an SSL Proxy. If an HTTPS request comes in, the BigIP provides the site’s public SSL certificate and manages the decryption of the request and the encryption of the response. This relieves the web servers of the burden of SSL management: they only ever server unencrypted requests on a single port. Their configuration is simplified because they don’t need to store certifcates and their performance improves because they’re not handling the data encryption.

While this provides a substantial overall benefit, it does introduce some difficulty in the handling of HTTPS requests on the part of the app servers. Some of the articles in the standards proposals section discuss this in detail.

Overal Motivations

The general motivations driving these solutions are maximization of performance and minimzation of configuration complexity.