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.