Load Balancer overview

Load Balancer overview

Table of contents |  Previous Next

Load Balancer consists of the following five components that can be used
separately or together:

• Dispatcher
• Content Based Routing (CBR) Component for HTTP and HTTPS
• Site Selector
• Cisco CSS Controller
• Nortel Alteon Controller

We cover these components in more detail in the following sections. However, in
our test environment we used the Dispatcher component.
Session affinity is an option that applies to all of these components.

Dispatcher

The Dispatcher component distributes the load it receives to servers contained in
a cluster (a set of servers that run the same application and can provide the
same contents to its clients). This mechanism is also known as IP spraying.
Dispatcher decides which server will handle a certain TCP/IP connection based
on the weight of each server in the cluster. The weight is the value that
determines the number of connections that each server receives. The weight can
be fixed in the configuration or it can be dynamically calculated by Dispatcher.

If you choose to configure the weight of the servers and set it as a fixed value, it
will not change no matter the conditions of the balanced servers, for example, if
you configure a cluster containing two servers, and you set the weight of the first
server to 1 and the weight of the second server to 2, meaning that the second
server will always receive twice the load as the first server. The only exception to
this is when an Advisor detects a failed server.

If you choose to work with dynamic weights (which is the default option, and what
we did in our test environment), Dispatcher will calculate the load of each
balanced server dynamically. In our previous example, if the response time of the
second server was slower than the response time of the first server, it would now
be possible to detect this and generate the correct weight value according to the
real conditions of each server.

For actual implementation information, refer to Install and configure IBM
Edge Load Balancer components (Specifically, see Configure the
Manager component )

Dispatcher’s internal components

Dispatcher has internal components that are responsible for the tasks mentioned
earlier, like distributing TCP/IP packets and calculating the weight of the
balanced servers. These components are:

• Executor
• Manager
• Advisors
• Metric server

Note: Load balancing can handle any TCP/IP-compliant protocol, including
the Sametime proprietary protocols. For example, Dispatcher can provide load
balancing for protocols such as HTTP, HTTPS, FTP, NNTP, IMAP, POP3,
SMTP, Telnet, and so on.


Executor
Executor is the core component of Dispatcher, and it is responsible for the load
distribution. It receives the packet, identifies whether this packet is destined to
the operating system or if it is destined to a cluster. If the packet is destined to a
cluster, it then determines whether this packet is a follow up to an existing
connection, or if it is a request for a new connection. Executor keeps a
connection table in memory to keep track of all active connections. After that, it
chooses the back-end server to which this packet will be sent.
In order to be able to identify the packets meant for the operating system, the
administrator needs to associate an IP address to the variable NFA
(non-forwarding address). This variable contains the IP address that is used for
all connections that should not be load balanced by Dispatcher, like telneting into
the machine, connecting to the Dispatcher’s administration service, and so on. In
other words, NFA determines the IP address that the Executor will ignore as far
as load balancing is concerned.

Manager
Manager is the component responsible for providing weight values of each
balanced server to Executor, so it can make its load balancing decision. Running
this component is optional, but it is necessary for dynamic weighting of the
servers and also for identifying failed servers.

Manager uses metric values for calculating the weight value of each server:

• The number of active connections being handled by that server
• The number of new connections that were forwarded to that server since the last check (The default is two seconds.)

The input from two components that gather load information about the
balanced servers:

• The Advisors
• The Metric Server

For additional information refer to Configure the Manager component.

Advisors
The Advisors are lightweight clients that run on the Dispatcher server, and they
are aware of the protocol used by the back-end servers. Load Balancer provides
advisors for HTTP, HTTPS, FTP, and LDAP, among others.
Each advisor connects to a certain service running on each server of the cluster,
and submits a request that validates the health of that service. This means that
the advisor actually tests the service, not only the connectivity to the server (a
system can be reachable by ping, but if the server is not running, it cannot be
used in load balancing). The advisor then returns a value to the manager, which
represents how long it took for each server to respond. If it does not receive a
response from a server, it provides a value of -1 for this server, which is
interpreted by the manager as a server being down. Refer to Advisors
for more information about the Advisors and to Configure the Manager
component for information about implementing this feature.

Metric server
If you need to collect more information from the back-end server for load
balancing, you can also use the metric server, which is a component that is
installed and runs in each back-end server. The metric server can additionally
provide values for the server where it is running. For example, the metric server
can monitor memory and CPU usage. This information is also sent to the
manager and is used to calculate the final weight value for each server.
The interaction of Executor, manager, and other Load Balancer components is
shown in Figure D-1.



Forwarding methods

There are three methods used by Executor to forward packets to the balanced
servers:

• MAC forwarding
• Network Address Translation (NAT)/ Network Address Port Translation (NAPT)
• Content Based Routing (CBR), also referred to as Kernel CBR (KCBR) in previous versions

MAC forwarding
This is the default forwarding method. When Dispatcher receives a packet and
chooses which server to send it to, it only changes the source and destination
MAC address of the packet. The IP addresses remain the same. This means that
the source IP address remains the IP address of the client machine, and the
destination IP address remains the cluster IP address.
When the balanced server receives the packet, it responds directly to the client
(because the source IP address in the packet belongs to the client).

Note: This is the method used in our test environment.

MAC forwarding is the fastest forwarding method because Dispatcher receives
only the incoming traffic. All outbound traffic is sent directly from the balanced
server to the client. This requires that all balanced servers be connected to the
same subnet as Dispatcher. See Figure D-2.



This method also requires that the services running on the balanced servers be
able to accept the packets containing the cluster IP address as the destination IP
address. The easier solution is to add an IP alias to the loopback interface (so it
is not advertised in the network).

Refer to Install and configure IBM Edge Load Balancer components on
, or Load Balancer Administration Guide Version 6.0, GC31-6858

(http://www-1.ibm.com/support/docview.wss?uid=pub1gc31685801), for
instructions on how to add an IP alias in various operating systems.

Network Address Translation (NAT)/ Network Address Port
Translation (NAPT)
This forwarding method allows Dispatcher to provide load balancing for remote
servers, which is not available in the MAC forwarding method.

Dispatcher receives the TCP/IP packet and chooses which server to send it to,
rewrites the IP header and changes the source IP address (which is originally the
IP address of the client machine), puts the return address instead (this is an IP
address configured by the Dispatcher administrator), changes the destination IP
address (which is originally the IP address of the cluster), and puts the balanced
server IP address instead. Now this packet can be routed to the balanced server
even if it is on a remote network. But because Dispatcher changes the packet, it
needs to receive the response so it can also change the IP header before
sending it to the client.


This method also allows port redirection (NAPT). This means that the port that
you configure on the cluster configuration does not need to be the same port that
the service is listening on in the balanced server. In this case, Dispatcher
changes the port information in the TCP header the same way it does with the IP
addresses in the IP header of the TCP/IP packet.

This method implies that Dispatcher needs to handle all traffic, both inbound and
outbound. It also needs one extra IP address to implement the configuration,
which is the return address.

Content Based Routing (CBR)
The CBR forwarding method does not require the caching proxy, as does the
CBR component. It allows content-based load balancing for HTTP and HTTPS
protocols.

For the HTTP protocol, the connection distribution is based on the contents of
the URL or the HTTP header. For the HTTPS protocol, the distribution is based
on the SSL session ID field of the client request.

CBR also allows load distribution to servers connected to remote networks. It
also requires one IP address for the return address.

For more details, advantages, and disadvantages of each forwarding method,
refer to the Load Balancer Administration Guide Version 6.0, GC31-6858:

http://www-1.ibm.com/support/docview.wss?uid=pub1gc31685801

Advisors
Advisors are lightweight clients that run on the Dispatcher machine, providing
information about the load of a given server. The product provides
protocol-specific advisors for several protocols and products, such as HTTP,
HTTPS, FTP, Telnet, DB2, DNS, LDAP, SMTP, and others.

Standard advisors send transactions periodically to determine the status of the
servers (for example, for HTTP an HTTP HEAD request is sent, and for FTP a
SYST command is sent). If the transaction succeeds, the server is considered
up.

Load Balancer also provides a generic advisor, called Connect, that can be used
in case you need to load balance a service or protocol for which there is no
dedicated advisor available. Connect opens a connection to the server using the
server port informed in the advisor configuration and closes the connection after
the TCP/IP handshake is done. As there is not an out-of-the-box advisor for
Sametime. We used the Connect advisor in our test environment.

Note: By default, the only available forwarding method is MAC forwarding. In
order to enable NAT/NAPT and CBR, you need to configure the client gateway
property of Executor and set it to the IP address of the router of the network.
Refer to Chapter 5 in the IBM Redbooks publication WebSphere Application
Server V6 Scalability and Performance Handbook, SG24-6392
(http://www.redbooks.ibm.com/abstracts/sg246392.html?Open), specifically
the NAT Scenario, for more details on how to enable all available forwarding
methods.


In order to calculate a load value, the advisor:

1. Opens a connection with each server.
2. Sends a protocol-specific request message.
3. Listens for a response from the server.
4. Calculates the load value.

   After getting the response, the advisor makes an assessment of the server.
   To calculate this load value, most advisors measure the time for the server to
   respond, and then use this value (in milliseconds) as the load.

   You may also set the connecttimeout and receivetimeout parameters for each
   advisor. connecttimeout is the amount of time the advisor will wait before
   aborting the connection and receivetimeout is the amount of time the advisor
   will wait before giving up on the data over the socket.

5. Reports the load value to manager.

If the server does not respond, the advisor returns a negative value (-1) for the
load. A downed server is given a weight of zero by the Executor, and packets will
not be forwarded to it until the server responds to the advisor again.

Manager obtains the load value reported by the advisor, which is available in the
Port column of the Manager report. The manager obtains these values from all of
its sources and sets proportional weight values for Executor.

Custom advisors
You can also write your own advisors for specific applications like Sametime.
These are called custom advisors, and you can write your own advisor based on
sample Java code provided with the product. The sample code is available in the
install_path/servers/samples/CustomAdvisors directory, where install_path is the
load balancer installation path (such as /opt/ibm/edge/lb on AIX, or C:\Program
Files\IBM\edge\lb on Windows).

Custom advisors run on the Dispatcher node, and must be written using Java
language and compiled with a Java compiler for the Dispatcher machine.
Class file names must follow the form ADV_name.class, where name is the
name you choose for the advisor.

Important: For the Edge Components that are part of IBM WebSphere
Application Server Network Deployment V6, you need Java compiler Version
1.4.2.


Using the Java SDK, the compile command is:

javac -classpath /servers/lib/ibmlb.jar ADV_<name

 

.java

The advisor code must then be copied to the
install_path/servers/lib/CustomAdvisors directory, and it can be started using the
command-line interface or the graphical interface.

Make sure that manager is running before you try to start any advisor.

More detailed information about custom advisors, describing how they work and
how to write, compile, and test them, including examples, development
techniques, and interface methods, can be found in the Load Balancer
Administration Guide Version 6.0, GC31-6858:

http://www-1.ibm.com/support/docview.wss?uid=pub1gc31685801

More detailed information about custom advisors specifically for Sametime can
be found in the developerWorks article “Sametime Chat Network Dispatcher
Advisor”:

http://www-128.ibm.com/developerworks/lotus/library/ls-STChat_advisor/

Which includes a link to their code for the Sametime Chat Advisor from the Lotus
Developer Domain sandbox:

http://www-10.lotus.com/ldd/sandbox.nsf/cde4d8ccbe98e4868525676e0079ad34/670748e0f41ae33485256d18005c9205?OpenDocument

Content Based Routing (CBR) Component

The CBR component load balances based on the content of the request. Load
Balancer supports content-based routing in two ways: the CBR component and
the Dispatcher CBR forwarding method (discussed in Dispatcher).
In conjunction with the caching proxy, the CBR component has the ability to
proxy HTTP and HTTPS (SSL) requests to specific servers based on the content
requested. The Dispatcher component also provides content-based routing, but
it does not require the caching proxy to be installed. Because the Dispatcher
component’s content-based routing is performed in the kernel as packets are
received, it can provide faster content-based routing than the CBR component.

When do you use which CBR method

For fully secure SSL traffic (client through server):

• The CBR component (in conjunction with the caching proxy) can process SSL encryption/decryption in order to perform content-based routing.
• The Dispatcher CBR forwarding method can only be configured with SSL ID affinity because it cannot process the encryption/decryption to perform true content-based routing on the requested URL.

For HTTP traffic the Dispatcher CBR forwarding method provides a faster
response to client requests than the CBR component. Also, the Dispatcher CBR
forwarding method does not require the installation and use of a caching proxy.

Site Selector

This component performs load balancing using a DNS round-robin approach or a
more advanced user-specified approach. Site Selector works in conjunction with
a name server to map DNS names to IP addresses. System Metrics (provided by
the metric server) should be used in addition to advisor weights to achieve a
well-balanced and accurate weighting of servers

Cisco CSS Controller and Nortel Alteon Controller

These controllers can be used to generate server weighting metrics that are then
sent to the Cisco and Alteon Switch, respectively, for optimal server selection,
load optimization, and fault tolerance