Network Load Balancer Client Affinity via Exception Lists
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current network load balancing technologies fail to maintain affinity with a client for all connections, including new connections, after cluster configuration changes, which is problematic for applications requiring the same node to handle all connections from a client regardless of changes.
Innovation Solution
Implementing a network load balancing system where each node maintains an affinity list of clients and propagates this information to other nodes, allowing the node owning the bucket to handle packets even if it no longer owns the bucket, by using affinity and exception lists to ensure client-node affinity is preserved during bucket redistribution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If bucket redistribution is performed during convergence after cluster configuration changes, then load balancing is improved, but client-node affinity is lost causing new connections to be handled by different nodes
Solution Approach 1:
The system performs preliminary actions by maintaining affinity lists that track which nodes previously handled connections from which clients. During convergence, these affinity lists are propagated to ensure that even if bucket ownership changes, nodes can still identify and maintain affinity with their original clients through the propagated affinity information.
Solution Approach 2:
The affinity list acts as an intermediary mechanism between bucket redistribution and client connection handling. By propagating affinity lists during convergence, the system creates a mediating layer that allows nodes to recognize and maintain client affinity relationships even when bucket ownership changes, thus preserving client-node affinity while enabling load balancing.
2Reliability
If the same node handles all connections from a client regardless of bucket ownership, then client affinity is maintained, but packet routing complexity increases requiring affinity list propagation and exception list building
Solution Approach 1:
The system segments the routing decision process into distinct components: affinity list maintenance at each node, affinity list propagation during convergence, and exception list building at bucket-owning nodes. This segmentation allows each node to handle a specific aspect of the complexity rather than requiring all nodes to implement complete affinity tracking logic.
Solution Approach 2:
Each node independently maintains its own affinity list and participates in propagating affinity information during convergence without requiring centralized coordination. Nodes autonomously build their exception lists based on received affinity information, distributing the complexity management across all nodes rather than concentrating it in a single controller.
3Reliability
If affinity lists are propagated during convergence, then client affinity is preserved after bucket redistribution, but convergence time and communication overhead increase
Solution Approach 1:
The system merges the affinity list propagation process with the existing convergence procedure. By integrating affinity information exchange into the standard convergence flow, the system leverages existing communication infrastructure and timing rather than adding a separate, time-consuming propagation phase. This combining approach preserves client affinity while minimizing additional convergence time.
Data Source
AI summary
Described is a technology in a network load balancing system (node cluster), by which client affinity is preserved across cluster configuration changes, including for new connections from a previous client. Each node maintains a list of the clients that are to remain (have affinity, or “stickiness”) with that node, including following bucket redistribution resulting from convergence. Each affinity list is communicated during convergence so that other nodes may build an exception list or lists. Via a node's exception list, the node that owns a bucket corresponding to a client knows of the affinity with another node and thus drops any packets from that client. Affinity may expire, whereby the node having affinity with that client releases it and notifies the node owning the bucket for that client that the client is no longer to be treated as an exception.