US20130173806A1

US20130173806A1 - Load-balancing cluster

Info

Publication number: US20130173806A1
Application number: US13/495,085
Authority: US
Inventors: Christopher Newton; Maksim Yevmenkin; David Fullagar; Jeffrey G. Koller
Original assignee: Level 3 Communications LLC
Current assignee: Level 3 Communications LLC
Priority date: 2011-12-31
Filing date: 2012-06-13
Publication date: 2013-07-04
Also published as: CA2862339A1; HK1203654A1; US20130174177A1; EP2798513B1; EP2798513A1; EP2798513A4; WO2013101844A1; US9444884B2; CA2862339C

Abstract

A load-balancing cluster includes a switch having ports; and servers connected to at least some of the ports. The servers are each addressable by the same virtual Internet Protocol (VIP) address. A first server of the plurality of servers establishing a Transmission Control Protocol (TCP) connection with a client computer, and, in response to a resource request received by the first server from the client computer for a particular resource, if the first server does not have a copy of the particular resource it queries one or more peers regarding the particular resource. Based at least in part on responses from the peers, the first server either: obtains the particular resource from a peer; or migrates the TCP connection to a peer; or serves the particular resource to the client request through a second server.

Description

RELATED APPLICATIONS

This application is related to and claims priority under 35 U.S.C. §119(e) to co-pending and co-owned U.S. patent applications No. 61/582,298, filed Dec. 31, 2011, titled “Load-Balancing Cluster,” and No. 61/582,301, filed Dec. 31, 2011, titled “Load-Aware Load-Balancing Cluster,” the entire contents of both which are fully incorporated herein by reference for all purposes.

COPYRIGHT STATEMENT

This patent document contains material subject to copyright protection. The copyright owner has no objection to the reproduction of this patent document or any related materials in the files of the United States Patent and Trademark Office, but otherwise reserves all copyrights whatsoever.

FIELD OF THE DISCLOSURE

This invention relates to content delivery.

GLOSSARY

As used herein, unless stated otherwise, the following terms or abbreviations have the following meanings:
MAC means Media Access Control;
MAC address means Media Access Control address;
IP means Internet Protocol;
TCP means Transmission Control Protocol;
“IP address” means an address used in the Internet Protocol to identify electronic devices such as servers and the like;
ARP means Address Resolution Protocol;
HTTP means Hyper Text Transfer Protocol;
URL means Uniform Resource Locator;
IGMP means Internet Group Management Protocol;
DNS means Domain Name System.

BRIEF DESCRIPTION OF THE DRAWINGS

The following description, given with respect to the attached drawings, may be better understood with reference to the non-limiting examples of the drawings, wherein:

FIG. 1 depicts a load-aware load-balancing cluster;

FIG. 2 depicts an exemplary TCP connection handoff;

FIGS. 3-4 are flowcharts of a TCP connection handoff;

FIG. 5 depicts a collection of load-balancing clusters;

FIGS. 6A-6B depict a flowchart of processing associated with server interactions;

FIG. 7 is a flowchart of processing associated with server interactions;

FIGS. 8A-8B show categorization of server load;

FIG. 9 is flowchart of processing associated with server load categorization;

FIG. 10 is an exemplary load table;

FIG. 11 is a flowchart of processing associated servers sharing load information;

FIGS. 12A-12B are flowcharts of processing associated with load-aware request processing; and

FIGS. 13-15 are flowcharts of processing associated with request processing.

THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENTS

As shown in FIG. 1, a load-balancing cluster 10 is formed by an n-port switch 12 connected to a number (between 1 and n) of servers 14-1, 14-2, . . . , 14-m, where m≦n (collectively “servers 14”) via ports 16-1, 16-2, . . . , 16-n. Not every port 16-k of the switch 12 needs to have an actual (or operating) server 14 connected thereto. The switch 12 is preferably an Ethernet switch.
Each server 14-j includes a processor (or collection of processors) constructed and adapted to provide data in response to requests. In presently preferred implementations, all servers are the same and run the same version of operating system (OS), with same kernel and software. However, those skilled in the art will realize and understand, upon reading this description, that the servers may be any server running any type of server processes. Those skilled in the art will further realize and understand, upon reading this description, that the servers need not all be the homogeneous, and heterogeneous servers are contemplated herein.
Each server 14-j in the cluster 10 is addressable by a unique hardware address—in the case of the Ethernet, a so-called a MAC address (also known sometimes as an Ethernet address). For the purposes of this description, the MAC or actual hardware address of the j-th cluster server is denoted MACj.
The servers 14 in the load-balancing cluster 10 are all assigned the same virtual IP address (VIP), e.g., “10.0.0.1”. Each server preferably also has at least one other unique (preferably local) IP address, denoted IPj for the j-th cluster server. Preferably a VIP address is also has MAC address (denoted MACVIP) associated with it, with the VIP's MAC address being shared by all the servers in a cluster. That is, in preferred embodiments, the (VIP, VIP's MAC address) pair, i.e., (VIP, MACVIP) is the same for all the servers in a cluster. However, as noted, each server also preferably has its own private (IP address, IP's MAC address) pair (e.g., (IPi, MACi)).
The servers 14 in cluster 10 are addressable externally (e.g., from network 17, e.g., the Internet) via the local (Ethernet) network 13 and switch 12. For example, using router 11, an external request from client 19 via network 17 (such as the Internet) to the IP address VIP is directed via the switch 12 to each real cluster server 14-j connected thereto. The switch 12 forwards Ethernet frames, preferably as fast and as efficiently as possible. The switch 12 may perform one-to-one (unicast) forwarding or one-to-many (broadcast or multicast) forwarding. In unicast forwarding a packet enters the switch on one port and leaves the switch on another port. In the case of broadcast or multicast forwarding packet enters the switch on one port and multiple copies of the same packet leave the switch on many ports. When broadcast forwarding (using, e.g., a so-called “unlearned” unicast MAC address), the switch sends all incoming packets to every port, whereas when multicasting mode (using a multicast MAC address), the switch sends all packets to those ports that have servers connected thereto. In either case, the desired result is that all cluster members—i.e., all servers 14 connected to the switch 12—get all packets destined for the IP address VIP.
In case of multicast MAC address, the switch 12 may use so-called “IGMP snooping” to learn which physical ports belong to live servers. In case of an “unlearned” unicast MAC address, the switch 12 forwards incoming traffic to all ports.
The system is not limited by the manner in which the switch 12 provides packets to the servers 14 connected thereto. Those skilled in the art will realize and understand, upon reading this description, that different and/or other methods of achieving this result may be used.
In a local Ethernet network, an Ethernet MAC address is used to identify a particular host machine connected to the network. In such a network, a protocol such as, e.g., ARP, may be used to translate between a host's IP address and its Ethernet MAC address. For example, a host on an IP network wishing to obtain a physical address broadcasts an ARP request onto the IP network. A host on the network that has the IP address in the request then replies with its physical hardware address.
An IP router provides a gateway between two (or more) IP networks. The purpose of an IP router is to forward IP packets from one IP network to another. An IP router should have an interface and IP address in each network to which it is connected. So, IP router 11 has at least two interfaces and two IP addresses: one IP address to connect to the upstream network (17 in FIG. 1) and the other IP address to connect to the local Ethernet network (13 in FIG. 1).
A request from client 19 is made to the IP address VIP (via network 17) and reaches the router 11. The request comes into the router 11 via the interface connected to the upstream network 17, and the router 11 forwards the request to the VIP (on the local Ethernet network 13).
Because the local network 13 is an Ethernet network and because router 11 is connected directly to the local network 13, the router 11 encapsulates the IP packet (i.e., the request) into an Ethernet packet before sending it. In order for the router 11 to know where to send the Ethernet packet, the router makes an ARP request. Once the Ethernet packet is sent, the switch 12 forwards it to the server(s) 14.
In order to affect ARP mapping, a router (e.g., router 11) typically maintains a so-called ARP table 15 (mapping IP addresses to the MAC addresses of hosts connected thereto). In this manner, when an IP packet is sent to a particular host that is connected to the router 11, the router automatically resolves to the destination host's MAC address and forwards the packet to the appropriate host. The router 11 will try to deliver the IP packet directly to destination (i.e., the VIP) because the router is connected to the same local Ethernet network.
Certain special MAC addresses (e.g., broadcast or multicast) can be used to instruct a switch to broadcast (or multicast) a packet, thereby providing a packet to all hosts connected to that switch. Specifically, e.g., an Ethernet switch sends a packet with a broadcast or multicast MAC address in its destination field to every port (or every port with a server connected thereto), whereby every host/server connected to the Ethernet switch should get a copy of the packet.
In order for two machines (e.g., client 19 and one of the servers 14) to interact, a network connection must be established between them. The client 19 has the IP address of a server (in this case VIP), and tries to establish a connection via the network 17 and the router 11.
When the router 11 gets a request to connect to a server with the IP address VIP (shared by the cluster servers 14-j), the router maps the IP address VIP to a special MAC address that causes the switch 12 to forward the request to each server connected thereto. In the case of the load-balancing cluster 10, preferably the switch 12 treats the MAC address for a VIP as a multicast Ethernet address. Consequently, each member of the cluster 12 (i.e., each server 14) sees all incoming traffic (addressed to VIP). The router's ARP table 15 thus gets a multicast Ethernet address for the VIP, and thus, at the IP layer, all incoming traffic to the VIP address is provided to all servers 14 connected to the switch 12.
In a presently preferred implementation, the switch 12 maintains a so-called “forwarding database,” (FDB 23 in FIG. 1) to map destination Ethernet MAC addresses to physical Ethernet ports 16 on switch 12. When switch 12 receives an Ethernet packet, the switch queries the forwarding database (e.g., using the destination MAC address as a key) and tries determine which physical port should be used to send the Ethernet packet out. This forwarding database 23 allows switch 12 to forward Ethernet packets only where they should go.
However, when switch 12 receives an Ethernet packet and cannot find an entry in its forwarding database for a destination Ethernet MAC address (i.e., e.g., in the case of an unknown/unlearned MAC address), the switch forwards such an Ethernet packet to all the ports (except the one it came from).
A multicast Ethernet MAC address has entry in the switch's 12 forwarding database instructing it to forward Ethernet packet to multiple ports 16.
An Ethernet switch will generally try to learn by looking at the MAC addresses of all the Ethernet packets passed through the switch and will try to update its forwarding database accordingly. However, it is preferable to ensure that the switch 12 never “learns” about MAC address for the VIP and never builds an association between VIP cluster MAC addresses and physical ports 16. The switch 12 is thereby forced to always forward Ethernet packets destined for the cluster MAC address (and thus the cluster VIP) to multiple/all ports 16.
Those skilled in the art will realize and understand, upon reading this description, that different and/or other ways of causing the switch to provide incoming data to all cluster members may be used.
Having found a cluster server with the IP address VIP, a TCP connection must be established between the client 19 and that cluster server 14. A TCP connection is established between two machines, in part, using a well-known three-way handshake (SYN, SYN/ACK, ACK). This protocol is described, e.g., in “RFC 793—Transmission Control Protocol,” September 1991, the entire contents of which are incorporated herein by reference for all purposes.
In the cluster 10, when a TCP connection is first established, each cluster member (i.e., each server 14) effectively decides which server 14 will handle a connection. In effect, each cluster member decides for itself whether or not to handle a connection. Once a particular cluster member takes (or is given) responsibility for a particular connection, the other cluster members do not handle (and need not even see) traffic related to that connection. The manner of server selection is described below.
Each cluster member (server) includes a stateful firewall (FW) mechanism that is used to filter unwanted incoming traffic. In FIG. 1, for the purposes of this discussion, the firewall mechanism for the j-th server is denoted 20-j. Upon receipt of an IP packet, the firewall first determines whether the packet is for an old (i.e., already established) connection or for a new connection. For already-established connections each firewall mechanism is configured to reject incoming traffic that does not have an entry in its firewall state table 22, and only to accept incoming traffic that does have an entry in its firewall state table. In FIG. 1, the firewall table for the j-th server is denoted 22-j. The firewall must still inspect packets associated with new connections (i.e., connections in the process of being established, specifically packets with only SYN flag set). To summarize: first the firewalls make a decision as to whether an IP packet is “new” or “old”. If the packet is “old” then it is discarded unless a state entry exists. If the packet is “new” it is passed for further inspection (e.g., load balancing) and then, depending on the results, can be either discarded or accepted.
Once it is determined (e.g., as described below) that a particular cluster member 14-j is going to handle incoming traffic on a certain connection, a corresponding entry is created in that member's firewall state table 22-j. Specifically, the cluster member/server creates a firewall state table entry for any packet that belongs to a connection initiated from or accepted by the cluster member. If a packet indicates that a remote host wishes to open a new connection (e.g., via an IP SYN packet), then such packet gets inspected by a firewall rule that determines whether or not the cluster member should accept it. If the packet was accepted by a cluster member, the firewall state table for that cluster member is updated and all subsequent packets on the connection will be accepted by the cluster member. The firewalls of the other cluster members will block packets that they are not supposed to be processing (i.e., packets that do not belong to connections they initiated or accepted).
The firewall rule preferably ensures that only one cluster member will accept a particular connection, however in some cases, it is possible that more than one cluster member decide to accept the same connection. This situation would create duplicate responses from the cluster. However, as those skilled in the art will realize and understand, upon reading this description, this is not a problem for a TCP connection because the remote host will only accept one response and discard others. In this scenario only one cluster member will be able to communicate with the remote host, other cluster members will have a stuck connection that will be closed due to timeout. In the case when no servers respond to an initial SYN packet the client will retry and will send another SYN packet after a timeout. While cluster members may have inconsistent state, they should converge and achieve consistent state quickly.
The firewall determines which cluster member should handle a particular connection using a given mapping function, preferably a hash function. By way of example, the hash function jhash, a standard hash function supplied in the Linux kernel, may be used. Those skilled in the art know how to produce a number in a particular range from the output of a hash function such as jhash. The hash function produces an integer value. To obtain a value in the range 1 to m, for some m, the output of the hash function is divided by in and the remainder is used (this operation may be performed using an integer remainder or modulo operation). For load balancing in a cluster, the value of in is the number of currently live servers in the cluster. Those skilled in the art will realize and understand, upon reading this description, that the function's output value need not be offset by one if the buckets are numbered starting at zero.
Using, e.g., jhash, the function MAP(source IP, in) may be implemented as:

- (jhash(parameters) modulo in)

If there are m alive servers in a cluster, each server 14 performs the (same) mapping function (with the same inputs). Each server or cluster member 14 is associated with a particular local server number (or agent identifier (ID)). E.g., if there are eight servers 14-0, . . . , 14-7, their corresponding agent IDs may be 0, 2, . . . , 7, respectively. Each server compares the result of the mapping function (e.g., hash modulo m) to its local server number. If the result of the mapping function is equal to the local server number, the packet is accepted, otherwise the packet is dropped.
Note that the exemplary functions shown above all operate on values related to the particular connection (e.g., source and destination address and port information). However, in a simplified case, the mapping function may be one which merely takes as input the number of active servers (MAP (m)→{1 . . . m}). An example of such a function is a round-robin function. Another example of such a function is one which uses external (possibly random) information. Note, however, that since all servers have to use the same mapping function and have to produce the same result, such a function would need to access a global space and all invocations of such a function (from each cluster server) would need to be operating on the same values.

Example I

By way of example, and without limitation, consider a cluster with 8 ports and with 7 active servers connected to those ports as shown in the following table:


Port #.	0	1	2	3	4	5	6	7

Server	S0	S1	S2	S3	S4	—	S6	S7
Bucket	0	1	2	3	4	5	6

In this case, the number of active servers, m, is 7, there are seven buckets (numbered 0 to 6), and so the mapping function should produce a number in the range 0 to 6. Suppose, for the sake of this example, that the mapping function is:

- MAP (source IP, destination IP, destination port, m)=hash (source IP, destination IP, destination port) modulo m

If a connection request comes in from IP address 123.156.189.123, for the VIP (1.0.0.1) on port 80. Each server runs the mapping function:

- hash (123.222.189.123, 1.0.0.1, 80) modulo 7

Suppose that this mapping produces a value of 4 then server S4 (which corresponds to bucket 4) handles the connection. Suppose that at some time one of the servers, e.g., S3 becomes inactive. The status of the cluster is then as follows:


Port #.	0	1	2	3	4	5	6	7

Server	S0	S1	S3	—	S4	—	S5	S6
Bucket	0	1	2	—	4		4	5

Notice that the association between servers and buckets has changed, so that server S4 is now associated with bucket 3, and server S5 is associated with bucket 4. Now, as there are only five “alive” severs, the mapping function must produce a value in the range 0 to 5. If a new connection comes in, and if the mapping function produces a value 4, then server S6 (not S5) will handle this connection.
If a new server S7 is connected to port 5, the number of servers becomes 7 and the status of the cluster would be:


Port #.	0	1	2	3	4	5	6	7

Server	S0	S1	S2	—	S4	S7	S5	S6
Bucket	0	1	2		3	4	5	6

End of Example I

Those skilled in the art will realize and understand, upon reading this description, that the buckets may be renumbered or reordered in different ways when a server is added to or removed from the cluster. For example, it may be desirable to give the new server the bucket number 5 and to leave the other servers as they were. It should be noted that existing connections are not affected by server/bucket renumbering because load balancing is only performed on new connections. Existing (i.e., old) connections handled entirely in the firewall.
Heartbeat
Each cluster member 14 includes a so-called heartbeat processes/mechanism 18. Each heartbeat mechanism 18 (on each cluster member 14) is a process (or collection of processes) that performs at least the following tasks:

- monitors server configurations on the cluster;
- answers ARP queries for the configured VIPs;
- monitors local state and state of other cluster members; and
- controls local load balancing firewall configuration.

The heartbeat monitors the state of VIPs on servers. Each server may have more than one VIP configured, and the heartbeat keeps track of each VIP's state separately.
While described herein as a single mechanism, those skilled in the art will realize and understand, upon reading this description, that the various functions of the heartbeat mechanism can each be considered a separate function or mechanism.
The Heartbeat Mechanism Monitors Server Configuration on The Cluster
The heartbeat mechanism 18 on each cluster member/server 14 determines its own state as well as that of each VIP on other cluster members. (In order to simplify the drawing, not all of the connections between the various heartbeat mechanisms are shown in FIG. 1.)
On each cluster member/server, heartbeat mechanism 18 maintains information about other VIPs in the cluster 10 (preferably all other VIPs). To this end, the heartbeat mechanism 18 builds and maintains a list of VIPs connected to the switch 12, and then, for each of those VIPs, maintains (and routinely updates) information. The heartbeat mechanism 18 on each server 14 first builds a list of network interfaces in the system and obtains information about IP addresses on these interfaces. The heartbeat mechanism 18 may, e.g., use, as its main input, a table containing information about the local cluster and VIPs. In general, an external process may provide VIP configuration on the local cluster to the heartbeat process, e.g., in a form of table. Those skilled in the art will know and understand, upon reading this description how such a process and table may be defined and configured.
The heartbeat mechanism 18 considers each VIP in the cluster 10 to be in one of three states, namely “configured”, “connecting” and “connectable”. In order to maintain these states, the heartbeat mechanism 18 obtains a list of VIPs that should be configured on the cluster 10. Each VIP from the list is preferably cross-checked against list of IP addresses on all interfaces. If a match is found, the VIP is marked as “configured”. (A VIP is in the “configured” state—when the VIP is configured on one of the local (to host) interfaces). For every VIP marked as “configured”, the heartbeat mechanism 18 tries to initiate a TCP connection on a specified port, e.g., either 80 or 443. As soon as connection to a VIP is initiated, the VIP is marked as “connecting”. If connection to a VIP is successful, the VIP is marked as “connectable”. A VIP's state is “connecting” when a TCP health check is currently in-progress; a VIP's state is “connectable” when the most recent TCP health check succeeded.
The heartbeat mechanism 18 continuously performs the actions described above, preferably at fixed, prescribed time intervals.
If a VIP changes it's state or completely disappears from the list of IP addresses, a state transition in noted. Servers are automatically configured (or removed) on (from) loopback clone interfaces as needed. In a presently preferred implementation, the heartbeat mechanism takes over the first 100 (1o:0-1o:99) loopback clone interfaces. If needed, manual loopback interfaces can be configured starting from 1o:100 and up.
The Heartbeat Mechanism Answers ARP Queries for the Configured VIPs
Each active heartbeat mechanism 18 continuously listens for ARP requests. Upon receipt of an ARP request, the heartbeat mechanism examines request to see if it relates to a VIP that should be configured on the cluster. If the ARP request does relate to a VIP, the heartbeat mechanism checks if the VIP is in “configured” state and if so, the heartbeat mechanism replies with an ARP reply for that VIP.
Although multiple heartbeat mechanisms may reply to the same ARP request, this is not a problem, since they will each return the same MAC address (MACVIP).
The Heartbeat Mechanism Monitors Local State and State of Other Cluster Members
The heartbeat mechanism 18 preferably tries to maintain full state information for all servers 14 in the cluster 10. State per cluster preferably includes one or more of: (a) number of cluster members that should serve traffic for the cluster, (b) number of cluster members that are serving traffic for the cluster; and (c) timestamp information. Those skilled in the art will realize and understand, upon reading this description, that different and/or other state information may be maintained for the cluster and for cluster members.
Each heartbeat mechanism preferably announces its full state to other cluster members at a prescribed time interval. State updates are preferably sent to a multicast UDP address which is shared by all cluster members. (Note: this UDP multicast is not the same as the VIP multicast discussed above.) The heartbeat mechanism can also be configured to send multiple unicast UDP messages to each member of the cluster when performing state announcing.
Each heartbeat mechanism updates its state upon receiving state update from other cluster members if the following conditions are met: the server is present on the receiving cluster member and the received state is “newer” (per timestamp) than the current state on receiving cluster member. Since a timestamp is used, preferably clocks on all cluster members are synchronized.
At prescribed time intervals a heartbeat mechanism 18 analyzes its state and checks for state transitions. The heartbeat mechanism checks each server's state and makes sure that it is fresh. So-called “non-fresh” servers are automatically considered as “down”. Each server's state is compared to its previous state, and, if different, a state transition is noted.
Changes to VIP state are made as they detected, based on the current heartbeat's view of the cluster.
Inter-Cluster Handoff
As described thus far, server selection has been made within a cluster by the cluster members at the TCP level. The system does not require a load balancing switch, thereby reducing the cost. Instead, as described, the system duplicates incoming (client-to-cluster) traffic to all servers in the cluster and lets each server decide if it is to deal with particular part of the incoming traffic. All servers in the cluster communicate with each other and decide on an individual server's health.
Another level of server selection—within a cluster—is also provided, as a result of which an initially-selected server (selected as described above) may pass on (or attempt to pass on) responsibility for a particular connection to another cluster member. For example, if one server in a cluster has already handled a particular request for a certain resource, that server may have that resource cached. The server with the already-cached copy of the resource may then be a better choice than another server in the cluster to process a request.
Accordingly, in some cases, after receiving a request from a client for a certain resource (after a server has been selected and the TCP connection has been established, as described above), the server may ascertain whether it is responsible for handling/serving the resource, and, if not, the previously-selected server may notify (or provide a notification) to another cluster member that is responsible for handling the resource (e.g., another cluster member that already has a copy of the requested resource). The notification may include a hand-off request to so that another cluster member responsible for the resource can server the resource itself. Or, alternatively, the notification may include a request for a copy of the resource (e.g., via a peer-fill request) from another cluster member responsible for the resource (i.e., that already has a copy of the requested resource).
The cluster member responsible for (handling) the requested resource may process the notification from the previously or originally selected server in a number of ways. For instance, a cluster member that has previously served the requested resource (or that is “responsible” for handling the request, or already has a copy of the requested resource) may determine whether to accept or reject a hand-off request (or a peer-fill request) from the previously or originally selected server. For example, the other cluster member may decide to accept or reject the hand-off request (or peer-fill request) based on various attributes of the requested resource such as, but not limited to, the size and popularity of the requested resource.
In one embodiment, the responsible server accepts a hand-off request (or rejects a peer-fill request) if the size of the request resource exceeds a threshold value. This step is advantageous because copying a large resource to the previously selected server is inefficient and would not be a worthwhile expenditure of system and network resources. If, on the other hand, the size of the requested resource is small (i.e., does not exceed a size threshold), then it may be worthwhile to reject the hand-off request (or accept the peer-fill request) and provide a copy of the requested resource to the previously selected sever so that the previously selected server can handle the request.
According to another example embodiment, if it determined that the requested resource is popular (i.e., exceeds a popularity threshold), then the responsible server may reject the hand-off request (or accept/honor the peer-fill request) and (indirectly) force the previously selected server to obtain and serve the requested resource (or simply provide a copy of the requested resource to the previously selected server). Since the resource is popular and, thus, likely to continue to be requested frequently, it would be beneficial for other servers (i.e., the previously selected server) to have a copy of the requested resource so that the requested “popular” resource can be served more efficiently. For example, in addition to sending a hand-off rejection message, the responsible server may also provide a copy of the requested resource to the previously selected server (or the previously selected server may also obtain a copy of the requested resource from other sources, such as other peers, upstream servers, etc.).
As used herein, a “resource” may be any kind of resource, including, without limitation static and dynamic: video content, audio content, text, image content, web pages, Hypertext Markup Language (HTML) files, XML files, files in a markup language, documents, hypertext documents, data files, and embedded resources.
Once a TCP/IP connection is made between two machines (e.g., client 19 and a particular cluster member, server 14-k (for some value of k)), the server 14-k may receive a request from the client 19, e.g., for a resource. For example, the server 14-k may receive an HTTP request (e.g., an HTTP GET request) from client 19. Such a request generally includes a URL along with various HTTP headers (e.g., a host header, etc.). The selected server 14-k now determines whether it is responsible to handle this request or whether the request should be passed on to a different cluster member. To make this determination, the selected server 14-k considers the request itself and applies a second given function to at least some of the information used to make the request (e.g., to the URL and/or headers in the request).
This second function essentially partitions the request space (e.g., the URL space) so as to determine whether the selected server is, in fact, responsible to for this particular request. If the server determines that it is responsible for the request, it continues processing the request. If not, the server hands-off the request (as described below) on to another cluster member (e.g., server 14-p) that is responsible for the request. Having successfully passed off the request, the cluster member, server 14-k, updates its firewall to reject packets associated with the connection. The responsible cluster member (server 14-p) correspondingly updates its firewall to accept packets associated with this connection.
For the sake of this discussion, the function used to partition the requests is referred to as a partition function. The partition function may be a hash function or the like. In some cases the partition function may take into account the nature or type of request or resource requested. For example, certain cluster members may be allocated to certain types of requests (e.g., movies, software applications, etc.). The partition function applied to the URL (and/or other information) can be used to implement a degree of policy based load mapping.
Exemplary partition functions are:

- Partition (URL, m)→{1 . . . m}
- Partition (URL, host header, in)→{1 . . . m}
- Partition (URL, HTTP headers, in)→{1 . . . m}
- where Partition (params, m) is implemented as, e.g.,
- hash(params) modulo m
- where m is the number of active servers in the cluster.

Those skilled in the art will realize and understand, upon reading this description, that different and or other parameters may be used in the Partition function. Further, not all parts of a parameter need be used. For example, if the URL is a parameter, the function may choose to use only a part of the URL (e.g., the hostname).
Since accounting and other information may be included in HTTP headers and/or URLs, such information may be used by the partition function. For example, a cluster may comprise a number of non-homogenous servers. Certain requests may be directed to certain cluster servers based on server capability (e.g., speed) or based on arrangements with customers.
In order to hand off a request to another server within its cluster, a server must be able to completely move an individual established TCP connection from one server to another in the same cluster. The following scenario, with references to FIGS. 2-4, describes this operation of the system. As shown in the FIG. 2, the cluster includes two servers: server A and server B. Each of the servers runs a web cache, listening on a shared VIP (and port, e.g., port 80). Remote clients make incoming TCP connections to the VIP and port (as described above).
Using the TCP-level load balancing described above, assume that server A is initially selected to accept a particular TCP connection from a client (at S30 in FIG. 3). Server A accepts the connection from the client and waits for the HTTP request from the client. Using information from the HTTP request (e.g., the URL and one or more HTTP headers) server A decides to hand the request off to the server B. That is, the selected server (server A in this example) ascertains (using the partition function described above) whether it is the server responsible for the request (at S31). If the originally-selected server is responsible for the request (at S32), then it handles the request (at S33), otherwise it hands off (or tries to hand off) the request to the responsible cluster member (server B in this example) (at S34). If the handoff is determined to be successful (at S35), then the server responsible for the request (Server B in the example) handles the request (at S36), otherwise the originally selected server (Server A) handles the request (at S37).
The hand-off process (S34) takes place as follows (with reference to FIG. 4) (for the purposes of this discussion, assume that server A hands off to server B):
First the originally-selected server (Server A) freezes the TCP connection from the client (at S40). The selected server (Server A) then takes a snapshot of the frozen TCP connection (at S41), storing required information about the connection. The originally-selected server (Server A) then sends the snapshot of the frozen TCP connection to the responsible server (server B), preferably using a side communication channel to the responsible server (at S42).
The responsible server (Server B) receives the snapshot of the frozen TCP connection from the originally-selected server (Server A) (at S43). Using the snapshot of the frozen TCP connection, the responsible server (Server B) attempts to clone the TCP connection to the remote client (at S44). If the connection was cloned successfully, the responsible server (server B) sends acknowledgement to the originally-selected server (Server A), preferably using the side communication channel to the server A (at S45).
Upon receipt of the acknowledgement, the originally-selected server (Server A) closes the frozen TCP connection to the client (at S46).
The responsible server (Server B) then thaws the frozen (clone) TCP connection to the client (at S47).
With the handoff successful, the responsible server (Server B) continues to process incoming HTTP request from the client (at 52 in FIG. 4).
The accepting server may fail to clone connection or may refuse to satisfy handoff request. In these cases a negative acknowledgment will be sent and originating (handoff) server will continue to process original request. Should the responsible server (Server B) decline (or fail to satisfy) the handoff request from the originally-selected server (Server A), server A may thaw the TCP connection and continue to serve it locally.
A responsible server generally should not decline a handoff request or a request to take over a connection. However, a responsible server may have to decline a request, for example if its software is being shutdown. Note, too that two or more servers in the same cluster may be responsible for the same content, and may provide a degree of redundancy in content (to reduce fills from the origin server) and also to handle a so-called “flash crowd” when a certain piece of content becomes very popular for a relatively short period time.
When a handoff is successful, the responsible server must update its firewall to accept packets relating to that connection (and the server that handed off the connection must update its firewall to no longer accept such packets).
It should be apparent that only the server that is actually handling the connection will invoke the partition function. The other servers do not generally have the information required (e.g., the URL) to make the required decision.
The server making the handoff may provide the responsible server with information about the request (e.g., the type of request, the URL, the headers, etc.). In this way the responsible server may have sufficient information to satisfy the request.

Example II


Port #.	0	1	2	3	4	5	6	7

Server	S0	S1	S2	S3	S4	—	S5	S6
Bucket	0	1	2	3	4		5	6

- MAP (source IP, destination IP, destination port, m)=hash (source IP, destination IP, destination port) modulo in

If a connection request comes in from IP address 123.156.189.123, for the VIP (1.0.0.1) on port 80. Each server runs the mapping function

- hash (123.156.189.123, 1.0.0.1, 80) modulo 7

Suppose that this mapping produces a value of 4 then server S4 (which corresponds to bucket 4) is selected at the TCP level to handle the connection. Server S4 and the client then establish their connection and the client then sends an HTTP request (e.g., a GET request with a URL (URL1) and header information).
Server S4 invokes the partition function:

- Partition (URL1, host header, 7)

Note that the partition function can use the same bucket association as the mapping function or it may use a different association. For example, if the partition function is implementing policy-based or capacity based distribution, then the partition function may need a separate bucket association. For this example, assume that the partition function uses the same bucket association as the mapping function.
Suppose that this invocation of the partition function returns a value of 6. This means that server S6 (associated with bucket no. 6) should handle this connection instead of the initially-selected server S4. So server S4 tries to hand off the connection to server S6.
Server S4 freezes the TCP connection from the client (at S40 in FIG. 4) and then takes a snapshot of the frozen TCP connection, storing required information about the connection (at S41). Server S4 sends the snapshot of the frozen TCP connection to Server S6, preferably using a side communication channel (at S42). Server S6 receives the snapshot of the frozen TCP connection from Server S4 (at S43). Using the snapshot of the frozen TCP connection, Server S6 attempts to clone the TCP connection to the remote client (at S44). If the connection is successfully cloned, then server S6 sends an acknowledgement to Server S4, preferably using the side communication channel (at S45). Upon receipt of the acknowledgement, Server S4 closes the frozen TCP connection to the client (at S46). Server S6 then thaws the frozen (clone) TCP connection to the client (at S47). With the handoff successful, Server S6 continues to process incoming HTTP request from the client.
Suppose now that another connection request comes in, this time from IP address 123.156.111.123, for the VIP (1.0.0.1) on port 80. Each server runs the mapping function:

- hash (123.156.111.123, 1.0.0.1, 80) modulo 7

Suppose that the result of this function is 6 which corresponds to server S6. S6 connects with the client and the client then sends an HTTP GET request with a URL (URL1—the same as in the earlier request) and header information.
Server S6 invokes the partition function:

- Partition (URL1, host header, 7)

Again the partition function returns the value 6. However, in this case the server responsible for the request is the one already handling the request, and so no handoff is needed (i.e., the check at S32 will return “YES”). Note that since server S6 has already served the resource associated with URL1, it may still have that resource cached.

End of Example II

Note that the number of servers connected to the switch could be greater than the number of servers responsible for the VIP. For example, a cluster may be configured with 20 servers connected to the same switch, 10 servers serving one VIP and another 10 servers serving another VIP. In this case the heartbeat assists in load balancing for two VIPs, and each VIP will be load balanced across 10 servers.
As shown in FIG. 5, a collection 100 of load-balancing clusters 10-1, 10-2, . . . , 10-p, may be combined. Each cluster 10-j has one or more corresponding VIPs (VIP-j), so that requests for a server at the IP address VIP-k (for some value of k) will be directed (by router 110) to the appropriate cluster for handling by one of the cluster members. The router 110 may be, e.g., a load balancing router. It should be appreciated that the collection 100 of clusters may form part of a content delivery network (CDN).
A client 19 may request a resource and be directed by a server selector system (e.g., DNS or the like) to a cluster. The server selector returns an IP address that happens to be a VIP address. The client then requests the resource from the VIP and, as described above, is connected (during a TCP connection) to a particular cluster member to handle the request.
If the cluster implements the partitioning function, then the connection may be handed off to another cluster member.
FIGS. 6A and 6B are a flowchart (600-1 and 600-2) of processing steps associated with server interactions.
In step 605, the cluster (i.e., via a switch) obtains a connection request to connect to a server associated with the virtual IP address (i.e., any server sitting behind the switch associated with a virtual IP address).
In step 610, the cluster (i.e., via the switch) provides the connection request to each server connected to the switch.
In step 615, at least one of the plurality of servers connected to the switch determines which of the plurality of servers should handle the connection. Such a determination can be based, for example, on a given function of information used to request the connection.
In step 620, if the server that is determined to handle the request does not have a copy of the requested resource, that server then requests to hand-off the connection (i.e., TCP connection) to at least one other of the plurality of servers that does have a copy of the requested resource. Note that the server may request a copy of the requested resource (e.g., via a peer-fill request) from another server that has a copy of the resource instead of sending a hand-off request.
In step 625, the server that has a copy of the requested resource determines whether to accept or reject the hand-off request (or reject or accept the peer-fill request) from the server that was originally determined to handle the connection/request. This determination can be based, for example, on the size of the requested resource, the popularity of the requested resource, as well as other attributes that are suitable for determining whether or not a TCP hand-off should occur in a server cluster in response to a request for certain resources.
In step 630, the server that has the copy of the requested resource accepts the hand-off request (or rejects the peer-fill request) if the size of the requested resource value exceeds a threshold value. In this example embodiment, if the size of the requested resource is determined to be too large (i.e., exceeds a threshold value) for expending precious system and network resource (i.e., by providing intra-cluster copies of resources, for example, one server sending a copy of a resource to another server in the cluster), then the server with the requested resource will handle the request itself (i.e., serve the requested resources, and, for example, not honor the peer-fill request).
In step 635, the server that has the copy of the requested resource accepts the hand-off request (or rejects the peer-fill request) if the popularity of the requested resource does not exceed a popularity threshold value. In other words, if it determined that the requested content is not popular (i.e., the number of times the particular resource has been requested during a retrospective time period does not exceed a threshold value), then the server with the copy of the request resource handles the connection and serves the resource (and, for example, does not honor the peer-fill request). Since the resource is not yet deemed popular, it is likely that the resource will not be requested as often and therefore is would not be efficient to transfer copies of the resource to other servers in the cluster.
In step 640, the server that has the copy of the requested resource rejects the hand-off request (or accepts/honors the peer-fill request if a copy of the resource is available) if the popularity of the requested resource exceeds the popularity threshold value. In this example circumstance, since it is determined that the requested content is popular, then it further behooves the cluster to have copies of the requested resource on other servers in the cluster to handle the possibility of more requests for the popular resource. Thus, instead of accepting the hand-off request, the server with the copy of the requested resource rejects the request, which, in one embodiment, forces the requesting server to obtain and serve the requested resource itself (and, thus, maintain a copy of the popular resource, for example, by honoring the peer-fill request and thus providing a copy of the requested resource).
In step 645, the server that has the copy of the requested resource rejects the hand-off request (or accepts/honors the peer-fill request if a copy of the resource is available) if the popularity of the requested resource exceeds the popularity threshold value and the size of the requested resource exceeds the threshold size value. This particular step elucidates the significance of popular content. Even if the size of the requested resource is deemed to large to send an intra-cluster copy from one server to another server within the same cluster (i.e., in light of the expenditure to system and network resources within the cluster), the popularity of the content may still make it more efficient in the long run to distribute a copy (or copies) of the requested resource throughout the cluster in anticipation of more requests for the popular content at the cluster. For example, one way to distribute copies of the requested resource is to reject the hand-off request and (either directly or indirectly) force the originally-selected server to handle the connection and ultimately serve the requested resource.
FIG. 7 is a flowchart 700 of processing steps associated with server interactions.
In step 705, a connection request to connect to a server associated with the IP address is received (e.g., at a cluster comprising a switch and plurality of server connected thereto via one or more ports of the switch).
In step 710, a determination is made as to which of the plurality servers is to handle the connection (e.g., via a hash function).
In step 720, if a first server of the plurality of servers is determined to be the server to handle the connection (e.g., via the hash function), and the first server does not have a copy of the requested resource, the first server provides a notification to a second server of the plurality of servers that does have a copy of the requested resource. In one example embodiment, the notification indicates that the first server does not have a copy of the requested resource. Alternatively, the notification can include a hand-off request to hand-off the connection to another server (e.g., the second server in this step), and/or a peer-fill request that requests a copy of the requested resource from another server (e.g., the second server in this step).
In step 725, in response to receiving the notification from the first server, the second sever determines whether to: i) provide a copy of the requested resource to said server (e.g., reject a hand-off request or accept a peer-fill request if a copy of the requested resource is available), or ii) request the server to handoff the connection to the second server so that the second server can serve the requested resource (e.g., accept a hand-off request or reject a peer-fill request). For example, in one embodiment this determining may be based on an attribute of the requested resource (e.g., size, popularity, etc.).
Load-Aware Load Balancing
In some embodiments each server in a cluster measures its own load and maintains information about the load of the other servers in the same cluster. For example, as shown in FIG. 1, each server 14-j in the cluster 10 includes a load mechanism denoted 24-j for the j-th cluster server. The load mechanism is constructed and adapted to measure the load on the cluster server using known load measurement techniques. In preferred embodiments the load mechanism on each particular cluster server converts or maps the load on that cluster server into one of a relatively small number of bands. These bands may be based on predetermined threshold values. For example, in one preferred implementation the load on a cluster server is mapped into one of three (3) bands or categories, corresponding to light load, medium load, and heavy load. For the sake of this description the three bands are referred to as Green (for lightly loaded servers), Yellow (for servers with medium load), and Red (for servers with a heavy load).
In order to categorize a server's load into k categories or bands (Band 1, Band 2 . . . Band k), k−1 threshold values are needed (denoted T₁, T₂. . . , T_k-1). If the measured load is less than the first (lowest) threshold value T₁, then the server's load is categorized as category 1 (i.e., for the purposes of load, that server is considered to be in Band 1). If the measured load on a server is between T_iand T_i+1, then the server's load is categorized as category on band T_i, and otherwise, if the server's load is greater than T_k-1then that server's load is categorized as being in band k. FIG. 8A shows K bands with k−1 thresholds. In the case of three bands (e.g., denoted “Green”, “Yellow”, “Red”), as shown in FIG. 8B, two threshold values (T₁and T₂) are needed in order to map or convert an load reading to a band. If the measured load on a server is less than T₁then that server's load is considered to be Green; if the measured load on a server is equal to or greater than T₁but less than T₂then that server's load is considered to be Yellow; otherwise, if the measured load on a server is equal to or greater than T₂then that server's load is considered to be Red.
FIG. 9 is a flowchart showing an exemplary categorization of a server's load into bands. For the flowchart in FIG. 9, the measured load on a server is denoted L, there are k bands denoted Band 1, Band 2 . . . Band k, and there are k−1 threshold values (denoted T₁, T₂. . . , T_k-1). The measured load (L) is compared to the thresholds (at 902). If the measured load L is less than the first threshold value T₁then the category is set to Band 1 (at 904). If the load L is between T_jand T_j+1for j=2 to k, then the category is set to Band j (at 906), otherwise the load is greater than T_k-1and the category is set to Band k (at 908).
It should be appreciated that because the servers in a cluster are sharing load information in the form of bands or categories (as described further below), each server in a cluster should use the same categories (e.g., Band 1, Band 2 . . . Band k or “Green”, “Yellow”, “Red”). However, those of skill in the art will realize and understand, upon reading this description, that it is not necessary for each server to use the same actual measure of load in order to determine which category or band it is in. This allows servers to self-categorize their load. Preferably all cluster servers in a cluster use the same concept of load.
The load categorization thresholds (T₁, T₂. . . , T_k-1) are preferably set in advance when the system is configured. However, it should be appreciated that the thresholds may be changed dynamically during operation of the system.
Those of skill in the art will realize and understand, upon reading this description, that different and/or other categorizations and names of the loads may be used. Those of skill in the art will realize and understand, upon reading this description, that the “load” on a cluster server may be measured in a number of different ways, taking into account a number of different factors.
Each cluster server 14-j in the cluster 10 also includes a load table (denoted 26-j for the j-th cluster server) in which the server stores its own load and the loads of the other servers in the cluster 10. Each server may provide its load to each other server in the cluster, using, e.g., the heartbeat mechanism. An exemplary load table 26-j is shown in FIG. 10. Each server may provide its load as a measured value or as a value mapped to a band or category. Preferably servers map their own loads to categories, since the load categories can be represented by fewer bits, and therefore fewer bits are required to provide the load information to the other servers. For example, only two (2) bits are needed when server load is categorized into three bands (“Green”, “Yellow”, “Red”).
The following table is an example of a load table for a cluster with eight (8) servers, where the load on each server is one of “Green”, “Yellow”, “Red”.


S1	S2	S3	S4	S5	S6	S7	S8

Green	Yellow	Red	Red	Green	Green	Yellow	Yellow

In this example the servers S1, S5, and S6 have load “Green,” servers S2, S7, and S8 have load “Yellow,” and servers S3 and S4 have load “Red.”
FIG. 11 is a flowchart of process(s) performed by each server in a cluster to determine its own load and to maintain its load table. The server determines its load (by some measure of load) (at 1102), categorizes its load (at 1104), and updates its load table with its current load category (at 1106). The server then provides its load category to the other servers in the cluster (at 1108), e.g., using the heartbeat mechanism 18. The server may also obtain load categories from other servers in the cluster and update its load table if necessary (at 1110). These processes are repeated while the system is in operation.
While the processes are shown in the flowchart in FIG. 11 as sequential, it should be appreciated that not all process steps need to be performed each time. For example, load determination (1102), categorization (1104), and table update (1106) may be performed at certain intervals, whereas the provision of load category information to the other servers (1108) may occur on each heartbeat.
Server Selection Using Load Information
The cluster servers may use their own load information and load information about other servers in the cluster in order to determine which cluster server is to handle a request (i.e., which cluster member is going to handle incoming traffic on a certain connection). As previously described, the cluster servers may make an initial determination of which cluster server is to handle a connection request, e.g., using values associated with the request.
For example, as described above, when the router 11 gets a request to connect to a server with the IP address VIP (shared by the cluster servers 14-j), the router maps the IP address VIP to a special MAC address that causes the switch 12 to forward the request to each server connected thereto, so that each member of the cluster 12 (i.e., each server 14) sees all incoming traffic (addressed to VIP). In the cluster 10, when a TCP connection is first established, each cluster member (i.e., each server 14) effectively decides for itself whether or not to handle a connection. As described above, a stateful firewall may use a mapping function (e.g., a hash function such as jhash) to select which cluster server is to handle a connection.
The system using the load information operates in a similar manner, except that heavily loaded servers may be omitted from the selection process (or may decline connections for which they are initially determined to be responsible). For example, consider the system described above with eight (8) cluster servers having their loads categorized as follows:


S1	S2	S3	S4	S5	S6	S7	S8

Green	Yellow	Red	Red	Green	Green	Yellow	Yellow

In this example, it may be preferable to have “Green” or even “Yellow” servers take on new requests instead of “Red” servers. One way to achieve this is to make an initial determination as before, and then to have the selected server decide whether to accept the connection request or pass it on to a server with a lighter load. For example, as shown in the flowchart of FIG. 12A, each (live) server will determine whether it is responsible for a connection request (e.g., using a hash function) (at 1202). Preferably the selection function will always select only one server. The particular server that is responsible for the connection then determines whether its load is too high to accept the connection (at 1204). This determination may be made using information in the load table on the server. For example, a server may consider its load to be too high if its load is in the “Red” band. In the example above, using this policy, the servers S3 and S4 may consider their loads to be too high. If the selected server does not consider its load to be too high to accept the connection, the server accepts responsibility and makes the connection (at 1206). It should be appreciated that this server may subsequently hand off the connection to another server after an actual connection is established, e.g., based on other policy considerations. For example, as described above, the initial server may make a connection handoff to another server based on the actual request being made.
If the selected server considers its load to be too high to accept the connection (at 1204), the server may try to find another server (within the cluster) to handle the connection. The server may use its load table to determine if there is another server in the cluster with a load that is lighter that its load (at 1208). For the purposes of this comparison, a server will treat all servers in the same load category as having the same load. If there are k load categories, with category 1 being the lightest loaded and category k being the heaviest loaded, the server may try to find a server in the lightest load category, then in the next lightest category, and so on, until it reaches its own category. For example, in the case of the three load categories “Green”, “Yellow”, “Red,” a “Red” server will first try to find a “Green” server to handle the request, and, failing that will try to find a “Yellow” server to handle the request. In the example above, if server S4 was initially selected as the server to handle the connection, that server would select one of the “Green” servers (S1, S5, S6) to take on the request.
If no server can be found with a lighter load (at 1208), then the initially-selected server takes responsibility for the connection (at 1206), otherwise it passes responsibility to a server with a lighter load (at 1210). Note that the lighter loaded server may decline to take the connection.
Those of skill in the art will realize and understand, upon reading this description, that different and/or other load-based server selection schemes may be used. For example, the system may implement a policy in which only servers in the heaviest loaded category (e.g., Red servers) may switch load, and then only to a server in the lightest loaded category on that cluster. In this policy, a Red server may switch to a Green server, and may only switch to a Yellow server if there are no Green servers. In another example, a cluster may try to maintain a certain ratio of Green (or Yellow) servers relative to the total number of (live) servers.
Another way to use the load information in initial server selection is to use the load information to essentially reduce the set of candidate machines For example, all machines categorized as having the heaviest load (e.g., Red) can be removed from the selection by being treated as inactive. Those servers become active again when their load drops to a lower category.
An alternative approach reduces the set of candidate machines for initial server selection based on a configured threshold, based, e.g., on a percentage of the size of the cluster. For example, the threshold may be set to X, where X represents a percentage of the number of live servers connected to ports of the switch and having the same VIP. By way of example, in the case of the three load categories “Green”, “Yellow”, “Red,” if there are sufficient machines in the Green load band (based on the threshold), then the selection algorithm proceeds using only the Green machines, with all other machines being considered offline (for selection purposes). If there are not enough Green machines (i.e., the number of Green machines is less than the threshold), then the machines with their loads in the next band (Yellow) are considered candidates (i.e., are treated as if online), such that the total of all of the machines in those bands is larger than the configured threshold. All machines make the same determination, however non-candidate machines cannot be selected or select themselves.
Its should be appreciated that the threshold used to select candidate machines for initial server selection is not the same as the thresholds discussed above that are used to mark the load category or band boundaries. The value X used for the threshold may be, for example, 5%, 10%, 15%, 20%, 30%, 40%, 50%, and so on. Those of skill in the art will realize and understand, upon reading this description, that other values of X may be used.
FIG. 12B is a flowchart showing selection of the set of candidate machines for initial server selection. In this example, there are three load categories denoted “Green”, “Yellow”, and “Red”, with the number of servers in the Green load category being denoted #G, the number of servers in the Yellow load category being denoted #Y, and the number of servers in the Red load category being denoted #R. For the sake of this example, suppose that the value X used to set the threshold is 40% and that there are eight live servers connected to the switch and having the same VIP. In this case then the threshold value T is 40% of eight which is rounded to 3. The candidate selection algorithm is:

- Candidates=
  - if #G>=T then Green servers
  - else if #G+#Y>=T then Green and Yellow servers
  - else Green and Yellow and Red servers

With reference to the flowchart in FIG. 12B, if the number of Green servers (#G) is greater than or equal to the threshold (T) (at 1212), then the candidate servers is set to the Green servers (at 1214). Otherwise, if the number of Green servers (#G) and the number of Yellow servers (#Y) is greater than or equal to the threshold (T) (at 1216), then the candidate servers is set to the Green and Yellow servers (at 1218). Otherwise the candidate servers are set to be the Green, Yellow, and Red servers (at 1220).
In this case, e.g., being a “red” server (i.e., a server whose load is categorized as “red”) may still be a candidate for server selection if there are too few green and yellow machines (based on the threshold).
Those of skill in the art will realize and understand, upon reading this description, how to extend this candidate selection algorithm to more than three load categories/bands. In the general case, with M bands, the candidates for selection (i.e., the machines considered online) are the machines of the lowest loaded N bands such that the total number of machines in those bands is larger than a configured threshold. The remaining machines, not in the candidates, are considered offline for the purposes of initial server selection.
It should be appreciated that the candidate servers may also be used for subsequent decisions (i.e., after the initial selection) regarding server selection and handoff.
It should be further appreciated that the above approach will work even if the load data are not identical on all servers. Suppose, e.g., that based on locally stored load information, some servers have server S as a candidate and others have S excluded (based on their information about S′s load). The servers that exclude S will select S′ as the server. If the other servers select S, then the first of the server S′ and S to make the connection with the client will handle the request.
Proxy Serving
With reference to FIG. 13, once a initial server is selected (at 1302) to handle a connection request from a client (whether or not using load information), that initial server then establishes a TCP connection with the client (at 1304), as described above. As described, after the initial TCP connection is established between the client and the initial server, the initial server will then obtain an actual request (e.g., an HTTP request) from the client (at 1306). Based on that request, the initial server may determine that a different server should preferably handle the request (at 1306), and so the initial server may attempt to handoff the connection to another cluster server (as described above) (at 1308). If the initial server determines that it should not try to handoff the request to another server (at 1308), then the initial server handles the request (at 1310). If the initial server determines that it should try to handoff the request to another server (at 1308), then the other cluster server may accept or reject the handoff request (at 1312). If the other cluster server rejects the handoff (at 1312), then the initial server handles the request (at 1310). If the other cluster server accepts the connection handoff, then that other server handles the request (at 1314). The selection of the initial server (at 1302) may use the load-aware selection described above or some other technique.
In some cases, however, the other cluster server may serve the client via the initial server, essentially using the initial server as a proxy. In these cases there is no handoff of the TCP/IP connection. The decision as to whether or not to accept a handoff or use the initial server as a proxy may be made by the other server based, e.g., on its load, on the popularity of the requested resource, and/or on other factors.
FIG. 14 is an exemplary flowchart of a system in which the initial server acts as a proxy for another cluster server. As in the case with the system described with respect to FIG. 13, once a initial server is selected (at 1402) to handle a connection request from a client, that initial server then establishes a TCP connection with the client (at 1404). After the initial TCP connection is established between the client and the initial server, the initial server obtains an actual request (e.g., an HTTP request) from the client (at 1406). Based on that request, the initial server may determine that a different server should preferably handle the request (at 1406), and so the initial server may attempt to handoff the connection to another cluster server (at 1408). If the initial server determines that it should not try to handoff the request to another server (at 1408), then the initial server handles the request itself (at 1410).
If the initial server determines that it should try to handoff the request to another server (at 1408), then the other cluster server (the “2nd Server” in the flowchart) may accept or reject the handoff request (at 1412). However, in this case, in addition to an outright rejection of the request, the other server may decline the connection handoff and still remain involved and serve the request to the client through the initial server (as a proxy). In this case there is no connection handoff. If the other cluster server rejects the handoff (at 1412), then it is determined (at 1414) whether the initial server should act as a proxy (i.e., whether the other server should serve the client request through the initial server). Preferably the other server determines whether it will serve the request via the initial server, however it should be appreciated that either of the peer servers may chose to handle the request in a proxy manner.
If it is determined (at 1414) that the initial server is not to act as a proxy then the initial server handles the request (at 1410), otherwise the other server handles the request via the initial server as a proxy (at 1416).
If the other cluster server accepts the connection handoff (at 1412), then that other server handles the request (at 1418).
In the embodiments described above, after establishing a connection with a client, the initial server determines whether or not to try to handoff the connection to a peer server (e.g., another server in the cluster) (e.g., at step 1308 in FIGS. 13 and 1408 in FIG. 14). As explained above, the decision to switch to a peer server may be based on a number of factors. In some embodiments, the decision to switch to a peer may be based, at least in part, on load information about the initial server and/or the other server. The decision may be based, at least in part, on load information in the load table, including, in some cases, load information about all of the other servers in the cluster.
Similarly, in the case of proxy serving described above, the decision (at 1414) as to whether or not the initial server is to act as a proxy for the second server may be based, at least in part, on load information about one or more of the servers.
In some embodiments, after an initial server is selected to handle a request, migration to another server (within the same cluster or outside the cluster) may occur as a result of a peering query event. For example, the initial contact machine may accept the connection from the client, read the request and if it has the resource to hand, serve the resource. However, if the initial contact server does not have the requested resource, it will query its peers to see if they have it. The normal response would then indicate from which of those peers (if any) the initial server could fill the resource. In some embodiments the peer response includes the ‘migrate the connection to me’ or ‘proxy the resource through’ options.
In the case of a peer ‘migrate the connection to me’ response, the initial contact server will migrate the connection, e.g., as described above. In the case of peer “proxy the resource through” response, the initial contact server will proxy the response through the designated server. It should be appreciated that the ‘proxy the resource’ option can be used with machines in a different cluster than the one that includes the initial contact server.
In presently preferred implementations there is no option to migrate out of the cluster.
Exemplary processing of peering query events is described with reference to the flowchart in FIG. 15. As in the case with the system described with respect to FIGS. 13 and 14, once a initial server is selected (at 1502) to handle a connection request from a client, that initial server then establishes a TCP connection with the client (at 1504). After the initial TCP connection is established between the client and the initial server, the initial server obtains an actual request (e.g., an HTTP request) from the client (at 1506). If the initial server has the requested resource (at 1508), then it serves that resource (at 1510), otherwise it queries its peers for the resource (at 1512). The initial server obtains and analyzes any peer response(s) (at 1514).
If a peer has the resource and instructs the initial contact server accordingly, then the initial server may obtain the resource from that peer (at 1516). If a peer responds with a “migrate the connection to me” response, the initial contact server may migrate the connection (e.g., as described above) to that peer (at 1518). If a peer responds with a “proxy the resource through” response (identifying a second server), the initial contact server may the proxy the resource through that second server (at 1520). If no peer responds, the initial server may obtain the resource in some other manner, e.g., from an origin server or the like.
Although aspects of this invention have been described with reference to a particular system, the present invention operates on any computer system and can be implemented in software, hardware or any combination thereof. When implemented fully or partially in software, the invention can reside, permanently or temporarily, on any memory or storage medium, including but not limited to a RAM, a ROM, a disk, an ASIC, a PROM and the like.
While certain configurations of structures have been illustrated for the purposes of presenting the basic structures of the present invention, one of ordinary skill in the art will appreciate that other variations are possible which would still fall within the scope of the appended claims. While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

We claim:

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

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

(ii) 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, the method comprising:

(A) in response to a connection request at said switch to connect a client computer to a server associated with said VIP address, a first server of said plurality of servers establishing a first connection with the client computer as a Transmission Control Protocol (TCP) connection;

(B) after establishing the TCP connection with the client computer in (A), and in response to a resource request received by said first server from said client computer for a particular resource, said first server determining whether or not to attempt to handoff the request to a second server of said plurality of servers; and

(C) based on said determining in (B), said first server attempting to handoff the TCP connection with the client computer to the second server when said first server determines that it should attempt to handoff the request to the second server; and,

(D) said second server rejecting the first server's attempted handoff of the TCP connection and said second server serving the particular resource to the client through the first server.

2. The method of claim 1, said connection request having been provided by said switch to each server connected to said switch, the method further comprising:

prior to said first server of said plurality of servers establishing a first connection with the client computer in (A), at least some of said servers determining which server of said plurality of servers is to handle the connection, wherein the determining is based, at least in part, on a first given function of information used to request the connection, whereby the first server is determined to handle the connection.

3. The method of claim 1 further comprising:

said first server updating a firewall of said first server to allow incoming traffic at said first server related to said TCP connection; and

other servers of said plurality of servers each updating a corresponding firewall thereof to reject incoming traffic related to said TCP connection between the client computer and the first server.

4. The method of claim 1 wherein the resource request for the particular resource comprises an HTTP request from said client computer for said particular resource.

5. The method of claim 1 wherein said determining whether or not to attempt to handoff the request to the second server in (B) is based, at least in part, on whether said second server had already handled a previous request from said client computer.

6. The method of claim 5 wherein the said determining whether or not to attempt to handoff the request to the second server in (B) is based, at least in part, on whether said second server had already handled a previous request from said client computer for said particular resource.

7. The method of claim 1 wherein the said determining whether or not to attempt to handoff the request to the second server in (B) is based, at least in part, on whether said second server had already handled a previous request for said particular resource.

8. The method of claim 7 wherein the said determining whether or not to attempt to handoff the request to the second server in (B) is based, at least in part, on whether said second server had previously served said particular resource

9. The method of claim 1 wherein the said determining whether or not to attempt to handoff the request to the second server in (B) is based, at least in part, on whether said second server had previously served said particular resource to any computer.

10. The method of claim 1 wherein the determining in (B) is made based at least in part on at least some information associated with the resource request for the particular resource.

11. The method of claim 10 wherein the resource request for the particular resource comprises an HTTP request from said client computer for said particular resource.

12. The method of claim 11 wherein the information associated with the resource request for the particular resource comprises at least some information from at least one HTTP header associated with the resource request.

13. The method of claim 1 wherein the said determining whether or not to attempt to handoff the request to the second server in (B) is based, at least in part, on whether said second server had previously served any resource to the client computer.

14. The method of claim 10 wherein the determining in (B) is made based at least in part on a second given function of said at least some information associated with the resource request for the particular resource.

15. The method of claim 14 wherein said second given function comprises a hash function.

16. The method of claim 1 wherein said determining in (B) is based, at least in part, on one or more of:

(b1) the type of resource request;

(b2) the type of particular resource requested; and

(b3) the particular resource requested.

17. The method of claim 1 further comprising:

said second server determining whether or not to accept the first server's attempted handoff of the TCP connection.

18. The method of claim 17 wherein the second server rejects the attempted handoff in (D) based, at least in part, on a load on said second server.

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

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

(A) in response to a connection request at said switch to connect a client computer to a server associated with said VIP address, at least some of said servers determining which server of said plurality of servers is to handle the connection, wherein the determining is based, at least in part, on a first given function of information used to request the connection, whereby a first server is determined to handle the connection;

(B) said first server of said plurality of servers establishing a first connection with the client computer as a Transmission Control Protocol (TCP) connection;

(C) said first server updating a firewall of said first server to allow incoming traffic at said first server related to said TCP connection; and

(D) other servers of said plurality of servers each updating a corresponding firewall thereof to reject incoming traffic related to said TCP connection between the client computer and the first server.

(E) after establishing the TCP connection with the client computer in (B), and in response to a resource request received by said first server from said client computer for a particular resource, said first server determining whether or not to attempt to handoff the request to a second server of said plurality of servers; and

(F) based on said determining in (E), said first server attempting to handoff the TCP connection with the client computer to the second server when said first server determines that it should attempt to handoff the request to the second server; and,

(G) said second server rejecting the first server's attempted handoff of the TCP connection and said second server serving the particular resource to the client through the first server.

20. The method of claim 19 wherein the determining in (E) by said first server whether or not to attempt to handoff the request to a second server of said plurality of servers is based, at least in part, on one or more of the following:

(e1) whether said second server had already handled a previous request from said client computer;

(e2) whether said second server had already handled a previous request for said particular resource;

(e3) the type of resource request;

(e4) the type of particular resource requested; and

(e5) the particular resource requested.

21. The method of claim 19 wherein the resource request for the particular resource comprises an HTTP request from said client computer for said particular resource.

22. The method of claim 19 wherein the determining in (E) is made based at least in part on at least some information associated with the resource request for the particular resource.

23. The method of claim 22 wherein the resource request for the particular resource comprises an HTTP request from said client computer for said particular resource.

24. The method of claim 23 wherein the information associated with the resource request for the particular resource comprises information associated with at least one HTTP header.

25. The method of claim 24 wherein the information associated with the at least one HTTP header comprises a URL.

26. The method of claim 19 wherein the determining in (E) is made based at least in part on a second given function of said at least some information associated with the resource request for the particular resource.

27. The method of claim 26 wherein said second given function comprises a hash function.

28. The method of claim 19 further comprising:

29. The method of claim 28 wherein the second server rejects the attempted handoff in (G) based, at least in part, on a load on said second server.

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

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

(B) after establishing the TCP connection with the client computer in (A), and in response to a resource request received by said first server from said client computer for a particular resource, said first server determining whether or not it has a copy of the particular resource;

(C) based on said determining in (B), said first server querying one or more peers regarding the particular resource;

(D) based on said querying in (C), said first server obtaining one or more responses from said one or more peers, and, based at least in part on said one or more responses, said first server performing one of:

(d1) obtaining the particular resource from a first peer of said one or more peers when said first peer indicates that said first peer has a copy of the particular resource; and

(d2) migrating the TCP connection to a second peer when the second peer indicates that the initial peer server should migrate the connection to the second peer; and

(d3) serving the particular resource to the client request through a second server when a third peer indicates that the initial server should proxy the particular resource through the second server.