Avaya P333R-LB Manuel D’Utilisation
Chapter 14
Load Balancing in the P333R-LB
56
Avaya
P333R-LB User’s Guide
You need to verify that the configured request results in the configured expected
response. P333R-LB searches for the expected string only in the first packet sent
by the server as a response to the script query.
A successful Script Health Check is defined as one with a valid expected string,
as well as a successful completion of the TCP connection.
response. P333R-LB searches for the expected string only in the first packet sent
by the server as a response to the script query.
A successful Script Health Check is defined as one with a valid expected string,
as well as a successful completion of the TCP connection.
Note:
In the Script Health Check query and expected-string “\r\n” denotes “enter”.
Refer to page 202 for a sample Script Health Check configuration.
Note:
The default health check method for Application Redirection is Ping.
For the commands to configure the different Health Checks, refer to Health Check
Commands on page 258.
Commands on page 258.
Client Persistency
Persistency is a way to ensure that all traffic related to a given session, and all
sessions of a given characteristic are served by the same server.
Client persistency is the persistency between many sessions for one client. Client
persistency ensures that all traffic from the client is directed to the same Real Server.
Client persistency is achieved either by using naturally persistent load balancing
schemes (such as Hash or MinMiss Hash) or by forcing persistent load balancing
decisions on non-persistent load balancing schemes (such as Round Robin).
Decision forcing is performed by storing the history of the latest decisions in a cache
for a limited time, and sending the packets to the appropriate server based on
previous load balancing decisions.
Regardless of the client persistency nature of the selected load balancing metric,
P333R-LB offers a unique client persistency feature that is available in all load
balancing metrics. Client persistency is based on a "persistency cache". Load
balancing decisions are recorded in a persistency cache for a specified time
configured by the user. When a new session that matches an entry in the persistency
cache is processed by P333R-LB, it is directed to the same server pointed by the
cache (provided, of course, that the server is considered healthy).
The key to the persistency cache is based on the client IP, in combination with a
wildcard. This allows persistency to be configured per an exact IP address, or per a
group of addresses. For instance, in cases where clients hide behind a NAT device
which selects NAT addresses from an address block of 255 addresses, enabling the
persistency cache with a wildcard of 0.0.0.255 maps all clients to a single entry and a
single Real Server.
sessions of a given characteristic are served by the same server.
Client persistency is the persistency between many sessions for one client. Client
persistency ensures that all traffic from the client is directed to the same Real Server.
Client persistency is achieved either by using naturally persistent load balancing
schemes (such as Hash or MinMiss Hash) or by forcing persistent load balancing
decisions on non-persistent load balancing schemes (such as Round Robin).
Decision forcing is performed by storing the history of the latest decisions in a cache
for a limited time, and sending the packets to the appropriate server based on
previous load balancing decisions.
Regardless of the client persistency nature of the selected load balancing metric,
P333R-LB offers a unique client persistency feature that is available in all load
balancing metrics. Client persistency is based on a "persistency cache". Load
balancing decisions are recorded in a persistency cache for a specified time
configured by the user. When a new session that matches an entry in the persistency
cache is processed by P333R-LB, it is directed to the same server pointed by the
cache (provided, of course, that the server is considered healthy).
The key to the persistency cache is based on the client IP, in combination with a
wildcard. This allows persistency to be configured per an exact IP address, or per a
group of addresses. For instance, in cases where clients hide behind a NAT device
which selects NAT addresses from an address block of 255 addresses, enabling the
persistency cache with a wildcard of 0.0.0.255 maps all clients to a single entry and a
single Real Server.