Session Stickiness via Cluster ID in Non-Sticky Load Balancers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Stateful cloud services face interruptions due to session stickiness issues when non-sticky load balancers route client requests to incorrect server clusters, leading to out-of-sync state information and application malfunctions.
Innovation Solution
A system and method that initiate a stateful session by sending a session initiation request to a global endpoint, receiving a cluster identification, and resending requests to the correct server cluster upon error, ensuring subsequent requests are routed to the same server cluster by including the cluster identification in HTTP requests and responding with error messages for mismatched cluster IDs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If a non-sticky load balancer is used to distribute requests, then load balancing efficiency is improved, but session stickiness deteriorates causing requests to be routed to incorrect server clusters
Solution Approach 1:
The system performs preliminary actions by including the cluster identification in the initial response to the client before subsequent requests are made. This allows the client to know which cluster to address in future requests, ensuring session stickiness is established in advance before the non-sticky load balancer could potentially route requests incorrectly.
Solution Approach 2:
The cluster identification acts as an intermediary element that mediates between the load balancer's non-sticky routing and the requirement for session stickiness. By embedding this identifier in requests and responses, the system creates a communication channel that ensures requests are directed to the correct cluster despite the load balancer's lack of sticky session capability.
2Adaptability or versatility
If requests are routed to any available server cluster, then system availability is improved, but state synchronization deteriorates causing out-of-sync state information
Solution Approach 1:
The system applies local quality by making the request routing dependent on the specific cluster identification rather than using a uniform routing approach. Each request includes the specific cluster ID that it must be routed to, ensuring that the local property of cluster-specific routing is maintained while still allowing overall system availability through multiple clusters.
Solution Approach 2:
The server provides feedback by including the cluster identification in its response to the client. This feedback loop ensures that the client has accurate information about which cluster to address for subsequent requests, maintaining state synchronization while preserving system availability through proper request routing.
3Measurement precision
If cluster identification verification is implemented, then session accuracy is improved, but request processing complexity increases
Solution Approach 1:
The system implements self-service by having the client automatically include the cluster identification in its requests based on information received from the server. This eliminates the need for complex server-side verification logic, as the client autonomously ensures requests are directed to the correct cluster, maintaining session accuracy while minimizing added complexity.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Systems and methods are provided and include a processor, memory, and an application that is stored in the memory and includes instructions. The instructions are configured to initiate a stateful session for the application by sending a session initiation request addressed to a global endpoint and receive a response to the session initiation request from a first server of a first server cluster, the response including a cluster identification associated with the first server cluster. The instructions are further configured to send a session request addressed to the global endpoint, the session request including the cluster identification associated with the first server cluster. The instructions are further configured to receive an error message in response to the session request from a second server of a second server cluster to resend the session request addressed to the first server cluster in response to receiving the error message.