Maintaining Client Affinity in Network Load Balancing Systems

• US 20100057923A1
• Filed: 08/29/2008
• Published: 03/04/2010
• Est. Priority Date: 08/29/2008
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Sen, Siddhartha, Yu, Jimmy C., D'Amato, Andrea, Petter, Vladimir
• Granted Patent: US 8,046,467 B2
• Time in Patent Office: Days
• US Class Current: 709/229
• CPC Class Codes: G06F 2209/505 Clust
• CPC Class Codes: G06F 9/5061 Partitioning or combining of resources
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/1027 Persistence of sessions during load balancing
• CPC Class Codes: H04L 67/1029 using data related to the state of servers by a load balancer
• CPC Class Codes: H04L 67/1031 Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests

Abstract

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.

Claims

1. A computer-readable medium having computer-executable instructions, which when executed perform steps, comprising:

receiving a packet at a node from a source; and

determining whether to drop or accept the packet based on data provided in the packet, including determining whether the packet maps to a bucket set comprising at least one bucket owned by the node, and

a) if the packet maps to the bucket set,

i) dropping the packet when the data indicates an exception, or

ii) accepting the packet; and

b) if the packet does not map to the bucket set,

i) accepting the packet when the data indicates that the node has affinity with a client connection corresponding to the source of the packet, or

ii) dropping the packet.

2. The computer-readable medium of claim 1 wherein dropping the packet when the data indicates an exception comprises accessing exception information to determine that the data corresponds to an exception.

3. The computer-readable medium of claim 1 having further computer-executable instructions comprising, building an exception list based on affinity information provided by at least one other node.

4. The computer-readable medium of claim 3 having further computer-executable instructions comprising, receiving information from another node that the other node has released affinity with a client connection, and in response, removing a client identifier corresponding to that client connection from the exception list.

5. The computer-readable medium of claim 1 wherein accepting the packet when the data indicates that the node has affinity comprises accessing an affinity list that contains information indicating that the node has affinity with the client connection.

6. The computer-readable medium of claim 5 having further computer-executable instructions comprising, removing a client identifier from the affinity list when a client corresponding to the client identifier has no connections for a period of time, and notifying an owner of a bucket corresponding to the client identifier of releasing affinity with the client connection.

7. The computer-readable medium of claim 6 having further computer-executable instructions comprising, entering a convergence phase, and communicating client affinity information to at least one other node.

8. In a computing environment, a system comprising, a plurality of nodes, each node including logic for selectively accepting only certain packets based on information contained within each packet, including logic that determines whether a packet maps to a bucket owned by that node, and whether the packet corresponds to a client with which the node has affinity or whether the packet corresponds to a client with which the node knows of an exception, and the logic configured to accept the packet when the node has affinity, or when the packet maps to a bucket owned by that node and there is no exception associated with the client corresponding to the packet.

9. The system of claim 8 wherein the logic is further configured to perform convergence, including sending affinity information to at least one other node, and to be notified of received affinity information from at least one other node, the logic building an exception list based on the received affinity information so as to know which client or clients have exceptions.

10. The system of claim 8 wherein the logic is further configured to remove an exception upon notification from another node that the other node no longer has affinity with a client.

11. The system of claim 8 wherein the logic is further configured to notify another node of no longer having affinity with a client.

12. In a computing environment, a method comprising, performing a convergence process among a plurality of nodes in a network load balanced cluster of nodes, including distributing buckets among nodes and communicating information that allows at least one node to maintain affinity with a client, including for any new connection from the client.

13. The method of claim 12 wherein communicating the information comprises sending an affinity list from one node to at least one other node, including to another node that owns a bucket to which packets from the client map.

14. The method of claim 13 further comprising, receiving a received affinity list at a node of the cluster, and using the received affinity list to build an exception list.

15. The method of claim 12 wherein communicating the information comprises identifying which buckets are empty, or identifying which buckets are not empty, or both identifying which buckets are empty and identifying which buckets are not empty, and wherein distributing the buckets among nodes comprises changing ownership of only empty buckets.

16. The method of claim 12 further comprising, entering a packet handling state, including receiving packets at each node of the cluster, and at each node, accepting the packet when that node has affinity, or when the packet maps to a bucket owned by that node and no other node has affinity.

17. The method of claim 16 further comprising, notifying at least one other node that affinity with a client is released such that another node accepts packets from that client.

18. The method of claim 17 further comprising, determining that affinity is to be released based upon a time limit associated with that client.

19. The method of claim 16 further comprising, at a given node, receiving a message indicating that another node has released affinity with a client, and in response, removing an exception for that client from an exception list maintained at the given node.

20. The method of claim 16 further comprising, exiting the packet handling state, and re-entering a new convergence state.