Load balancers are usually present in large environments in which different servers (e.g., Web, application, database, etc.) are accessed by a large number of internal or external users. These servers are grouped in server farms that contain a number of servers that together offer a single service based on performance and redundancy.
The load is usually shared across all servers in a server farm and load balancer devices are used to distribute the load from the users to multiple servers. This operation is invisible to the end-user, as the load balancer balances the requests from the users to the servers and responds to the users on behalf of the servers. In this operation, the users think they are communicating with a single server.
Using load balancers also provides fault tolerance in situations in which a server from a server farm goes down. The other servers will still be used by the load balancer and the end-users’ service will not be affected. Load balancers usually offer fast convergence because they can quickly detect that a server is down and remove it from the list, thus using only the other healthy servers to transmit requests.
Based on the servers’ capabilities, load balancers can be configured to use them in different proportions. Some of the common load balancing algorithms include the following:
- Round robin (each request is sent to a different server)
- Weighted round robin (requests can be sent more often to specific servers based on weights assigned to them – unequal load balancing)
- Least connection (requests are sent to servers that are not busy with other connections)
- Weighted least connection (the same as least connection but with weights assigned to servers)
Load balancers are also capable of TCP offloading, which means that the device sets up a TCP connection to each server and uses it every time. The alternative would waste more time and resources and would require the load balancer to initiate a TCP handshake with the servers every time it had to forward a user request.
Load balancers also include dedicated hardware components specialized for different functions, like SSL offloading (i.e., the encryption/decryption process is managed by the load balancers instead of the servers). Another function is caching, which allows the load balancers to answer some user requests faster using the built-in cache instead of requesting the data from the servers. Usually only the most frequent requests are cached because of memory limitations.
Load balancers also offer QoS capabilities (e.g., prioritizing certain services over others) and content switching (provides load balancing on the Application Level, where certain servers may only use certain applications).
Load balancers can be deployed in the following modes:
- Router mode
- Bridge mode
- One-armed or two-armed mode
Router Mode
Router mode is one of the most popular implementation modes and in this mode the Server Load Balancer (SLB) device routes between the outside subnets (toward the clients) and the inside subnets (toward the servers). In this scenario, which is illustrated in Figure 21.1 below, the services addresses are typically globally routable public IP subnet addresses, and the external subnets represent the public network while the internal subnets represent the private network:
Figure 21.1 – Load Balancer Router Mode
The load balancer routes between the public and the private networks and the servers will use the SLB’s inside address as their default gateway. Since the replies that come back from the servers (i.e., responses to clients) pass through the SLB and the SLB changes the servers’ IP addresses to the appropriate addresses, the end-users do not know there is an SLB device in the path because they do not see the real IP addresses of the servers and internal applications. This process is similar to NAT (Network Address Translation) technology. Load balancer router mode is easy to deploy, works with many server subnets, and is the recommended mode to be used for a majority of appliance-based content load balancers.
Bridge Mode
Load balancer bridge mode, shown in Figure 21.2 below, is also called the inline mode and it works by having the SLB device operate as a transparent firewall. In this situation, you need an upstream router between the clients and the SLB.
Figure 21.2 – Load Balancer Bridge Mode
In this design, the physical servers are in globally routable IP subnets, and the IP addresses on the SLB can be in the same or in different IP subnets. Each one of the inside server farms (i.e., the Web server farm, the application server farm, or the database server farm) has to be in a single IP subnet because the SLB will modify the MAC addresses associated with the virtual IP (VIP) to the specific MAC address of a physical server in order to direct traffic to the appropriate server.
This design method is seen most often with integrated load balancers, such as the Cisco Content Switching Module or the Application Control Engine in a 6500 or 7600 chassis. However, if the physical servers have to be deployed in a redundant configuration, you should be aware of the implications of Spanning Tree Protocol and how it will affect the devices and the backend servers. It is typically easier to configure the SLB device in router mode because troubleshooting STP can become very complicated.
One-Armed/Two-Armed Modes
The one-armed/two-armed modes are pretty popular approaches as well and they involve running the SLB device in an out-of-band fashion, similar to an IDS sensor that analyzes mirrored traffic from a switch. The load balancer is connected to a switch with one or two links, but it is not placed directly in line with the traffic as is the case with the router and bridge modes presented previously. These types of modes are illustrated in Figure 21.3 below:
Figure 21.3 – Load Balancer One-Armed/Two-Armed Modes
In a one-armed topology, the SLB and the physical servers are in the same VLAN (or subnet), while with the two-armed approach, the SLB device routes the traffic to the physical server subnet, which can also be a private subnet with NAT.