Load Balancer provides user exits that trigger scripts
that you can customize. You can create the scripts to perform automated
actions, such as alerting an Administrator when servers are marked
down by the manager or simply record the event of the failure.
Sample scripts, which you can customize, are in the
install_root/servers/samples
directory. In order to run the files, you must move them to the
install_root/servers/bin
directory and remove the ″sample″ file extension. The following sample
scripts are provided:
- serverDown — a server is marked down by the manager.
- serverUp — a server is marked back up by the manager.
- managerAlert — all servers are marked down for a particular
port.
- managerClear — at least one server is now up, after all
were marked down for a particular port.
If all servers on a cluster are marked down (either by the user
or by the advisors), the managerAlert (if configured) starts, and
Load Balancer attempts to route traffic to the servers using a round-robin
technique. The serverDown script does not start when the last server
in the cluster is detected as offline. By design, Load Balancer attempts
to continue to route the traffic in case a server comes back online
and responds to the request. If Load Balancer instead dropped all
traffic, the client would receive no response. When Load Balancer
detects that the first server of a cluster is back online, the managerClear
script (if configured) starts, but the serverUp script (if configured)
is not run until an additional server is brought back online.
Here are some considerations for using the serverUp and serverDown
scripts:
- If you define the manager cycle to be less than 25% of the advisor
time, false reports of servers up or down can result. By default,
the manager runs every 2 seconds, but the advisor runs every 7 seconds.
Therefore, the manager expects new advisor information within 4 cycles.
However, removing this restriction (that is, defining the manager
cycle to be greater than 25% of the advisor time) significantly decreases
performance because multiple advisors can advise on a single server.
- When a server goes down, the serverDown script starts. However,
if you issue a serverUp command, it is assumed that the server is
up until the manager obtains new information from the advisor cycle.
If the server is still down, the serverDown script runs again.