Session Affinity via Appended Clone IDs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed networking environments, maintaining session affinity across multiple server groups is challenging, especially when requests sharing a session ID switch between server groups and then return to the original group, leading to inefficiencies due to the need for session data retrieval from a database, which is time-consuming and resource-intensive.
Innovation Solution
A method and apparatus that append a clone identification code to the session identification code, allowing requests with a given session ID to be directed to the same clone within a server group whenever possible, even when switching between server groups, by parsing the universal resource identifier (URI) and appending new clone identification codes without overwriting existing ones, ensuring consistent routing and minimizing database reads.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If session affinity is maintained across multiple server groups by appending clone identification codes, then session data can be kept locally improving performance, but the session identification code becomes more complex requiring multiple codes to be tracked
Solution Approach 1:
The session identification mechanism is segmented into multiple components: the original session ID and multiple appended clone identification codes. Each clone ID represents a specific server group that has handled requests for that session, allowing the system to track session history across server group boundaries while maintaining local session data caches.
Solution Approach 2:
Clone identification codes are nested within the session identification structure by appending them to the session ID. This creates a hierarchical identification system where the session ID contains within it the history of server groups that have serviced that session, enabling efficient lookup and routing decisions.
2Reliability
If requests are routed to the same clone within a server group by appending clone identification codes, then session affinity is improved, but the routing logic becomes more complex requiring URI parsing and code matching
Solution Approach 1:
The system performs preliminary actions by appending clone identification codes to the session ID during the initial request routing. This pre-computed information is then reused for subsequent routing decisions, eliminating the need for complex real-time analysis of session history and enabling simple match-based routing logic.
Solution Approach 2:
The appended clone identification code acts as an intermediary between the session ID and the routing logic. Instead of requiring the routing system to interpret complex session history or maintain external state, the intermediary code directly encodes the routing information needed to maintain session affinity across server group transitions.
3Loss of time
If session data is stored locally in server groups rather than in a database, then access efficiency improves, but session data must be maintained across server group switches which increases complexity
Solution Approach 1:
Each server group maintains its own session data cache and can independently service requests for sessions it has previously handled. The appended clone identification codes enable server groups to self-determine whether they have the session data locally, eliminating the need for centralized database queries and enabling autonomous session data management.
Data Source
AI summary
The invention is a method and apparatus for maintaining session affinity within a server farm when requests sharing a session ID switch between server groups or between server clones in a single server group. In accordance with the invention, client requests include a list of clone identification codes, each code uniquely identifying a clone within a server group for handling the request. The clone identification code may be appended to a session identification code. For each different server that handles a request in a session, a new clone identification code is appended without deleting or overwriting any previously appended clone identification codes. When a request is received, the list of clone identification codes associated with the request is parsed in a predetermined order to search for the first clone identification code that matches one of the clone identification codes of a server in the appropriate server group. If a match is detected, the request is dispatched to that clone. If no match is found, the request is dispatched to a server clone in the server group using any reasonable Work Load Management (WLM) mechanism and then the clone identification code of the selected clone is added to the list.