Clustering and Load Balancing

 

Figure: Application deployed on the Single Application Server

Figure: In order to make the Application as a reliable one , now the Application deployed on the Multiple Application Servers

 http://192.168.56.1:7002/shoppingcart
http://192.168.56.2:7002/shoppingcart
http://192.168.56.3:7002/shoppingcart
http://192.168.56.4:7002/shoppingcart
http://192.168.56.5:7002/shoppingcart
http://192.168.56.6:7002/shoppingcart
http://192.168.56.7:7002/shoppingcart
http://192.168.56.8:7002/shoppingcart
http://192.168.56.9:7002/shoppingcart

Problem:

So the application is deployed under different machines, using this URL you can access the application, but still the reliability of the Application is not 100%. Because if the server goes down, then the session will be terminated.

Every time the servers goes down, you need to manually switch to some the server, it’s a awkward task for the users.

How to satisfy the user expectation ?


• To add one server in-front of all application server clusters, to accept all the request and distribute to the cluster, so this server acts as a load balancer. There is lots of server is available with load balancing capability, here we are going to use Apache httpd web server as a load balancer, with mod_proxy Module.

Figure: Apache Web Sever as Load Balancer

Solution

-> So now users can access the deployed application in the application servers through the Load Balancer (Apache Web Server).


http://www.shoppingcart.com/shoppingcart


-> The request given by user to Load Balancer (apache web server) is distributed the application servers in different clusters so the application will be available across 24x7.

Required Modules


Mod_proxy


Mod_proxy_http (Assume you are load balancing HTTP requests)


Mod_proxy_balancer


Mod_headers (for Sticky Sessions)


Mod_rewrite (for advance Configurations)

Apache Module mod_proxy_balancer


Description: mod_proxy extension for load balancing


Status: Extension


Module Identifier: proxy_balancer_module


Source File: mod_proxy_balancer.c


Compatibility: Available in version 2.1 and later

Examples of a balancer configuration

• Before we dive into the technical details, here's an example of how you might use mod_proxy_balancer to provide load balancing between nine back-end application servers:

<Proxy balancer://applicationcluster>
BalancerMember http://192.168.56.1:7002
BalancerMember http://192.168.56.2:7002
BalancerMember http://192.168.56.3:7002
BalancerMember http://192.168.56.4:7002
BalancerMember http://192.168.56.5:7002
BalancerMember http://192.168.56.6:7002
BalancerMember http://192.168.56.7:7002
BalancerMember http://192.168.56.8:7002
BalancerMember http://192.168.56.9:7002
</Proxy>
ProxyPass /shoppingcart balancer://applicationcluster 

Load balancer scheduler algorithm

    • At present, there are 3 load balancer scheduler algorithms available for use:


    a) Request Counting


    b) Weighted Traffic Counting


    c) Pending Request Counting


    • These are controlled via the lbmethod value of the Balancer definition.

<proxy balancer: a_name_signifying_your_app> 
BalancerMember http://ip_address:port/ loadfactor=appropriate_load_factor 
# Balancer member 1 
BalancerMember http://ip_address:port/ loadfactor=appropriate_load_factor 
# Balancer member 2 
ProxySet lbmethod=the_Load_Balancing_algorithm 
</proxy>

<Proxy balancer://applicationcluster> 
BalancerMember http://192.168.56.1:7002 loadfactor=1 # Balancer member 1 
BalancerMember http://192.168.56.2:7002 loadfactor=3 # Balancer member 1 
BalancerMember http://192.168.56.3:7002 loadfactor=1 # Balancer member 1 
BalancerMember http://192.168.56.4:7002 loadfactor=3 # Balancer member 1 
BalancerMember http://192.168.56.5:7002 loadfactor=1 # Balancer member 1 
BalancerMember http://192.168.56.6:7002 loadfactor=3 # Balancer member 1 
BalancerMember http://192.168.56.7:7002 loadfactor=1 # Balancer member 1 
BalancerMember http://192.168.56.8:7002 loadfactor=3 # Balancer member 1 
BalancerMember http://192.168.56.9:7002 loadfactor=1 # Balancer member 1 
ProxySet lbmethod= byrequests 
</Proxy> 
ProxyPass /shoppingcart balancer://applicationcluster 

Weighted Traffic Counting Counting Algorithm


• The Weighted Traffic Counting algorithm is similar to Request Counting algorithm, with a minor difference: Weighted Traffic Counting considers the number of bytes instead of number of requests. In the configuration example below, the number of bytes processed by 192.168.56.1 will be three times that of 192.168.56.2. . For example, consider this Apache config snippet:

<Proxy balancer://applicationcluster> 
BalancerMember http://192.168.56.1:7002 loadfactor=1 # Balancer member 1 
BalancerMember http://192.168.56.2:7002 loadfactor=3 # Balancer member 1 
BalancerMember http://192.168.56.3:7002 loadfactor=1 # Balancer member 1 
BalancerMember http://192.168.56.4:7002 loadfactor=3 # Balancer member 1 
BalancerMember http://192.168.56.5:7002 loadfactor=1 # Balancer member 1 
BalancerMember http://192.168.56.6:7002 loadfactor=3 # Balancer member 1 
BalancerMember http://192.168.56.7:7002 loadfactor=1 # Balancer member 1 
BalancerMember http://192.168.56.8:7002 loadfactor=3 # Balancer member 1 
BalancerMember http://192.168.56.9:7002 loadfactor=1 # Balancer member 1 
ProxySet lbmethod= bytraffic 
</Proxy> 
ProxyPass /shoppingcart balancer://applicationcluster 

Pending Request Counting Algorithm


• The Pending Request Counting algorithm is the latest and most sophisticated algorithm provided by Apache for load balancing. It is available from Apache 2.2.10 onward.


•  In this algorithm, the scheduler keeps track of the number of requests that are assigned to each back-end worker at any given time. Each new incoming request will be sent to the back end that has least number of pending requests – in other words, to the back-end worker that is relatively least loaded. This helps keep the request queues even among the back-end workers, and each request generally goes to the worker that can process it the fastest.


• If two workers are equally lightly loaded, the scheduler uses the Request Counting algorithm to break the tie. For example, consider this Apache config snippet:

<Proxy balancer://applicationcluster>
BalancerMember http://192.168.56.1:7002 # Balancer member 1 
BalancerMember http://192.168.56.2:7002 # Balancer member 1 
BalancerMember http://192.168.56.3:7002 # Balancer member 1 
BalancerMember http://192.168.56.4:7002 # Balancer member 1 
BalancerMember http://192.168.56.5:7002 # Balancer member 1 
BalancerMember http://192.168.56.6:7002 # Balancer member 1 
BalancerMember http://192.168.56.7:7002 # Balancer member 1 
BalancerMember http://192.168.56.8:7002 # Balancer member 1 
BalancerMember http://192.168.56.9:7002 # Balancer member 1 
ProxySet lbmethod= bybusyness 
</Proxy>
ProxyPass /shoppingcart balancer://applicationcluster 
 

Software Load Balancer  (Vs) Hardware Load Balancer


•Apache mod_proxy_balancer provides a cost-effective software solution for load balancing. While a hardware load balancer device can easily cost more than $1,000, software load balancers are cheap – or, in this case, free.


• Even though mod_proxy_balancer has a fairly limited feature set compared to those of hardware load balancers, which can provide more comprehensive statistics and handle larger volumes of traffic, it offers solid basic capabilities for small to midsize deployments.

Load balancer stickyness:

a The balancer supports stickyness. When a request is proxied to some back-end, then all following requests from the same user should be proxied to the same back-end. Many load balancers implement this feature via a table that maps client IP addresses to back-ends.


a This approach is transparent to clients and back-ends, but suffers from some problems:


a] unequal load distribution if clients are themselves hidden behind proxies


b] stickyness errors when a client uses a dynamic IP address that changes during a session and loss of stickyness, if mapping table overflows.


a The module mod_proxy_balancer implements stickyness on top of two alternative means: cookies and URL encoding. Providing the cookie can be either done by the back-end or by the Apache web server itself. The URL encoding is usually done on the back-end.

Examples of a balancer configuration with stickyness

•Another example of how to provide load balancing with stickyness using mod_headers, even if the back-end server does not set a suitable session cookie:


Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED

<proxy applicationcluster balancer:> 
BalancerMember http://192.168.56.1:7002 route=1 
BalancerMember http://192.168.56.2:7002 route=2 
BalancerMember http://192.168.56.3:7002 route=3 
BalancerMember http://192.168.56.4:7002 route=4 
BalancerMember http://192.168.56.5:7002 route=5 
BalancerMember http://192.168.56.6:7002 route=6 
BalancerMember http://192.168.56.7:7002 route=7 
BalancerMember http://192.168.56.8:7002 route=8 
BalancerMember http://192.168.56.9:7002 route=9 
ProxySet stickysession=ROUTEID 
ProxyPass /shoppingcart balancer://applicationcluster