|
Abstract |
The High Availability function for Load Balancer requires
users to customize the go scripts. This document explains how
to do this customization in more detail than what is covered in the Load
Balancer samples or in the Load Balancer Administration Guide. |
|
|
Content |
When Load Balancer is installed, sample go scripts are
installed in the
install_root/opt/ibm/edge/lb/servers/samples
directory, which is typically c:\program
files\ibm\edge\lb\servers\samples for Microsoft® Windows® operating
systems).
Go scripts are command files that are invoked upon certain
changes within the state of Load Balancer. They configure and unconfigure
the cluster addresses and return addresses. Thus, the go scripts
should be unique for each deployment because the IP address of the cluster
address and the return address differ.
There are two types of addresses that you can configure or unconfigure in
the go scripts:
- Cluster addresses - These IP addresses are used in Media
Access Control (MAC), Network address translation (NAT), and Content-based
routing (CBR) forwarding methods that you use to access the service that
is needed.
- Return addresses - These IP addresses are used by Load
Balancer in the NAT and CBR forwarding methods as the source address when
the client load balances a request to the server.
Go scripts have a .cmd extension in Windows operating systems.
The go scripts include:
- goActive - This script is called when high
availability is defined and Load Balancer has detected that it should be
actively forwarding traffic for a cluster address. Usually, this script
involves configuring cluster and return addresses.
Also, if any special configuration is made when the machine is running as
the backup Load Balancer, this configuration should be undone in the
goActive script. The most common special configuration is
configuring the machine to act as a server when the machine is the backup
Load Balancer. This type of configuration is discussed later.
- goStandby - This script is called when high
availability is defined and the Load Balancer is forwarding traffic.
However, it has detected that the partner Load Balancer can forward
traffic more efficiently.
This script unconfigures all of the clusters and the return addresses. If
the machine requires a special configuration when it is running as the
backup Load Balancer, make the configuration change in this script.
- goIdle - This script is called when high
availability is not defined. This script is optional for all of the
supported operating systems. You can use this script to log information
about the start of the forwarding functionality, to notify a user that the
product is starting, or to use any other feature that you can code into a
script.
- goInOp - This script is called when the executor
function is stopped. This script should be identical to the goStandby
script.
The goInOp script unconfigures all of the clusters and return
addresses and adds any configuration requirements for the server when it
is in a backup mode.
The go scripts are provided as samples. Edit these scripts to
reflect the deployment clusters and return addresses. If you use NATor CBR
forwarding, both the clusters and the return addresses must be configured
and unconfigured in these scripts. If you use MAC forwarding, configure
and unconfigure the cluster addresses only in the scripts.
After the go scripts are finalized, move them to the
install_root/opt/ibm/edge/lb/servers/bin
directory. Typically, the path is c:\program
files\ibm\edge\lb\servers\bin for Windows operating systems.
Configuring the loopback adapters
You do not need to configure the loopback adapter unless you are using MAC
forwarding and you have a server that is collocated on the same machine as
Load Balancer. You can have one Load Balancer with a collocated server and
another Load Balancer without a collocated server. In this case, configure
and unconfigure the loopback on the Load Balancer with a collocated server
only and not on the Load Balancer without a collocated server.
When you configure and unconfigure the loopback adapter with the
go scripts, the syntax should be identical to the syntax that is
described for configuring the loopback addresses for the back-end server.
Note: For Windows operating systems, the Administration Guide for
Load Balancer documents a method with the graphical user interface (GUI)
for configuring the loopback adapter, and you will want to use the netsh
command to allow this configuration from a script.
Collocated servers
If you are using a collocated server, verify that the collocate
flag is set to yes in the server add command or in the server
set command only if you are using the MAC forwarding method. Configure
this setting in the configuration file for Load Balancer and not in the
go scripts.
Timed delay for switching between the backup and active Load Balancer
machines
When the active and the backup Load Balancers communicate to determine
Load Balancer that should be actively forwarding traffic, they communicate
using IP traffic that uses the Generic routing encapsulation (GRE)
protocol. A port is not associated with GRE traffic, so an IP trace that
is based upon the High Availability port does not capture any data.
When the Load Balancer machines determines which machine should be active,
the backup machine runs the goStandby script and the active
machine waits two seconds before running the goActive script.
This delay is present to ensure that the IP addresses are released before
they are configured on the active machine. In some cases, this two second
delay might not be long enough; this is particularly true in an OS/390®
environment. In these cases, add a sleep delay at the beginning of the
goActive script to allow extra time for the IP addresses to be
released from the partner machine.
Mutual High Availability
Mutual High Availability allows both Load Balancers to forward traffic
while acting as a backup for each other. To use Mutual High Availability,
you must define at least two clusters.
Mutual High Availability is generally discouraged because machines are
often overloaded. In these cases, one machine is forced to handle all of
the network traffic in the event of a failover and it might not be able to
handle the workload.
If you have configured High Availablity, the Load Balancer that is active
sends information about its connections to the backup machine and the
backup Load Balancer acknowledges receipt of the transaction. This
scenario is referred to as the machines "syncing" with each other. Mutual
High Availability requires that each machine is able to run the syncing
process with the partner. However, the process can be less efficient and
requires more time than a configuration with basic high availability.
With Mutual High Availability, the non-forwarding address of each Load
Balancer is defined in the go scripts. Under each clause that
corresponds to an non-forwarding address, Load Balancer configures or
unconfigures the clusters and the return addresses for that specific
non-forwarding address. When a cluster is configured to Load Balancer
through configuration and not through the go scripts, use the
primaryhost keyword and give the correct non-forwarding address for Mutual
High Availability to work correctly.
The primaryhost keyword should be the same on both of the cluster
definitions for each Load Balancer. For example:
dscontrol cluster add 1.2.3.4 primaryhost 9.37.240.6
Mutual High Availability has been deprecated and it will be removed in a
future release.
Load Balancers with more than one network adapter
If the Load Balancer machine has more than one adapter, specify the
non-forwarding address with the following command:
executor set nfa x.x.x.x
The non-forwarding address adapter is used to send connection information
to the partner machine. If you have more than one heartbeat defined,
ensure that the non-forwarding address on each machine corresponds to the
same heartbeat pair. |
|
|
|
Original publication
date |
2007/4/3 |
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|
|