Load Balancer
Content
CHAPTER 4 BOUNDED WEB LOAD BALANCER ARCHITECTURE
Figure 4.1.Architecture of bounded web load balancer
This Bounded web load balancer consists of the following components.
Dispatcher
This dispatcher acts as an interceptor, dispatching all the incoming requests to the backend servers. The dispatcher is present in the server side which is activated when the server is started in load balancing mode. The dispatcher itself in some case is able to
serve the incoming request. The dispatcher is set to serve static contents like *.jpg,*.html,*.gif etc., The one important feature of this bounded web load balancer is that the dispatcher interceptor is responsible for preventing the backend servers and the clients from the denial of service attacks.
Node chooser
The node chooser module decides the node to be assigned for different incoming requests. The node chooser may assign more than one node to process a request. The node chooser selects the node based on the current load of the nodes which is being analyzed by the load analyzer present within the active node manager. The node chooser selects the node based on the node weight in a round robin fashion. The node chooser module comprises of a stack of node choosers arranged in a particular order, each assigned a specific task. Whenever a request is passed to the node chooser to resolve a node, it is processed in specified order to obtain a node.
URL Mapping Node Chooser: It makes a decision based on the hostname and URL of the request, comparing them with the url rules laid down in the configuration file. A code snippet of the configuration for URI based redirection is given below:
Load Balancing Node Chooser: It implements an adaptive load balancing algorithm. The adaptive load balancing algorithm used here is dynamic weighted round robin algorithm. Weighted Round-Robin is an advanced version of the round-robin that eliminates the deficiencies of the plain round robin algorithm. In case of a weighted round-robin, one can assign a weight to each server in the group so that if one server is capable of handling twice as much load as the other, the powerful server gets a weight of 2. In such cases, the IP sprayer will assign two requests to the powerful server for each request assigned to the
weaker one. The advantage of this algorithm is that it takes care of the capacity of the servers in the system. The weighted round-robin scheduling is designed to better handle servers with different processing capacities. Each server can be assigned a weight, an integer value that indicates the processing capacity. Servers with higher weights receive new connections first than those with less weights, and servers with higher weights get more connections than those with less weights and servers with equal weights get equal connections. For example, the real servers, A, B and C, have the weights, 4, 3, 2 respectively, a good scheduling sequence will be AABABCABC in a scheduling period (mod sum(Wi)). In the implementation of the weighted round-robin scheduling, a scheduling sequence will be generated according to the server weights after the rules of Virtual Server are modified. The network connections are directed to the different real servers based on the scheduling sequence in a round-robin manner. The weighted round-robin scheduling is better than the round-robin scheduling, when the processing capacity of real servers are different.
Node Manager The node manager is responsible for maintaining a record of which of the backend servers is presently active and dead. When a web load balancer is initialized the manager checks for the availability of nodes. . If a particular node is down, the Node Manager informs the Web Load Balancer and the Node Choosers, so that subsequent requests do not get routed to the failed node. It also checks all nodes at periodic intervals to find out whether the live nodes are still able to serve requests, and whether the dead nodes have come up again. The node manager in this web load balancer is of two types which are as follows
Active Node Manager
The active node chooser consists of the active nodes list. The load analyzer in the active node manager analyzes the load of the different active nodes. This information is essential as the node chooser selects the based on their current load.
Failover Manager
The failover manager consists of the list of dead nodes. The failover manager handles the situation when a node is dead. This failover manager periodically updates the node chooser with the list of dead nodes to prevent the node chooser from sending the subsequent requests to the dead nodes. when a node that is currently processing the requests assigned by the dispatcher interceptor is down, then the failover manager informs the dispatcher interceptor about the failure of the node. Now the dispatcher asks the node chooser for an active node by sending again the request and the node chooser responds the dispatcher with an active node.
Load Monitor The load monitor module monitors the current load of each of the backend servers and report the status to the active node manager and also monitors the dead nodes and informs it to the failover manager which helps the node chooser to assign the subsequent requests to those dead nodes.
Node
Any backend server to which the requests are being dispatched by the dispatcher interceptor is said to be a node. The backend server may be anything like Apache server, IIS server and suchlike. The nodes are assigned an unique name by the load balancer administrator. which is mapped to a combination of IP address and web port.
Working of the bounded web load balancer
The bounded web load balancer sits transparently in front of the server farm acting as a proxy receiving the requests from the clients which are destined for certain internet services. The dispatcher gets the incoming requests and passes that information to the node chooser module asking for a node to assign the request and to get back the response. The node chooser receives the status of both the available and dead nodes and the current load of the available nodes. Now the node chooser module selects the node based on these information. The node chooser contains a stack of information to resolve the nodes to process the request. when a dispatcher sends a request to the node chooser asking for a node the URL controller makes a decision based on the hostname and the URL of the request and then it passes through the load balancing controller which implements the adaptive load balancing algorithm to select an active node to process the request. Now the dispatcher gets the IP address of the node and writes the request to that selected node to get the response, which it writes back to the client.
The normal node chooser and failover node chooser behaves as follows
The dispatcher forwards the requests to the node chooser which has to perform the role of delegating a node for processing the request. The node chooser has a stack of modules for resolving a single node for processing the request. When the request passes through the URL controller nodes B and C are resolved. Then the resolved nodes are passed through the load balancer controller which in turn resolves the node C based on an adaptive load balancing algorithm. Now the node is delegated by the node chooser module to the dispatcher interceptor to process the request. If this selected node say C fails or if the dispatcher does not get any response from the selected node for a long time then the failover manager informs the dispatcher about the failure of the node and also updates the node chooser with the new dead nodes list. now the dispatcher sends the requests again to the node chooser asking for a new available node. As shown above if node C fails then nodes A and B are resolved by the URL and load balancing controllers to delegate an available node to the dispatcher to process the request. when one of the backend server fails it is immediately removed and is started again when it is ready.
Figure 4.1.Architecture of bounded web load balancer
This Bounded web load balancer consists of the following components.
Dispatcher
This dispatcher acts as an interceptor, dispatching all the incoming requests to the backend servers. The dispatcher is present in the server side which is activated when the server is started in load balancing mode. The dispatcher itself in some case is able to
serve the incoming request. The dispatcher is set to serve static contents like *.jpg,*.html,*.gif etc., The one important feature of this bounded web load balancer is that the dispatcher interceptor is responsible for preventing the backend servers and the clients from the denial of service attacks.
Node chooser
The node chooser module decides the node to be assigned for different incoming requests. The node chooser may assign more than one node to process a request. The node chooser selects the node based on the current load of the nodes which is being analyzed by the load analyzer present within the active node manager. The node chooser selects the node based on the node weight in a round robin fashion. The node chooser module comprises of a stack of node choosers arranged in a particular order, each assigned a specific task. Whenever a request is passed to the node chooser to resolve a node, it is processed in specified order to obtain a node.
URL Mapping Node Chooser: It makes a decision based on the hostname and URL of the request, comparing them with the url rules laid down in the configuration file. A code snippet of the configuration for URI based redirection is given below:
Load Balancing Node Chooser: It implements an adaptive load balancing algorithm. The adaptive load balancing algorithm used here is dynamic weighted round robin algorithm. Weighted Round-Robin is an advanced version of the round-robin that eliminates the deficiencies of the plain round robin algorithm. In case of a weighted round-robin, one can assign a weight to each server in the group so that if one server is capable of handling twice as much load as the other, the powerful server gets a weight of 2. In such cases, the IP sprayer will assign two requests to the powerful server for each request assigned to the
weaker one. The advantage of this algorithm is that it takes care of the capacity of the servers in the system. The weighted round-robin scheduling is designed to better handle servers with different processing capacities. Each server can be assigned a weight, an integer value that indicates the processing capacity. Servers with higher weights receive new connections first than those with less weights, and servers with higher weights get more connections than those with less weights and servers with equal weights get equal connections. For example, the real servers, A, B and C, have the weights, 4, 3, 2 respectively, a good scheduling sequence will be AABABCABC in a scheduling period (mod sum(Wi)). In the implementation of the weighted round-robin scheduling, a scheduling sequence will be generated according to the server weights after the rules of Virtual Server are modified. The network connections are directed to the different real servers based on the scheduling sequence in a round-robin manner. The weighted round-robin scheduling is better than the round-robin scheduling, when the processing capacity of real servers are different.
Node Manager The node manager is responsible for maintaining a record of which of the backend servers is presently active and dead. When a web load balancer is initialized the manager checks for the availability of nodes. . If a particular node is down, the Node Manager informs the Web Load Balancer and the Node Choosers, so that subsequent requests do not get routed to the failed node. It also checks all nodes at periodic intervals to find out whether the live nodes are still able to serve requests, and whether the dead nodes have come up again. The node manager in this web load balancer is of two types which are as follows
Active Node Manager
The active node chooser consists of the active nodes list. The load analyzer in the active node manager analyzes the load of the different active nodes. This information is essential as the node chooser selects the based on their current load.
Failover Manager
The failover manager consists of the list of dead nodes. The failover manager handles the situation when a node is dead. This failover manager periodically updates the node chooser with the list of dead nodes to prevent the node chooser from sending the subsequent requests to the dead nodes. when a node that is currently processing the requests assigned by the dispatcher interceptor is down, then the failover manager informs the dispatcher interceptor about the failure of the node. Now the dispatcher asks the node chooser for an active node by sending again the request and the node chooser responds the dispatcher with an active node.
Load Monitor The load monitor module monitors the current load of each of the backend servers and report the status to the active node manager and also monitors the dead nodes and informs it to the failover manager which helps the node chooser to assign the subsequent requests to those dead nodes.
Node
Any backend server to which the requests are being dispatched by the dispatcher interceptor is said to be a node. The backend server may be anything like Apache server, IIS server and suchlike. The nodes are assigned an unique name by the load balancer administrator. which is mapped to a combination of IP address and web port.
Working of the bounded web load balancer
The bounded web load balancer sits transparently in front of the server farm acting as a proxy receiving the requests from the clients which are destined for certain internet services. The dispatcher gets the incoming requests and passes that information to the node chooser module asking for a node to assign the request and to get back the response. The node chooser receives the status of both the available and dead nodes and the current load of the available nodes. Now the node chooser module selects the node based on these information. The node chooser contains a stack of information to resolve the nodes to process the request. when a dispatcher sends a request to the node chooser asking for a node the URL controller makes a decision based on the hostname and the URL of the request and then it passes through the load balancing controller which implements the adaptive load balancing algorithm to select an active node to process the request. Now the dispatcher gets the IP address of the node and writes the request to that selected node to get the response, which it writes back to the client.
The normal node chooser and failover node chooser behaves as follows
The dispatcher forwards the requests to the node chooser which has to perform the role of delegating a node for processing the request. The node chooser has a stack of modules for resolving a single node for processing the request. When the request passes through the URL controller nodes B and C are resolved. Then the resolved nodes are passed through the load balancer controller which in turn resolves the node C based on an adaptive load balancing algorithm. Now the node is delegated by the node chooser module to the dispatcher interceptor to process the request. If this selected node say C fails or if the dispatcher does not get any response from the selected node for a long time then the failover manager informs the dispatcher about the failure of the node and also updates the node chooser with the new dead nodes list. now the dispatcher sends the requests again to the node chooser asking for a new available node. As shown above if node C fails then nodes A and B are resolved by the URL and load balancing controllers to delegate an available node to the dispatcher to process the request. when one of the backend server fails it is immediately removed and is started again when it is ready.
