LOAD-BALANCING CLUSTER

• US 20100332664A1
• Filed: 09/13/2010
• Published: 12/30/2010
• Est. Priority Date: 02/28/2008
• Status: Active Grant

• Current Assignee: Level 3 Communications LLC (Lumen Technologies, Inc.)
• Original Assignee: Level 3 Communications LLC (Lumen Technologies, Inc.)
• Inventors: Newton, Christopher, Koller, Jeffrey, Yevmenkin, Maksim, Fullagar, David
• Granted Patent: US 8,489,750 B2
• Time in Patent Office: Days
• US Class Current: 709/227
• CPC Class Codes: H04L 61/2528 Translation at a proxy
• CPC Class Codes: H04L 61/5007 Internet protocol [IP] addresses
• CPC Class Codes: H04L 67/02 based on web technology, e.g. hypertext transfer protocol [HTTP]
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/101 based on network conditions
• CPC Class Codes: H04L 67/1014 based on the content of a request
• CPC Class Codes: H04L 67/1023 based on a hash applied to IP addresses or costs
• CPC Class Codes: H04L 67/1036 Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
• CPC Class Codes: H04L 67/1068 Discovery involving direct consultation or announcement among potential requesting and potential source peers
• CPC Class Codes: H04L 67/141 Setup of application sessions admission control or resource allocation in data switching networks H04L47/70
• CPC Class Codes: H04L 67/568 Storing data temporarily at an intermediate stage, e.g. caching
• CPC Class Codes: H04L 69/326 in the transport layer [OSI layer 4] H04L69/16 takes precedence

Abstract

A load-balancing cluster includes a switch having a plurality of ports; and a plurality of servers connected to at least some of the plurality of ports of the switch. Each server is addressable by the same virtual Internet Protocol (VIP) address. Each server in the cluster has a mechanism constructed and adapted to respond to connection requests at the VIP by selecting one of the plurality of servers to handle that connection, wherein the selecting is based, at least in part, on a given function of information used to request the connection; and a firewall mechanism constructed and adapted to accept all requests for the VIP address for a particular connection only on the server that has been selected to handle that particular connection. The selected server determines whether it is responsible for the request and may hand it off to another cluster member.

Claims

1. A load-balancing cluster comprising:

(A) a switch having a plurality of ports; and

(B) a plurality of servers connected to at least some of the plurality of ports of the switch, each of said servers being addressable by the same virtual Internet Protocol (VIP) address, wherein each of said plurality of servers comprises;

a mechanism constructed and adapted to respond to a connection request at the VIP address by selecting one of said plurality of servers to handle that connection, wherein said selecting is based, at least in part, on a first given function of information used to request the connection;

a firewall mechanism constructed and adapted to accept all requests for the VIP address for a particular connection only on the server that has been selected to handle that particular connection;

a mechanism constructed and adapted to determine, when a server has been selected and when a request for a resource has been made, whether the server is responsible for the request for the resource, said determining being based, at least in part, on information associated with the request for the resource; and

a handoff mechanism constructed and adapted to handoff a network connection to another of said plurality of servers and to accept a handoff request from another of said plurality of servers, wherein the handoff mechanism determines whether to handoff a network connection or to accept a handoff request based on at least one attribute associated with the requested resource.

2. A load-balancing cluster as recited in claim 1, wherein the at least one attribute associated with the requested resource comprises at least one of the size of the requested resource and the popularity of the requested resource.

3. A load-balancing cluster as recited in claim 2, wherein the handoff mechanism is configured to accept a handoff request if the size of the requested resource exceeds a threshold value.

4. A load-balancing cluster as recited in claim 2, wherein the handoff mechanism is configured to accept a handoff request if the popularity of the requested resource does not exceed a threshold value.

5. A load-balancing cluster as recited in claim 2, wherein the other of said plurality of servers that does have a copy of the requested resource is configured to reject the handoff request if the popularity of the requested resource exceeds a threshold value, and wherein in response to receiving the rejection, the server obtains and serves the requested resource.

6. A load-balancing cluster as recited in claim 2, wherein the handoff mechanism is configured to accept a handoff request if the popularity of the requested resource does not exceed a popularity threshold value and the size of the requested resource exceeds a size threshold value.

7. A load-balancing cluster as recited in claim 1 wherein said request for the resource is an HTTP request.

8. A load-balancing cluster as recited in claim 7 wherein the information associated with the request for the resource comprises a URL.

9. A load-balancing cluster as recited in claim 8 wherein the HTTP request is an HTTP GET request and wherein the information associated with the request for the resource comprises a URL and at least one HTTP header.

10. A method, operable in a load-balancing cluster comprising:

a switch having a plurality of ports; and

a plurality of servers connected to at least some of the plurality of ports of the switch, each of the plurality of servers being addressable by the same Internet Protocol (IP) address, and each of the plurality of servers having a unique hardware address, the method comprising;

obtaining a connection request at the cluster to connect to a server associated with the IP address, wherein the connection request is for a resource;

providing the connection request to each server connected to the switch;

at least one of the plurality of servers determining which of the plurality servers is to handle the connection, wherein the determining act is based, at least in part, on a given function of information used to request the connection; and

if a first server of the plurality of servers that is determined to handle the connection does not have a copy of the requested resource, the first server providing a notification to a second server of the plurality of servers that does have a copy of the requested resource, wherein the notification indicates that the first server does not have a copy of the requested resource.

11. A method as recited in claim 10, further comprising:

determining, by the second server, whether to;

i) provide a copy of the requested resource to said server, or ii) request the server to handoff the connection to the second server so that the second server can serve the requested resource,

wherein the determining act performed by the second server is based on an attribute of the requested resource.

12. A method as recited in claim 11, wherein the attribute of the requested resource comprises at least one of a size of the requested resource and a popularity of the requested resource.

13. A method as recited in claim 10, wherein the notification is a hand-off request.

14. A method as recited in claim 10, wherein the notification is a peer-fill request.

15. A method as recited in claim 11, further comprising:

the second server providing a copy of the requested resource to the first server if at least one of;

the size of the requested resource does not exceed a size threshold, and

a popularity value associated with the requested resource exceeds a popularity threshold.

16. A method as recited in claim 15, further comprising:

upon receiving at least a portion of the requested resource from the second server, the first server serving the requested resource.

17. A method as recited in claim 11, further comprising:

the second server requesting the first server to handoff the connection to the second server if at least one of;

the size of the requested resource exceeds a size threshold, and

a popularity value associated with the requested resource does not exceed a popularity threshold.

18. A method as recited in claim 17, further comprising:

the first server handing off the connection to the second server; and

the second server serving the requested resource.

19. A method as in claim 10 wherein the given function comprises a hash function.

20. A method as in claim 10 wherein the information used by the given function comprises:

the VIP, port information, the number of servers in the cluster, the number of serving servers in the cluster, and a server number.

21. A method as in claim 10 wherein the hardware address is a Media Access Control (MAC) address and wherein the connection is a Transmission Control Protocol (TCP) connection.

22. A method for load-balancing across a plurality of servers connected to a switch, wherein each of the plurality of servers is addressable by the same Internet Protocol (IP) address, the method comprising:

receiving a connection request to connect to a server associated with the IP address, wherein the connection request is for a resource;

determining which of the plurality servers is to handle the connection;

if a first server of the plurality of servers that is determined to handle the connection does not have a copy of the requested resource, the first server providing a notification to a second server of the plurality of servers that does have a copy of the requested resource, wherein the notification indicates that the first server does not have a copy of the requested resource; and

in response to receiving the notification from the first server, determining, by the second server, whether to;

i) provide a copy of the requested resource to said server, or ii) request the server to handoff the connection to the second server so that the second server can serve the requested resource,

wherein the determining act performed by the second server is based on an attribute of the requested resource.