Load Balancer overview
Load Balancer consists of the following five components that can be used
separately or together:
- 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,
our test environment we used the Dispatcher component.
Session affinity is an option that applies to all of these components.
The Dispatcher component distributes the load it receives to servers contained
a cluster (a set of servers that run the same application and can provide
same contents to its clients). This mechanism is also known as IP spraying.
Dispatcher decides which server will handle a certain TCP/IP connection
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
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
will not change no matter the conditions of the balanced servers, for example,
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
server will always receive twice the load as the first server. The only
this is when an Advisor detects a failed server.
If you choose to work with dynamic weights (which is the default option,
we did in our test environment), Dispatcher will calculate the load of
balanced server dynamically. In our previous example, if the response time
second server was slower than the response time of the first server, it
be possible to detect this and generate the correct weight value according
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
balanced servers. These components are:
- Metric server
Load balancing can handle any TCP/IP-compliant protocol, including
the Sametime proprietary protocols. For example, Dispatcher can provide
balancing for protocols such as HTTP, HTTPS, FTP, NNTP, IMAP, POP3,
SMTP, Telnet, and so on.
is the core component of
Dispatcher, and it is responsible for the load
distribution. It receives the packet, identifies whether this packet is
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
connection table in memory to keep track of all active connections. After
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,
administrator needs to associate an IP address to the variable NFA
(non-forwarding address). This variable contains the IP address that is
all connections that should not be load balanced by Dispatcher, like telneting
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 load balancing is concerned.
is the component responsible
for providing weight values of each
balanced server to Executor, so it can make its load balancing decision.
this component is optional, but it is necessary for dynamic weighting of
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
- The Advisors
- The Metric Server
For additional information refer to Configure the Manager component.
The Advisors are lightweight clients that run on the Dispatcher server,
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
and submits a request that validates the health of that service. This means
the advisor actually tests the service, not only the connectivity to the
system can be reachable by ping, but if the server is not running, it cannot
used in load balancing). The advisor then returns a value to the manager,
represents how long it took for each server to respond. If it does not
response from a server, it provides a value of -1 for this server, which
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.
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
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
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
shown in Figure D-1.
There are three methods used by Executor to forward packets to the balanced
- 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
This is the default forwarding method. When Dispatcher receives a packet
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
the source IP address remains the IP address of the client machine, and
destination IP address remains the cluster IP address.
When the balanced server receives the packet, it responds directly to the
(because the source IP address in the packet belongs to the client).
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
server to the client. This requires that all balanced servers be connected
same subnet as Dispatcher. See Figure D-2.
This method also requires that the services running on the balanced servers
able to accept the packets containing the cluster IP address as the destination
address. The easier solution is to add an IP alias to the loopback interface
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,
instructions on how to add an IP alias in various operating systems.
Network Address Translation (NAT)/ Network Address Port
This forwarding method allows Dispatcher to provide load balancing for
servers, which is not available in the MAC forwarding method.
Dispatcher receives the TCP/IP packet and chooses which server to send
rewrites the IP header and changes the source IP address (which is originally
IP address of the client machine), puts the return address instead (this
is an IP
address configured by the Dispatcher administrator), changes the destination
address (which is originally the IP address of the cluster), and puts the
server IP address instead. Now this packet can be routed to the balanced
even if it is on a remote network. But because Dispatcher changes the packet,
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
you configure on the cluster configuration does not need to be the same
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
addresses in the IP header of the TCP/IP packet.
This method implies that Dispatcher needs to handle all traffic, both inbound
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
For the HTTP protocol, the connection distribution is based on the contents
the URL or the HTTP header. For the HTTPS protocol, the distribution is
on the SSL session ID field of the client request.
CBR also allows load distribution to servers connected to remote networks.
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,
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
HTTPS, FTP, Telnet, DB2, DNS, LDAP, SMTP, and others.
Standard advisors send transactions periodically to determine the status
servers (for example, for HTTP an HTTP HEAD request is sent, and for FTP
SYST command is sent). If the transaction succeeds, the server is considered
Load Balancer also provides a generic advisor, called Connect, that can
in case you need to load balance a service or protocol for which there
dedicated advisor available. Connect opens a connection to the server using
server port informed in the advisor configuration and closes the connection
the TCP/IP handshake is done. As there is not an out-of-the-box advisor
Sametime. We used the Connect advisor in our test environment.
By default, the only available forwarding method is MAC forwarding.
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
Refer to Chapter 5 in the IBM Redbooks publication WebSphere Application
Server V6 Scalability and Performance Handbook
the NAT Scenario, for more details on how to enable all available forwarding
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
You may also set the connecttimeout and receivetimeout parameters
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)
load. A downed server is given a weight of zero by the Executor, and packets
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
Port column of the Manager report. The manager obtains these values from
its sources and sets proportional weight values for Executor.
You can also write your own advisors for specific applications like Sametime.
These are called custom
, and you can write your own
advisor based on
sample Java code provided with the product. The sample code is available
/servers/samples/CustomAdvisors directory, where install_path
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
name you choose for the advisor.
For the Edge Components that are part of IBM WebSphere
Application Server Network Deployment V6, you need Java compiler Version
Using the Java SDK, the compile command is:
javac -classpath /servers/lib/ibmlb.jar ADV_<name
The advisor code must then be copied to the
install_path/servers/lib/CustomAdvisors directory, and it can be started
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
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:
More detailed information about custom advisors specifically for Sametime
be found in the developerWorks article “Sametime Chat Network Dispatcher
Which includes a link to their code for the Sametime Chat Advisor from
Developer Domain sandbox:
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
the Dispatcher CBR forwarding method (discussed in Dispatcher).
In conjunction with the caching proxy, the CBR component has the ability
proxy HTTP and HTTPS (SSL) requests to specific servers based on the content
requested. The Dispatcher component also provides content-based routing,
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
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
- 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
forwarding method does not require the installation and use of a caching
This component performs load balancing using a DNS round-robin approach
more advanced user-specified approach. Site Selector works in conjunction
a name server to map DNS names to IP addresses. System Metrics (provided
the metric server) should be used in addition to advisor weights to achieve
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
sent to the Cisco and Alteon Switch, respectively, for optimal server selection,
load optimization, and fault tolerance