Overview of the components of Load Balancer

This chapter gives an overview of Load Balancer components and includes the following sections:

For a high-level list of configuration features that are provided by each of the Load Balancer components, and to assist you in planning which features to use for managing your network, see Managing your network: Determining which Load Balancer features to use.

What are the components of Load Balancer?

The five components of Load Balancer are: Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller, and Nortel Alteon Controller. Load Balancer gives you the flexibility of using the components separately or together depending on your site configuration. This section gives an overview of these components.

Overview of the Dispatcher component

The Dispatcher component balances traffic among your servers through a unique combination of load balancing and management software. Dispatcher can also detect a failed server and forward traffic around it. Dispatcher supports HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP, and any other TCP or stateless UDP based application.

All client requests sent to the Dispatcher machine are directed to the "best" server according to weights that are set dynamically. You can use the default values for those weights or change the values during the configuration process.

Dispatcher offers three forwarding methods (specified on the port):

The Dispatcher component is the key to stable, efficient management of a large, scalable network of servers. With Dispatcher, you can link many individual servers into what seems to be a single, virtual server. Your site is presented as a single IP address to the world. Dispatcher functions independently of a domain name server; all requests are sent to the IP address of the Dispatcher machine.

Dispatcher brings distinct advantages in balancing traffic load to clustered servers, resulting in stable and efficient management of your site.

Managing local servers with Dispatcher

Figure 1. Example of a physical representation of a site using Dispatcher to manage local servers
Physical representation of site using Dispatcher to manage local servers

Figure 1 shows a physical representation of the site using an Ethernet network configuration. The Dispatcher machine can be installed without making any physical changes to the network. After a client request is directed to the optimal server by the Dispatcher, the response is then sent directly from server to client with no involvement by the Dispatcher when using MAC forwarding method.

Managing servers using Dispatcher and Metric Server

Figure 2. Example of a site using Dispatcher and Metric Server to manage servers
Site with Dispatcher and Metric Server managing servers

Figure 2 illustrates a site in which all servers are on a local network. The Dispatcher component is used to forward requests, and the Metric Server is used to provide system load information to the Dispatcher machine.

In this example, the Metric Server daemon is installed on each back-end server. You can use Metric Server with the Dispatcher component or any of the other Load Balancer components.

Managing local and remote servers with Dispatcher

Figure 3. Example of a site using Dispatcher to manage local and remote servers
Site with Dispatcher managing local and remote servers

Wide area support in Dispatcher enables you to use both local and remote servers (servers on different subnets). Figure 3 shows a configuration where one local Dispatcher (Dispatcher 1) serves as the entry point for all requests. It distributes these requests among its own local servers (ServerA, ServerB, ServerC) and to the remote Dispatcher (Dispatcher 2), which will load balance to its local servers (ServerG, ServerH, ServerI).

When using Dispatcher's NAT forwarding method or using GRE support, wide area support with Dispatcher can also be achieved without using a Dispatcher at the remote site (where ServerD, ServerE, and ServerF are located). See Dispatcher's NAT/NAPT (nat forwarding method) and GRE (Generic Routing Encapsulation) support for more information.

Overview of the Content Based Routing (CBR) component

CBR works with Caching Proxy to proxy client requests to specified HTTP or HTTPS (SSL) servers. It allows you to manipulate caching details for faster Web document retrieval with low network bandwidth requirements. CBR and Caching Proxy examines HTTP requests using specified rule types.

Note:
The Content Based Routing (CBR) component is available on all supported platforms except those running a 64-bit JVM. Alternatively, you can use the cbr forwarding method of Load Balancer's Dispatcher component to provide content-based routing without the use of Caching Proxy. See Dispatcher's content-based routing (cbr forwarding method) for more information.

CBR gives you the ability to specify a set of servers that handle a request based on regular expression matching of the content of the request. Because CBR allows you to specify multiple servers for each type of request, the requests can be load balanced for optimal client response. CBR also detects when one server in a set has failed, and stops routing requests to that server. The load-balancing algorithm used by the CBR component is identical to the proven algorithm used by the Dispatcher component.

When a request is received by Caching Proxy, it is checked against the rules that have been defined in the CBR component. If a match is found, then one of the servers associated with that rule is chosen to handle the request. Caching Proxy then performs its normal processing to proxy the request to the chosen server.

CBR has the same functions as Dispatcher with the exception of high availability, SNMP subagent, wide area, and a few other configuration commands.

Caching Proxy must be running before CBR can begin load balancing client requests.

Managing local servers with CBR

Figure 4. Example of a site using CBR to manage local servers
Site with CBR managing local servers

Figure 4 shows a logical representation of a site in which CBR is being used to proxy some content from local servers. The CBR component uses Caching Proxy to forward client requests (HTTP or HTTPS) to the servers based on the content of the URL.

Overview of the Site Selector component

Site Selector acts as a name server that works in conjunction with other name servers in a domain name system to load balance among a group of servers using measurements and weights that are gathered. You can create a site configuration to let you load balance traffic among a group of servers based on the domain name used for a client's request.

A client submits a request for resolution of a domain name to a name server within its network. Name server forwards the request to the Site Selector machine. Site Selector then resolves the domain name to the IP address of one of the servers that has been configured under the site name. Site Selector returns the IP address of the selected server to the name server. The name server returns the IP address to the client.

Metric Server is a system monitoring component of Load Balancer that must be installed in each load-balanced server within your configuration. Using Metric Server, Site Selector can monitor the level of activity on a server, detect when a server is the least heavily loaded, and detect a failed server. The load is a measure of how hard the server is working. By customizing system metric script files, you can control the type of measurements used to measure the load. You can configure Site Selector to suit your environment, considering such factors as frequency of access, the total number of users, and types of access (for example, short queries, long-running queries, or CPU-intensive loads).

Managing local and remote servers with Site Selector and Metric Server

Figure 5. Example of a site using Site Selector and Metric Server to manage local and remote servers
Site with Site Selector and Metric Server managing servers

Figure 5 illustrates a site in which the Site Selector component is used to answer requests. Server1, Server2, and Server3 are local. Server4, Server5, and Server6 are remote.

A client submits a request for resolution of a domain name to a client name server. The client name server forwards the request through the DNS to the Site Selector machine (Path 1). Site Selector then resolves the domain name to the IP address of one of the servers. Site Selector returns the IP address of the selected server to the client name server. The name server returns the IP address to the client.

After the client receives the IP address of the server, the client routes application requests directly to the selected server (Path 2).

Note:
In this example, the Metric Server provides system load information to the Site Selector machine. The Metric Server agent is installed on each back-end server. Use Metric Server in conjunction with Site Selector; otherwise Site Selector can only use a round-robin selection method for load balancing.

Overview of the Cisco CSS Controller component

Note:
The Cisco CSS Controller component is shipped with Version 7.0 of Load Balancer for IPv4, but this component might not support newer hardware. Consult the prerequisites page for supported hardware: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

Cisco CSS Controller forms a complementary solution in conjunction with Cisco's CSS 11000 series switches. The combined solution blends the CSS 11000 series' robust packet forwarding and content routing capabilities with Load Balancer's sophisticated awareness algorithms for determining load information and availability of the service (back-end server application or database). The Cisco CSS Controller function utilizes Load Balancer's weight calculation algorithm, standard and custom advisors, and Metric Server to determine the metrics, health, and load of the service. With this information Cisco CSS Controller generates service weights, which it sends to the Cisco CSS Switch for optimal service selection, load optimization, and fault tolerance.

Cisco CSS Controller tracks many criteria, including:

When a Cisco CSS Switch, without Cisco CSS Controller, is determining the health of a content-providing service, it uses response times for content requests or other network measures. With Cisco CSS Controller in place, these activities are offloaded from the Cisco CSS Switch to Cisco CSS Controller. Cisco CSS Controller influences the service's weight or ability to serve content, and activates or suspends a service as appropriate when the service regains or loses availability.

Cisco CSS Controller:

Weights are applied to all services on a port. For any particular port, the requests are distributed between services based on their weights relative to each other. For example, if one service is set to a weight of 10, and the other to 5 the service set to 10 gets twice as many requests as the service set to 5. These weights are provided to the Cisco CSS Switch using SNMP. As the weight of any service is set higher, the Cisco CSS Switch directs more requests to that service.
Figure 6. Example of a site using Cisco CSS Controller and Metric Server to manage local services
Site with Cisco CSS Controller and Metric Server managing services

Cisco CSS Controller, in conjunction with the Cisco CSS Switch, delivers a "best of both worlds" solution that combines wire-speed content switching with sophisticated application awareness, fault tolerance, and service load optimization. Cisco CSS Controller is part of an overall complementary solution between the Cisco CSS Switch and IBM® WebSphere® Application Server Load Balancer.

Overview of Nortel Alteon Controller component

Note:
The Nortel Alteon Controller component is shipped with Version 7.0 of Load Balancer for IPv4, but this component might not support newer hardware. Consult the prerequisites page for supported hardware: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921

Nortel Alteon Controller in conjunction with the Nortel Alteon family of Web switches provides a complementary solution that combines the switches' packet forwarding speed and capacity with the Load Balancer's sophisticated awareness algorithms for determining server weights.

Nortel Alteon Controller allows you to develop custom advisors that are capable of performing more intelligent, application-aware assessments of the availability and load of applications used to deploy services.

The Metric Server provides system load information, such as CPU and memory utilization information, and a framework for you to develop custom system load measurements.

Nortel Alteon Controller collects many types of metric data to determine weights for servers being load-balanced by Nortel Alteon Web Switches, including:

Nortel Alteon Controller uses SNMP to communicate with the switch. Configuration , state and connection information is retrieved from the switch. When server weights are calculated by the controller, they are set on the switch. The switch uses the weights set by the controller to select the best server to handle client requests for a service.

Figure 7. Example of a site using Nortel Alteon Controller to manage local servers
Site with Nortel Alteon Controller managing servers

You can manage the controller using a browser, a remote GUI, or a remote command line interface.

Nortel Alteon Controller combined with the Nortel Alteon family of Web switches delivers a "best of both worlds" solution that combines wire-speed packet switching with sophisticated application awareness, fault tolerance and server load optimization. Nortel Alteon Controller is part of a complementary solution between the Nortel Alteon family of Web switches and IBM's WebSphere.