Load Balancer Port

Cluster | Rule-based-load balancing

Load Balancer Port

+
Search Tips | Advanced Search

The most important parameter for port performance is the forwarding method, which is defined when adding the port to the cluster.
MAC forwarding is the fastest method, but you can only use it if all your load-balanced Web servers are in the same IP network.
NAT forwarding is a little slower, as it requires that Load Balancer also processes the Web server responses.
With MAC forwarding, the IP source IP address information is not modified, so the Web servers can send their responses directly back to the client.) Content-based routing is generally the most expensive method, depending on the routing algorithm and the complexity of the rules in use (see Rule-based load balancing.
You could increase balancing performance by working without server weights, for example, without manager and advisors. However, we do not recommend this, as you would not be able to automatically detect Web server outages and you might risk server overloading.
Once a port is created, its forwarding method cannot be changed, but there are several configuration options that can be changed at runtime.
To display port settings, select...
Port: PortNumber | Configuration

The following parameters have an impact on performance:

Stale time out For Load Balancer, connections are considered stale when there has been no activity on that connection for the number of seconds specified in stale time out. When the number of seconds has been exceeded with no activity, Load Balancer will remove that connection record from its tables, and subsequent traffic for that connection will be discarded.
Some well-defined ports have different default stale time-out values. For example, the Telnet port 23 has a default of 259,200 seconds. Some services may also have staletimeout values of their own.
Connectivity problems can occur when Load Balancer's stale timeout value is smaller than the service's timeout value. Clients may then believe that they have connections to the server after the timeout value, but Load Balancer will discard all connections in that case.
You can use stale timeout and FIN timeout (at the executor level) to control the cleanup of connection records.
Weight bound This specifies the maximum weight boundary that any server can have. Weights are set by the manager function based upon internal counters in the executor, feedback from the advisors, and feedback from a system-monitoring program, such as metric server. As you increase this number, the difference in how servers can be weighted is increased. At a maximum weightbound of 2, one server could get twice as many requests as another. At a maximum weightbound of 10, one server could get 10 times as many requests as another. The default maximum weightbound is 20.
Sticky time See 19.3, Server affinity.
Port protocol This is only changeable for MAC forwarding. Depending on the protocol that you are balancing, this can be set to TCP, UDP, or both. In case of HTTP, it must be either TCP or both.
Cross port affinity See 19.3, Server affinity.
Sticky address mask bits See 19.3, Server affinity.
Maximum number of half-open connections The threshold for the maximum half-open connections. Use this parameter to detect possible denial of service attacks that result in a large number of half-opened TCP connections on servers.
A positive value indicates that a check will be made to determine whether the current half-open connections exceed the threshold. If the current value is above the threshold, a call to an alert script is made. See "Denial of service attack detection" in Load Balancer Administration Guide, GC31-6858, for more information about how to set this up.
Send TCP resets If TCP reset is activated, Dispatcher will send a TCP reset to the client when the client has a connection to a server whose weight is 0. A server's weight may be 0 if it is configured as 0 or if an advisor marks it down. A TCP reset will cause the connection to be immediately closed. This feature is useful for long-lived connections where it hastens the client's ability to renegotiate a failed connection.
A useful feature to configure, in conjunction with TCP reset, is advisor retry. With this feature, an advisor has the ability to retry a connection before marking a server down. This would help prevent the advisor from marking the server down prematurely, which could lead to connection-reset problems. That is, just because the advisor failed on the first attempt does not necessarily mean that the existing connections are also failing. See 19.2.7, Advisor.

Stale time out	For Load Balancer, connections are considered stale when there has been no activity on that connection for the number of seconds specified in stale time out. When the number of seconds has been exceeded with no activity, Load Balancer will remove that connection record from its tables, and subsequent traffic for that connection will be discarded. Some well-defined ports have different default stale time-out values. For example, the Telnet port 23 has a default of 259,200 seconds. Some services may also have staletimeout values of their own. Connectivity problems can occur when Load Balancer's stale timeout value is smaller than the service's timeout value. Clients may then believe that they have connections to the server after the timeout value, but Load Balancer will discard all connections in that case. You can use stale timeout and FIN timeout (at the executor level) to control the cleanup of connection records.
Weight bound	This specifies the maximum weight boundary that any server can have. Weights are set by the manager function based upon internal counters in the executor, feedback from the advisors, and feedback from a system-monitoring program, such as metric server. As you increase this number, the difference in how servers can be weighted is increased. At a maximum weightbound of 2, one server could get twice as many requests as another. At a maximum weightbound of 10, one server could get 10 times as many requests as another. The default maximum weightbound is 20.
Sticky time	See 19.3, Server affinity.
Port protocol	This is only changeable for MAC forwarding. Depending on the protocol that you are balancing, this can be set to TCP, UDP, or both. In case of HTTP, it must be either TCP or both.
Cross port affinity	See 19.3, Server affinity.
Sticky address mask bits	See 19.3, Server affinity.
Maximum number of half-open connections	The threshold for the maximum half-open connections. Use this parameter to detect possible denial of service attacks that result in a large number of half-opened TCP connections on servers. A positive value indicates that a check will be made to determine whether the current half-open connections exceed the threshold. If the current value is above the threshold, a call to an alert script is made. See "Denial of service attack detection" in Load Balancer Administration Guide, GC31-6858, for more information about how to set this up.
Send TCP resets	If TCP reset is activated, Dispatcher will send a TCP reset to the client when the client has a connection to a server whose weight is 0. A server's weight may be 0 if it is configured as 0 or if an advisor marks it down. A TCP reset will cause the connection to be immediately closed. This feature is useful for long-lived connections where it hastens the client's ability to renegotiate a failed connection. A useful feature to configure, in conjunction with TCP reset, is advisor retry. With this feature, an advisor has the ability to retry a connection before marking a server down. This would help prevent the advisor from marking the server down prematurely, which could lead to connection-reset problems. That is, just because the advisor failed on the first attempt does not necessarily mean that the existing connections are also failing. See 19.2.7, Advisor.