Issue #

A user reports that they are using Relianoid for load balancing with cookie insertion-based session persistence. Initially, the setup was perfectly balanced with five servers. However, after adding a new server to the pool, sessions are not being distributed as expected. The new server only has a few sessions, while the existing servers continue to handle most of the traffic.

Explanation #

This issue arises because of the current session persistence mechanism and the load balancing algorithm in use.

Understanding the Problem #

1. Cookie Insertion-Based Session Persistence: When using cookie insertion for session persistence, the load balancer assigns a unique cookie to each client. This cookie directs subsequent requests from the same client to the same backend server, ensuring session persistence. This works well in a stable setup but creates challenges when a new server is added to the pool.

2. Existing Sessions Are “Sticky”: Since sessions are already established with the initial set of servers, these existing sessions remain “sticky” to their original backends due to the persistence cookie. Consequently, the newly added server only receives new sessions or traffic from new clients that have not yet been assigned a persistence cookie.

3. Current Scheduling Algorithm Limitations: Many load balancers use a default scheduling algorithm like Round Robin or Least Response Time. These algorithms do not necessarily rebalance the load when new servers are added, especially when session persistence is involved. This is because the algorithms tend to maintain connections to existing backends for active sessions.

Why Sessions Are Not Being Rebalanced #

When a new server is added, it does not immediately start sharing the load equally because:

• Existing sessions are bound to their original backends.
• The default scheduling algorithm does not prioritize backends with fewer sessions or connections.

To achieve a fair distribution of sessions, a different load balancing algorithm is needed.

Solution #

Use the “Least Connections” Scheduling Algorithm #

The Least Connections algorithm is a scheduling method where the load balancer selects the backend server with the fewest active connections. This approach helps distribute sessions more evenly, especially when a new server is added to the pool.

Here’s why “Least Connections” works effectively in this scenario:

• Dynamic Rebalancing: Unlike algorithms such as Round Robin, Least Connections constantly evaluates which server has the fewest active sessions. This allows the new server, which has fewer sessions initially, to receive more new connections until the load evens out.
• Better Resource Utilization: As new sessions are created, they will be directed to the server with the least load, improving overall resource utilization.

Steps to Implement the “Least Connections” Algorithm in Relianoid #

1. Access the Relianoid Load Balancer Configuration: Log in to your Relianoid administration console or use the CLI tools if applicable.
2. Navigate to the Load Balancer Settings: Locate the settings for your load balancer instance that is managing the server pool with session persistence.
3. Modify the Scheduling Algorithm:

• Find the setting for the load balancing algorithm or scheduling method.
• Change the algorithm from the current setting (e.g., Round Robin) to Least Connections.

4. Save and Apply Changes: Make sure to save your changes and apply them to the load balancer configuration. Depending on your environment, this might require restarting the load balancer or performing a soft reload.
5. Monitor and Verify: After applying the changes, monitor the session distribution across all servers. Over time, the new server should begin to receive more sessions, leading to a more balanced load.

Conclusion #

By changing the load balancing algorithm to “Least Connections,” you ensure that the newly added server can catch up and start handling more sessions. This dynamic scheduling method considers the number of active connections and efficiently distributes the load, resolving the imbalance issue caused by session persistence with cookie insertion.

If you continue to face issues after implementing this change, consider checking:

• The health and performance of the newly added server.
• The configuration for other parameters that might affect load balancing (e.g., session timeout settings, stickiness duration, etc.).
• Network or application-level logs for potential errors or bottlenecks.

By following these steps, you can optimize your load balancer configuration to ensure a fair and balanced session distribution across all servers in your pool.