<h1>Load Balancing (III)</h1>

Before we go any deeper into the abyss of all the techniques and algorithms used in the load balancing world it is important to clarify some concepts and notions and take a look at the most used load balancing terminology. The target audience of this blog is supposed to know what the OSI Model is and therefore I won’t even bother to explain what the layers are...  

Server health checking

Server health checking is the ability of the load balancer to run a test against the servers to determine if they are providing service:

• Ping: This is the most simple method, however it is not very reliable as the server can be up whilst the web service could be down;

• TCP connect:  This is a more sophisticated method which can check if a service is up and running like a service on port 80 for web. i.e. try and open a connection to that port on the real server;

• HTTP GET HEADER: This will make a HTTP GET request to the web server and typically check for a header response such as 200 OK;

• HTTP GET CONTENTS:  This will make a HTTP GET and check the actual content body for a correct response. Can be useful to check a dynamic web page that returns 'OK' only if some application health checks work i.e. backend database query validates. This feature is only available on some of the more advanced products but is the superior method for web applications as its will check that the actual application is available.

Layer-2 Load Balancing

Layer-2 load balancing (also referred as link aggregation, port aggregation, ether channel or gigabit ether channel port bundling) is to bond two or more links into a single, higher-bandwidth logical link. Aggregated links also provide redundancy and fault tolerance if each of the aggregated links follows a different physical path.

Layer-4 Load Balancing

Layer-4 load balancing is to distribute requests to the servers at transport layer, such as TCP, UDP and SCTP transport protocols.  A typical network router simply sends incoming packets onto the appropriate IP address on its network but a layer 4 router is on the Transport Layer and makes decisions on where to send the packets distributing network connections from clients who know a single IP address for a service, to a set of servers that actually perform the work.

A layer 4 router, more correctly a NAT with port and transaction awareness, sends incoming packets to one or more machines which are hidden behind a single IP address. Since connection must be established between client and server in connection-oriented transport before sending the request content, the load balancer usually selects a server without looking at the content of the request. This is also a redundancy method, so if one machine is not up, the router will not send traffic to it.

Layer-7 Load Balancing

Layer-7 load balancing, also known as application-level load balancing, is to parse requests in application layer and distribute them to servers based on different types of request contents, in order to provide quality of service requirements for different types of contents and improve overall cluster performance. The overhead of parsing requests in application layer is high, thus its scalability is limited, compared to layer-4 load balancing.

The computer appliances capable of performing layer 7 load balancing are called Application Delivery Controllers (ADC) and they blend traditional load-balancing capabilities with advanced, application aware layer 7 switching to support the design of a highly scalable, optimized application delivery network. Let’s now take a look at the difference between the two technologies, and the benefits of combining the two into a single appliance.

As we have previously seen, load balancing is the process of balancing application requests in which the load balancer presents to the outside world a "virtual server" that accepts requests on behalf of a pool (also called a cluster or farm) of servers containing the same content and distributes those requests across all servers based on a load-balancing algorithm.

 

Layer 7 Switching

Layer 7 switching, also known as "request switching", "application switching", and "content based routing", takes its name from the OSI model, indicating that the device switches requests based on layer 7 (application) data. A layer 7 switch presents to the outside world a "virtual server" that accepts requests on behalf of a number of servers and distributes those requests based on policies that use application data to determine which server should service which request.

This allows for the application infrastructure to be specifically tuned/optimized to serve specific types of content. For example, one server can be tuned to serve only images, another for execution of server-side scripting languages like PHP and ASP, and another for static content such as HTML, CSS , and JavaScript.

Unlike load balancing, layer 7 switching does not require that all servers in the pool (farm/cluster) have the same content. In fact, layer 7 switching expects that servers will have different content, thus the need to more deeply inspect requests before determining where they should be directed. Layer 7 switches are capable of directing requests based on URL, host, HTTP headers, and anything in the application message.

Layer 7 load balancing concepts

By combining load balancing with layer 7 switching, we arrive at Layer 7 Load Balancing, a core capability of all modern ADCs.

 

Layer 7 load balancing allows for additional features offered by ADCs to be applied based on content type, which further improves performance by executing only those policies that are applicable to the content. It’s also unlikely that all the servers will be the same specification - again, this might suit the different types of content to be served; some users might be directed at higher powered servers, if they are premium customers, or are on the site to place an order rather than just browse.

Layer 7 load balancing also allows for increased efficiency of the application infrastructure because different types of content have different requirements in terms of CPU usage, I/O throughput etc. So it’s possible to get better efficiencies out of the servers by grouping them so that some handle transactions, while others just act as massive storage systems for serving up static pages, or are optimized for downloading streaming video, for instance.

To carry out more precise load balancing, the ADC 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. The ADC might look for a particular string, so that www.mysite.com/welcome.html requests go to one group of high-powered servers, while www.mysite.com/exit.html goes to another or it could use the extension (.asp, .gif, etc.) to point traffic at servers that have been optimized for serving that type of traffic.

HTTP Header interrogation

The ADC can glean a lot of information by looking at the header information. The Host: header is actually the www.mysite.com part of the overall HTTP address, and it’s separated from the rest (as of HTTP 1.1) into its own header field. In the event of hosting multiple companies’ web sites, one doesn’t have to advertise multiple Virtual IP addresses for each, but just let the ADC direct traffic using the header information.

Persistence / Sticky / Affinity

When people were pointed at servers based on their source address, it was pretty easy to keep them going to the same server all the time but directing people according to web page addresses and type of content, makes it more difficult to keep control. There are times when it’s vital that just one server handles all of a user’s transactions for the length of that session and the obvious one is online shopping. Regardless of how the user jumps about looking at brochure content, their shopping cart entries have to go to the same place all the time. This is known as persistence.

Persistence is a feature that is required by many web applications and it is normally required when the session state is stored locally to the web server as opposed to a database. Once a user has interacted with a particular server all subsequent requests are sent to the same server thus persisting to that particular server. Persistent load balancing can be achieved using IP address hashing or the use of cookies - the latter being the more flexible.

• Source IP based persistence: This is a simple and fast method, and these days it’s very unlikely to get a client IP change during a session so it is perfectly safe to use but is not very effective due to proxies i.e. a user could connect to the site via a range of external IPs thus breaking the persistence;

• Cookie based persistence: Layer 7 devices can take advantage of setting a load balancer cookie with the persistence information. This is a more reliable method, it does not suffer from the proxy problem and it will work well as long as the clients accept cookies, but obviously it can only work with HTTP traffic.A special case of header information, the cookies sent down from the servers to the clients, either temporarily for the duration of that session, or permanently, to be stored on the users’ hard drives, gives 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 the site before, so that they can be welcomed by name the next time they visit, or if it’s a service they’ve previously subscribed to, be sent to the servers providing the services they’ve paid for.

The problem here is that if the servers are running secure HTTP - which is more than likely on an ecommerce site where people exchange financial and personal information - the cookie is within the encrypted SSL payload, so the content servers can’t see it or react it.

SSL Termination

SSL termination  or SSL offload is the ability for a load balancer to establish a secure tunnel with the client thus in most cases replacing the requirement for the web server to perform SSL. In order for the load balancer to perform this function it must be configured with an SSL certificate either self-generated or signed by a certificate authority. SSL termination is often required for any Layer 7 trickery such as cookie insertion; otherwise the load balancer can't read the encrypted payload of the packets. Layer 4 load balancing doesn't have the need to read the packet contents and therefore doesn't require SSL Termination.

Advantages of Layer 7 load balancing

In sum Layer 7 load balancing allows:

• Application-intelligent load balancing across application servers, firewalls, and many other devices-based on sophisticated load-balancing algorithms, content, and policies; continuous health-checking; support for backup and overflow devices; and active-active redundant switch configurations - to ensure that requests are efficiently sent to and served by the most appropriate network device;

• Application-intelligent application redirection, based on full Layer 7 inspection of URLs, cookies, and host headers across multiple requests and responses, applied against powerful filtering rules;

• 'Cookie-aware' differentiated services, such as special treatment for frequent shoppers versus casual browsers—plus differentiated bandwidth and jitter characteristics for different types of applications based on awareness of the requested URL, not just on IP address or application port;

• Virtual hosting, by enabling a single public IP address to represent multiple domains, and automatically redirecting requests to the appropriate server or server farm;

• Persistent connections to improve session performance for eBusiness transactions (shopping carts and multi-page forms, for example), Multimedia applications (VoIP, SIP, etc.) and wireless applications;

• Application-aware security that protects servers and applications against attacks (Virus, Worms, DoS, etc.) and unwanted intrusion while providing continuous service for legitimate traffic;

• Intelligent bandwidth management capabilities that can meter, control and account for resource utilization by any Layer 2-7 attribute, including application type, client, server farm, filters, service, user class, URL, cookies and content type.
  

Technorati Tags: Load Balancing,Servers,High Availability