The manager function of Load Balancer calculates a weight
for each server. These weights are used to determine how many connections
a server should receive as compared with the other servers in the
same cluster and port configuration. Understanding the manager report
is critical to understanding how the network traffic is distributed.
The manager report contains a list of each cluster, port, and server
that is defined to that cluster:port combination. Each server shows
two weights, now and new, and four columns that are used to calculate
the weight:
- Active connections (ACTV) or CPU (in the case of Site Selector
component based on input from the Metric Server)
- New connections (NEWC) or Memory (in the case of Site Selector
component based on input from the Metric Server)
- Port Load (PORT)
- System load (SYS)
Each of the four columns is assigned a percentage that is used
to calculate the weight for the server. The percentages are set with
the cluster set proportion command. By default, only the active connections
and new connections are considered when calculating the weight of
the server in the case of Dispatcher and CBR. These values are based
on information that is generated and stored internally in the executor.
For Site Selector, the manager obtains the first two values (CPU and
memory) from Metric Server.
When an advisor is started, the proportion for the port load is
set to 1% so that the port load is used in the weight calculation.
Similarly, when a metric is added the proportion for the system load
is set to 1%. The manager function returns the following values for
each server:
- Active connections (ACTV)
- Active connections are TCP connections that are closed at the
start of the manager cycle.
- New connections (NEWC)
- New connections represent the increase in total connections from
the start of the manager cycle to the start of the last manager cycle.
- Port Load (PORT)
- The port load is the value that is obtained from an advisor that
is defined on this cluster:port combination. If an advisor is not
started, the port load is always zero. When an advisor is defined,
the port load typically represents the number of milliseconds for
the advisor to receive a response from the server.
When the port
load is shown as -1, the advisor did not receive a successful response
to its query. Increase the log level and log size for the advisor
to investigate why the server did not respond. If the server never
responds to the connection request, complete the following steps:
- Ensure that you can successfully ping the server from the Load
Balancer machine.
- Verify that the server application is started and listening on
the port that is defined. The server should be listening on the wildcard
address (0.0.0.0), or both the cluster IP address and the real server
IP address to successfully respond to the advisor requests.
If the server responds to the connection, then it might be responding
to the query in a manner that is different from what Load Balancer
is expecting to see. Check the advisorresponse string that is defined
to ensure it matches what the server has transmitted. This scenario
applies to both http and https advisors.
- System load (SYS)
- The system load represents the value that is returned from the
metric server. If metrics have not been added for this cluster:port
combination, the system load is zero (0). When metrics are defined,
the system load is a value in between -1 and 100, which represents
the status of the server. 100 is very busy and zero (0) is idle.
If
the system load shows -1, Load Balancer cannot communicate with the
metric server on the back-end machine. Ensure Load Balancer keys are
properly distributed to the server, that the server can be pinged
from the Load Balancer, and that metric server is started on the machine.
If the problem persists, complete the following steps:
- Edit the script for the metric server on the back-end machine
and increase both the log level and log size.
- Restart the metric server.
- Increase the the log size and the log level for the metric monitor
at the Load Balancer.
- Examine the log files on both the Load Balancer machine and the
back-end machine to determine why communication is failing.
- CPU and Memory (Site Selector component)
- The CPU and Memory represent the values that are returned from
the metric server . Cpuload and memload metrics are added automatically
for the Site Selector configuration. CPU and Memory are values in
between -1 and 100, which represent the status of the server. 100
is very busy and zero (0) is idle. If these metrics show -1, Load
Balancer cannot communicate with the metric server on the back-end
machine. Ensure Load Balancer keys are properly distributed to the
server, that the server can be pinged from the Load Balancer, and
that metric server is started on the machine. If the problem persists,
complete the following steps:
- Edit the script for the metric server on the back-end machine
and increase both the log level and log size.
- Restart the metric server.
- Increase the log size and the log level for the metric monitor
at the Load Balancer.
- Examine the log files on both the Load Balancer machine and the
back-end machine to determine why communication is failing.
The number of active connections and new connections are determined
based upon the number of connections that the executor has forwarded
within the last cycle of the last manager function. The manager cycle
is two seconds, by default.
Configuring server weights
Under normal circumstances, Load Balancer uses all of the values
that have proportions that are not zero to calculate the new weight.
For example, if the proporations are 40 40 20 0, the active connections
and new connections are 40% of the weight calculation each and the
port load is 20%.
As an example, assume the manager function returns the following
values:
ACTV NEWC PORT SYS
Server1 50 200 25 0
Server2 25 100 50 0
The initial
weight calculations will be:
- Server1 = .40(50) + .40(200) + .2(25) = 20 + 80 + 5 = 105
- Server2 = .40(25) + .40(100) + .2(50) = 10 + 40 + 10 = 60
The initial weights are scaled to be proportional to the weightbound
for the cluster:port. By default, the weightbound is 10. Thus, in
the previous example, the final weights, which are rounded to the
nearest whole number, are:
- Server1 = (105/165) * 10 = 6
- Server2 = ( 60/165) * 10 = 4
The calculated weight is shown as the NEW weight in the manager
report. The weight is only pushed to the executor function if it exceeds
the sensitivity level that is configured for the cluster:port combination.
The NOW weight represents the weight that is obtained from the executor
at the start of this manager cycle.
If the port load or the system load is -1, and the respective proportion
for the port or system column is greater than 0, the calculated weight
is zero (0). Zero (0) indicates that the server is not active and
new requests are not sent to the server.
If you quiesce a server, you will see that the weight is also shown
as zero (0), but the port load is positive if the server is still
online. If a quiesced server goes offline, the port load is -1.
If a user issues a "server down" function on a server to prevent
Load Balancer from sending requests to that server, the weight is
-1 regardless of the value for the port load and system load.