Customizing the go scripts for High Availability
 Product documentation
 
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
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Edge Component
Operating system(s): Windows
Software version: 6.1
Software edition:
Reference #: 7009574
IBM Group: Software Group
Modified date: Apr 6, 2007