Common Causes of Load Imbalance using SOURCEIP Persistence

Symptoms

The NetScaler appliance load balances network traffic unevenly when configured with SOURCEIP-based persistence.

There are a few situations where this problem can occur and there are different ways to handle this problem.

Scenario 1: Proxy Clients

When a large number of clients are connected to the Virtual IP address (VIP) through a proxy server, that proxy server might translate the network address of the client source IP address. As a result the NetScaler appliance tracks this network traffic as coming from a single source. While in reality there may be 100 users, they are treated as a single user because of SOURCEIP persistence.

Scenario 2: Long-lived clients and services failing health checks

In situations where individual clients maintain long-lived connections, a problem can arise when a service fails a health check or is taken out of service. After the service is marked as DOWN all clients that were previously connected to the service are connected to another service. When the service is marked as UP, because of the long-lived nature of the connection or to the SOURCEIP persistence, they remain on the new server. This can give the impression that the original service is not used effectively.

In both scenarios, the outcome is not because of aberrant behavior of the appliance, or the persistence method, but to the way this persistence method works.

Resolution

Depending on requirements, there may be a few options to prevent or recover from this state.

Select a different persistence method.
Other methods might provide equally effective results without risking the problems seen in scenarios 1 or 2. For example, SSLSESSION tracks individual clients by the SSL Session ID number.
Disable or enable services.
To overcome scenario 2, it may be possible to briefly disable and enable services to clear the SOURCEIP persistence binding a client to a particular service, and allow a new service to be selected.
Do not select persistence.
Although there are certain types of traffic for which persistence is crucial, it might be possible to choose a different load-balancing method, and set the persistence type to NONE. Some load-balancing methods provide de facto persistence as part of the mechanism used to make load-balancing decisions.
For example, the Source-IP plus Source-Port Hash method calculates a value based on the client Source-IP and source port, and assigns a service to this hash value. So long as the client Source-Port remains the same, the client attaches to the same backend service. This allows many clients to approach the VIP from the same Source-IP (Scenario 1), but load balance their sessions because each uses a separate Source-Port.
Another example can be Source-IP Hash. In scenarios where the same pools of clients repeatedly access the VIP, each client IP is assigned a hash value, which maps to a backend service. If the designated service fails, the client is directed to an alternate service. When the service returns to an UP state, new connections from the client return to the original service. Both of these options provide de facto persistence because the hash value is calculated mathematically, and thus service selection does not change.

More Information

For more information on the Source-IP Hash load-balancing method, refer to the Installation and Configuration Guide.