RU2387002C2 - Levelling network load through connection control - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: network load levelling module has connection transfer unit which can transfer connections from the said module, where the connection transfer unit can compile the protocol status for connection over a network stack; the connection transfer unit can aggregate the compiled protocol status with data for connection to the aggregated connection status for connection; the connection transfer unit can also initiate sending the aggregated connection status to a host; and a classifier which can accept a connection and give out a connection transfer instruction to the connection transfer unit. An information carrier contains instructions executed by a processor, which order the said module to carry out operations which include: reception from the packet of at least part of the source/destination pair; accessing the encapsulation mapping table using at least part of the source/destination pair and replacing part of the packet with a stream identifier in order to create an encapsulated packet.

EFFECT: higher quality of load levelling.

40 cl, 45 dwg

Description

FIELD OF THE INVENTION

This invention relates, in general, to network load balancing and, in particular, to network load balancing by manipulating connections, for example, transferring connections with tunneling and / or transferring connections together with load balancing at the application level.

BACKGROUND

The Internet has had a great influence on communication and many aspects of life using communication. The Internet provides a quick and relatively simple exchange of data between two people or objects (entities). The Internet includes numerous network nodes interconnected, which provides the ability to transfer information between them. Some network nodes can be routers that forward a packet from one communication line to another, can be separate client computers, can be private networks for various entities (for example, intranets in enterprises), etc.

In the case of a private network, as well as in other cases, packets arriving at a node or nodes of the Internet are distributed to other nodes of the private network. Such a private network can be formed, for example, from a group of servers, each of which can process packets arriving at the private network. In private networks of enterprises, universities, public institutions, etc. Numerous packets may arrive over a short time interval. To respond in a timely manner and reduce the likelihood of failure or loss of incoming packets, multiple servers can be used on the private network that can simultaneously process incoming packets.

Incoming packages are often requests related to certain information, such as a document, catalog item, web page, etc. Incoming packages may also refer to a financial transaction between a buyer and a seller. In packet communication, packets can be used for other purposes. In any case, incoming packets are distributed between different servers from the server group to ensure fast packet reception and / or complex communication.

Distributing incoming packets between servers in a server group is often referred to as network load balancing. In other words, the load balancing operation can be performed on packets as they arrive at a node or nodes of the Internet, when the node or nodes form a private network and / or when they connect the private network to the Internet.

Such a load balancing operation is carried out using special equipment that is located “in front” of the private network on the node or nodes connecting the private network to the Internet and / or which ensures the presence of the private network on the Internet. The physical equipment that performs the load balancing operation is usually completely duplicated in order to realize redundancy and increase the reliability of the load balancing operation. To increase the capacity of load balancing operations, the old load balancing equipment is replaced with more powerful equipment that completely repeats the previous load balancing equipment. Thus, the expansion of load balancing is limited by the increase in equipment capacity during its replacement.

To implement the load balancing operation, the equipment usually cyclically distributes incoming connection requests. In other words, incoming connection requests are distributed to servers from a group of servers in a linear, repeating order, with a single connection request being distributed to each server. This cyclic load balancing for connections is typically used regardless of the state of the private network or the nature of incoming connection requests. If the load balancing operation does not extend beyond the cyclic distribution, these other factors are taken into account only insofar as they can be derived from the network and / or from the congestion level of the private network.

US Pat. No. 6,427,171 describes a host central processing unit (CPU) serving a network protocol processing stack. This processing stack provides commands not only for processing network messages, but also for distributing the processing of certain network messages to a specialized network communication device, due to which some load on the most time-consuming protocol processing is transferred from the host CPU to the network communication device. The host CPU, operating according to the instructions from the stack, and the network communication device together determine whether a message will be processed by the host CPU or network communication device, and to what extent it will be processed.

US 2001/0039586 describes a system for sending a request for dynamic content to an application server that has access to a database containing updated data related to the request. The system contains a dynamic content router, database replication tools, and web server plugins. The dynamic content router controls the forwarding of the request by the web server plug-ins to the corresponding application server.

The publication 2002.0194342 describes switching between applications based on content and its methods that allow intelligent redirection of client packets to a single server from a group of servers included in the server farm. For switching, the content of the seventh level of the network model or application is used, extracted from the package through analysis to provide assistance in choosing a server and to plan the transmission of the package to the server. This allows for optimized load balancing and quality of service management tailored to the switching application.

Accordingly, schemes and / or methods for improving network load balancing are required, in particular in systems consisting of a plurality of devices, and / or related operations.

SUMMARY OF THE INVENTION

In accordance with a first aspect of the present invention, there is provided a method according to claim 1.

In accordance with a second aspect of the present invention, there is provided a load balancing module according to claim 21.

In accordance with a third aspect of the present invention, there is provided a host according to paragraph 31 of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For the designation of similar and / or corresponding aspects, features and components in the drawings, the same reference numbers are used.

Figure 1 is an illustrative network load balancing diagram showing load balancing infrastructure and multiple hosts.

FIG. 2 is an illustrative network load balancing scheme showing multiple load balancing modules and multiple hosts.

Figure 3 is a schematic illustration of a load balancing module having separate functions and a host.

4 is an illustrative diagram of a network load balancing infrastructure with separated classification and forwarding functions.

5 is an illustrative flowchart of a method for expanding a network load balancing infrastructure into various configurations.

6 is an illustrative diagram of a first configuration of a network load balancing infrastructure with respect to devices.

7 is an illustrative diagram of a second network load balancing infrastructure configuration with respect to devices.

FIG. 8A and 8B are an illustrative diagram of first and second configurations of a network load balancing infrastructure with respect to components.

FIG. 9A and 9B are an illustrative diagram of a first and second configuration of a network load balancing infrastructure in terms of resources.

10 is an illustrative diagram of an approach to balancing network load using host status information.

11 is an illustrative logical block diagram of a method of balancing network load using host status information.

12 is an illustrative diagram of an approach to balancing network load using health and load information.

Figa is an illustrative table of health and load, indicated in Fig.12.

FIG. 13B is an illustrative combined health and load cache indicated in FIG.

FIG. 14 is an illustrative flowchart of a method for balancing network load using health and load information.

15 is an illustrative diagram of a messaging protocol for transmissions shown in FIG. 12 between hosts and load balancing modules.

FIG. 16 is an illustrative message transmission diagram for transmissions shown in FIG. 12 between hosts and load balancing modules.

FIG. 17A and 17B are illustrative diagrams of scenarios for storing health and load information on the intermediary for the health and load tables shown in FIG. 13A and for the combined health and load caches shown in FIG. 13B, respectively.

FIG. 18 is an illustrative diagram of a distribution procedure for a target host that uses health and load information.

19 is an illustrative diagram of an approach to balancing network load using session information.

FIG. 20 is an illustrative diagram of an approach to balancing network load using the transfer of session information through notifications and messages.

FIG. 21 is an illustrative flowchart of a method for balancing network load using the transmission of session information through notifications and messages.

22 is an illustrative diagram of an approach to managing session information on multiple load balancing modules.

Figa is an illustrative table of sessions indicated in Fig.20.

Figv is an illustrative table (TRDA) of a distributed atom manager (RDA) indicated in Fig.22.

24 is an illustrative flowchart of a method for managing session information on multiple load balancing modules.

25 is an illustrative diagram of a network load balancing infrastructure with a query routing function.

FIG. 26 is an illustrative flow chart of a method for routing incoming packets in accordance with (i) session information and (ii) health and load information.

Fig. 27 is an illustrative flow diagram of routing traffic in the absence of failures.

Fig. 28 is an illustrative flowchart of traffic routing in the event of a failure (s).

29 is an illustrative diagram of additional failover procedures to improve the reliability of the network load balancing infrastructure.

Fig. 30 is an illustrative diagram of an operational implementation of a traffic routing interaction with health and load information.

Fig is an illustrative diagram of mechanisms for ensuring high reliability of the network load balancing infrastructure.

32 is an illustrative diagram of an approach to balancing network load with connection transfer.

Fig. 33 is an illustrative logical block diagram of a method for transferring a connection from a first device to a second device.

Fig. 34 is an illustrative diagram of an approach for transferring connections from the point of view of the sending device.

Fig. 35 is an illustrative diagram of a connection transfer approach from the perspective of the destination device.

Fig. 36 is an illustrative diagram of an approach to an upload procedure for transferring a connection.

Fig. 37 is an illustrative diagram of an approach to a download procedure for transferring a connection.

Fig. 38 is an illustrative diagram of an approach to tunneling packets between a forwarder and a host.

Fig. 39 is an illustrative flowchart of a method for tunneling packets between a first device and a second device.

FIG. 40 is an illustrative diagram of a computer operating environment (or a general purpose device) that is capable of (in whole or in part) implementing at least one aspect of network load balancing described herein.

DETAILED DESCRIPTION OF THE INVENTION

Network load balancing schemes

This section describes illustrative network load balancing schemes and is used to provide principles, environments, contexts, etc. for descriptions in the following sections. In this section, references are mainly made in FIGS. 1-3.

1 illustrates an exemplary network load balancing scheme 100 showing load balancing infrastructure 106 and multiple hosts 108. An exemplary network load balancing scheme 100 includes multiple clients 102 (1), 102 (2) ... 102 (m) and multiple hosts 108 (1), 108 (2) ... 108 (n), as well as network 104 and load balancing infrastructure 106.

Each client 102 may be a device capable of network communication, such as a computer, mobile station, entertainment device, another network, etc. Clients 102 may also refer to a person and / or entity operating a client device. In other words, clients 102 may be logical clients that are users and / or machines. Network 104 may be formed from one or more networks, such as the Internet, intranet, wired or wireless telephone network, etc. Additional examples of devices for clients 102 and network types / topologies for network 104 are described below with reference to FIG. 40 in the section “Illustrative operating environment for a computer or other device”.

Individual clients 102 are able to communicate with one or more hosts 108 and vice versa over a network 104 through load balancing infrastructure 106. Hosts 108 comprise one or more applications for interacting / communicating with clients 102, for use by clients 102, etc. Each host 108 may correspond to a server and / or device, multiple servers and / or multiple devices, server parts and / or device parts, some combinations thereof, etc. Partial implementations of hosts 108 are described below in relation to various cases of network load balancing. (However, application support for hosts 108 is, for clarity, not shown.) Also below, with reference to FIG. 40, in the section entitled “Operating environment for a computer or other device”, examples of devices for hosts 108 are described.

The load balancing infrastructure 106 is reachable or discoverable through the network 104 at one or more virtual Internet Protocol (IP) addresses. Transmissions from clients 102 (or other nodes) directed to the virtual IP address of load balancing infrastructure 106 are received here and forwarded to host 108. Load balancing infrastructure 106 consists of hardware and / or software components (not shown explicitly in FIG. 1) .

Although the infrastructure 106 is shown as a single ellipse, the infrastructure for performing load balancing can also be distributed to other aspects of the illustrative network load distribution circuit 100. For example, the software component (s) of the load balancing infrastructure 106 may / may reside on one or more hosts 108, as described below. Examples of architectures of load balancing infrastructure 106 are described below with reference to FIG. 40 in the section entitled “Illustrative operating environment for a computer or other device”.

According to (1), one or more hosts 108 may provide host status information from hosts 108 to load balancing infrastructure 106. This host status information may vary by application. Examples of such host status information are described below and include health and / or load information, session information, etc. for hosts 108. A specific implementation, including the provision of health and / or load information from hosts 108 to load balancing infrastructure 106, is described below in the section entitled “Illustrative Health and Load Management”.

Position (2) denotes a request transmitted from the client 102 (1) through the network 104 to the load balancing infrastructure 106 by its virtual IP address. Content, format, etc. the request from client 102 may depend on the application to which the request is addressed, and the term “request” may implicitly include the response or responses of the host (s) 108, depending on the context. Types of client requests include, but are not limited to:

1. GET requests for the transmission of hypertext files (HTTP) from the client using a browser program. Depending on the application (in particular, on the unified index (URL) of the request resource), it may be better to serve requests by different groups of hosts, and the existence of a client “session” state on hosts may prevent routing of these requests from specific clients to specific hosts. Requests can be sent via a secure socket protocol (SSL) connection (or another encrypted connection).

2. Virtual Private Network (VPN) connections (for example, hosts are a group of VPN servers). In this case, the “request” can be considered as a “connection” using the Layer 2 Tunneling Protocol (L2TP) or Point-to-Point Tunneling Protocol (PPTP) (the latter is a combination of the transmission control protocol (TCP) connection and the corresponding encapsulated general routing data (GRE).

3. Terminal server connections (for example, hosts are a group of terminal servers).

4. Own requests in the form of individual TCP connections (one per request) using their own application-specific protocol.

5. Requests for the Simple Object Access Protocol (SOAP).

6. Real-time communication requests that provide control information over a TCP connection and delay-sensitive multimedia streaming via real-time protocol (RTF).

Thus, requests can take many forms depending on the application. In some described embodiments, the load balancing infrastructure 106 may make forwarding decisions depending on the application.

Position (3) indicates that the load balancing infrastructure 106 forwards the request from 102 (1) to the host 108 (2) (in this example). The load balancing infrastructure 106 may consider one or more factors when choosing a host 108 to forward the request depending on which / which of the implementations described here are used. For example, load balancing infrastructure 106 may consider: application health and application information for each host 108, session information related to client 102 (1) stored on host 108, etc.

2 illustrates an exemplary network load balancing circuit 200 showing multiple load balancing modules 106 and multiple hosts 108. In particular, in an illustrative network load balancing circuit 200, load balancing infrastructure 106 is shown as multiple modules 106 (1), 106 ( 2), ..., 106 (u) load balancing. In addition, two routers and / or switches 202 (1) and 202 (2) are shown.

Routers / switches 202, if present, can be considered as part of the infrastructure load balancing 106 (figure 1) or separately from it. Routers / switches 202 are responsible for forwarding all requests and individual packets coming from network 104 to the shared virtual IP address (s) (VIP) of load balancing modules 106. In the event of a failure of the first router / switch 202, the second router / switch 202 assumes its functions. Although two routers / switches 202 are shown, alternatively one or more of two routers / switches 202 can be used.

Routers / switches 202 may not be aware of load balancing infrastructure or may be aware of load balancing. If the routers / switches 202 are not aware of load balancing, then one of two options can be used. The first of these is that a shared VIP address is “assigned” to one load balancing module 106, and all network traffic is forwarded to it. Then this one load balancing module 106 evenly redistributes the traffic to the other load balancing modules 106. However, problems and bridging issues arise with the first option (which can be mitigated by having multiple shared VIP addresses and sharing between multiple load balancing modules 106). The second option is that routers / switches 202 are “tricked” towards network traffic to all load balancing modules 106, each of which independently decides which traffic to accept for load balancing. However, this second option leads to insufficient duplication of effort and to switch performance / compatibility issues.

If routers / switches 202 are aware of load balancing, then routers / switches 202 can be made to distribute incoming network traffic between multiple load balancing modules 106 (e.g., in cyclic mode). It should be understood that such routers / switches 202 that are aware of load balancing are capable of performing load balancing functions at a rudimentary level (e.g., hardware). For example, routers / switches 202 that are aware of load balancing can easily identify session affinity based on IP addresses so that all packets from a particular source IP address are routed to the same load balancer 106.

Each separately shown load balancing module 106 from load balancing modules 106 may represent one physical device, multiple physical devices, or part of a single physical device. For example, load balancing module 106 (1) may correspond to one server, two or more servers. Alternatively, the load balancing module 106 (1) and the load balancing module 106 (2) may jointly correspond to one server. An exemplary load balancing module 106 is described below in terms of its functions with reference to FIG.

Figure 2 shows two illustrative query paths [1] and [2]. As for the request path [1], the client 102 (2) sends the request over the network 104, and this request arrives at the router / switch 202 (1). Router / switch 202 (1) routes the request packet (s) from client 102 (2) to load balancing module 106 (1). Then, load balancing module 106 (1) forwards the request packet (s) to host 108 (1) in accordance with some load balancing functions (e.g., a policy). As for the request path [2], the client 102 (m) transmits the request over the network 104, and this request arrives at the router / switch 202 (2). Router / switch 202 (2) sends the request packet (s) received from client 102 (m) to load balancing module 106 (u). Then, load balancing module 106 (u) forwards the request packet (s) to host 108 (n) in accordance with some load balancing functions. Illustrative load balancing functions are described below with reference to FIG. 3.

FIG. 3 shows an exemplary distributed load balancing module 106 and an illustrative host 108. The load balancing module 106 comprises seven (7) function blocks 302-314. These functional blocks of the load balancing module 106 may be implemented, at least in part, by software. The host 108 includes one or more applications 316. In the described embodiment, the load balancing module 106 includes a forwarder 302, a classifier 304, a request router 306, a session tracking unit 308, a connection transfer unit 310, a tunneling unit 312, and a health and load handler 314 .

A health and load processor 314 is partially located on the hosts 108 and partially on the devices of the load balancing modules 106. The health and load processor 314 monitors the health and / or load (or, more generally, the status) of the hosts 108 so that its health and / or load information can be used for load balancing functions (for example, when making decisions about load balancing). Illustrative implementations of the health and load processor 314 are described below, in particular, in the section entitled “Illustrative Health and Load Processing”.

Session tracking unit 308 may also be located partially on hosts 108 and partially on devices of load balancing modules 106. Session tracking unit 308 monitors sessions established by clients 102 to facilitate load balancing functions to restore / continue previously established sessions. For example, some applications support client-specific client session data (which is also some kind of status information) on hosts. These applications typically expect clients to use the same host for any given session. Illustrative types of sessions include: (i) a TCP connection (which, strictly speaking, is a session); (ii) SSL session; (iii) secure IP session (IPsec); (iv) an HTTP cookie session; etc.

Although the session tracking unit 308 is shown as a separate unit in the load balancing module 106, the session tracking function of the session tracking unit 308 can in fact be implemented globally. In other words, session affinity is supported across multiple load balancing modules 106. Session tracking unit 308 includes a centralized database and / or a distributed database of session information to maintain affinity for the session. Illustrative implementations of the session tracking unit 308, with emphasis on a distributed database approach, are described below, particularly in the section entitled “Session Tracking”.

Classifier 304 uses the data collected and maintained by the health and load processor 314 and / or session tracking unit 308, possibly in conjunction with other factors, to classify incoming requests. In other words, the classifier 304 allocates the destination host 108 for each incoming request from the client 102. The forwarding unit 302 forwards the client's requests (and / or its packets) in accordance with the destination host 108 selected by the classifier 304. The forwarding unit 302 and the classifier 304 are described below. in particular, in the sections entitled “Illustrative approach to flexible load balancing” and “Illustrative classification, forwarding and routing of requests”.

Request router 306, unlike packet-oriented implementations of forwarder 302 and classifier 304, can act as an intermediary for an application running on host 108. For example, request router 306 can terminate TCP connections, analyze (possibly partially) each logical request from client 102 and redirect each logical request to destination host 108. Therefore, each logical request from the client 102 can be directed to one or another host 108 depending on the decisions made by the router 306 requests. In addition, the request router 306 can pre-process on the connection (for example, SSL decryption), it can select the absorption of certain requests (for example, because the request router 306 supports the response cache), it can change the requests at its discretion before forwarding them to hosts 108, etc. Exemplary implementations of the request router 306 are also described below, in particular in the sections entitled “Illustrative approach to flexible load balancing” and “Illustrative classification, forwarding and routing of requests”.

The connection transfer unit 310 first terminates the connection on the load balancing module 106 and then transfers it so that the connection subsequently ends on the host 108. This transfer of connections can facilitate application-level load balancing. The connection transfer unit 310 is capable of transferring the connection from the load balancer 106 to the host 108 so that the initial termination on the load balancer 106 is transparent to the requesting client 102 and applications 316 of the newly terminating host 108. The tunneling unit 312 may use an encapsulation scheme to tunnel packets , which does not introduce excessive load in each tunneled packet.

The functions of tunneling unit 312 can also be used in cases that do not involve connection transfer. In addition, connection transfer unit 310 and / or tunneling unit 312 can be further used in implementations without load balancing. Exemplary implementations of the connection transfer unit 310 as well as the tunneling unit 312 are described below, in particular, in the section entitled “Illustrative connection transfer with optional tunneling and / or load balancing at the application level”.

Any given implementation of load balancing module 106 may include one or more of the illustrated functions. Although each of the functions of blocks 302-314 is shown separately, it can actually be interconnected with, overlap with, and / or be part of other functions. For example, classifier 304 may use health and / or load information of health and load handler 314. In addition, the connection transfer unit 310 and the tunneling unit 312 work in conjunction with the forwarding unit 302 and the classifier 304. Certain other illustrative overlaps and interactions are described below.

In the described implementation, one or more applications 316 are running on host 108 and access is provided to them. In general, applications 316 include file delivery programs, management / website server programs, remote access programs, email programs, database access programs, and the like. In particular, applications 316 may include, but are not limited to, Microsoft® Internet Information Server® (IIS), terminal servers, such as Microsoft® Terminal Server ™, and firewall and reseller products, such as Internet Security and Acceleration Server ™ ( ISA). Although the specific application examples 316 in the previous sentence relate to Microsoft products, the network load balancing described here is not limited to any particular vendor (s), application (s) or operating system (s).

Flexible Network Load Balancing Approach

This section shows how the network load balancing implementations described in this and other sections provide a flexible approach to network load balancing. In this section, the links go mainly to FIGS. 4-9B.

As noted above, the network load balancing functions can be expanded by replacing the first network load balancer with a second, larger and more powerful network load balancer. The hardware capabilities of the second network load balancer repeats all the hardware capabilities of the first network load balancer, with the exception of providing higher capacity. This is an inflexible approach that can be very inefficient, especially when the only sign of network load balancing is performance limitation and conditional update of the network load balancer.

4 shows a network load balancing infrastructure having separate classification and forwarding functions. The divided classification function and the forwarding function are represented by the classifier 304 and the forwarding unit 302, respectively. Although the classification and forwarding functions are described below, especially in the section entitled “Illustrative classification, forwarding, and routing of requests,” the primary description is presented here as an example of the interaction between the functional units of the network load balancing infrastructure and the hosts 108.

In the described implementation, the forwarding unit 302 corresponds to the virtual IP address (VIP) (or addresses) and is the network endpoint for it (them). Forwarder 302 is a relatively low-level component that makes simplified and / or elementary policy decisions, if any, when routing packets to a further or final destination. Forwarder 302 checks the routing table to determine this destination. Classifier 304 populates the routing table based on one or more factors (eg, host status information), which are described in other sections.

Clients 102 and hosts 108 also match the specified network addresses. In particular, client 102 (1) corresponds to address C1, client 102 (2) corresponds to address C2, ... client 102 (m) corresponds to address Cm. In addition, host 108 (1) corresponds to H1, host 108 (2) corresponds to H2, ... host 108 (n) corresponds to Hn.

Figure 4 shows five communication paths (1) to (5). A communication path (1) passes between the client 102 (1) and the forwarding unit 302, and a communication path (5) passes between the forwarding unit 302 and the host 108 (1). Communication paths (2) to (4) pass between the forwarder 302 and the classifier 304. For simplicity, in this example, the connections associated with the communication paths (1) to (5) will be considered HTTP TCP connections. In addition, load balancing in this example refers to routing incoming connections to at least a busy host 108, at least without any explicit consideration for load balancing at the application level.

Communication paths (1) to (5) indicate how the forwarder 302 and classifier 304 balance the load of one HTTP TCP connection from client 102 (1). On path (1), client 102 (1) initiates a TCP connection by sending a TCP SYN packet addressed to the VIP address. Network routing infrastructure 104 routes this packet to forwarding unit 302 via router / switch 202 (1), which is the “closest” router / switch 202 to forwarding unit 302.

On path (2), the forwarding unit 302 checks the routing table, which may be internal to the forwarding unit 302 or otherwise available to him to find this connection. This connection can be identified in the routing table by an ordered four TCP / IP (i.e. source IP address, source TCP port, destination IP address, destination TCP port). Since this is the first connection packet, there are no entries in the routing table. Therefore, the forwarding unit 302 applies the “default route” action, according to which this packet must be forwarded to the classifier 304.

On path (3), the classifier 304 checks against its (e.g., combined) host status information cache for hosts 108 (1), 108 (2), ..., 108 (n). Classifier 304 concludes that host 108 (1) is available and is the last loaded host 108 at this point in this example. Classifier 304 also “paves” a route in the routing table that is forwarded by forwarder 302 for this TCP connection. For example, classifier 304 adds a route element or causes the forwarder 302 to add a route element to a routing table that maps a TCP connection (for example, identified by an ordered four TCP) to a specific destination host 108, which in this example is host 108 (1). In particular, the route element indicates the network address H1 of the host 108 (1).

On path (4), the classifier 304 sends the TCP SYN packet back to the forwarder 302. Alternatively, classifier 304 may forward this initial TCP SYN packet to host 108 (1) without using the forwarder 302. Other available classifier 304 options are described below.

On path (5), forwarding unit 302 may access a route element for the connection represented by SYN packets to forward the packet to host 108 (1) at address H1. Forwarder 302 also forwards all subsequent packets from client 102 (1) for this connection directly to host 108 (1). In other words, forwarding unit 302 can avoid further interaction with classifier 304 for this connection. You can use one or more of the mechanisms described below to delete a route item when the connection is complete.

Regarding path (5), in many protocol environments, forwarder 302 cannot simply send packets from client 102 (1) as it is to host 108 (1) at network address H1, because these packets are addressed to the VIP address that is hosted by yourself forwarding unit 302. Instead, forwarder 302 may use one or more of the following illustrative options.

1. Forwarding unit 302 performs network address translation (TCA) (i) by recording instead of the IP address (C1) (client 102 (1)) and source port number, the IP address and port number generated by the TCA, forwarding unit 302 and (ii) recording instead of the destination IP address (VIP) the host IP address (H1) (108 (1)).

2. Forwarding unit 302 performs a “semi-TSA”, instead of recording the destination IP address (VIP), the host IP address (H1) (108 (1)), which allows you to save the IP address (C1) and the port number of the source (client 102 (1)).

3. Forwarding unit 302 “tunnels” packets received from client 102 (1) from forwarding unit 302 to host 108 (1). In particular, in this example, tunneling can be accomplished by encapsulating each packet in a new IP packet that is addressed to host 108 (1). Software aware of network load balancing on host 108 (1) reconstructs the original packet upon receipt of a forwarding block 302 from client 102 (1). This source packet is then indicated on the virtual interface on host 108 (1) (for example, the VIP address corresponding to the forwarding unit 302 is mapped to this virtual interface on host 108 (1)). Illustrative implementations of such tunneling are described below with reference to tunneling block 312, especially for connection transfer scenarios, and in particular in the section entitled “Illustrative transfer of connections with optional tunneling and / or load balancing at the application level”.

Although in FIG. 4-9B show two specific separated functions, namely classification and forwarding, it should be understood that other functions, for example, the functions of the request router 306, session tracking unit 308, connection transfer unit 310, and health and load handler 314 can also be expanded independently ( for example, independently proportionally increase), as described below. In addition, it should be noted that one or more of two functions can be separated and expanded independently at different points in time and / or simultaneously. In addition, although TCP / IP is used in many examples in this and other sections for clarity, the principles of network load balancing described here apply to other transmission and / or communication protocols.

According to the example shown in FIG. 4, the network load balancing functions (for example, shown in FIG. 3) can be separated from each other for expansion purposes. They can also be split and duplicated in various configurations to increase reliability. Illustrative configurations for scalability and / or reliability are described below with reference to Fig.6-9B after the description of the method with reference to Fig.5.

5 is a flowchart 500 of an illustrative method for expanding a network load balancing infrastructure into different configurations. Logical block diagram 500 comprises three blocks 502-506. Although the actions of the logic flow diagram 500 may be performed in other environments through a variety of software schemes, FIG. 1-4 and 6-9B are used, in particular, to illustrate certain aspects and examples of the method.

At block 502, the network load balancing infrastructure is operated in a first configuration. For example, each configuration may relate to one or more of the emphasis, proportion, and / or relationship of various load balancing functions; to a number and / or type (s) of various devices; to the organization and / or layout of the various components; to the allocation and / or allocation of resources; etc. At block 504, the network load balancing infrastructure is expanded. For example, individual load balancing functions can be expanded and / or reduced in a consistent manner on an individual and / or independent basis. At block 506, the expanded network load balancing infrastructure is operated in a second configuration.

As noted above, a monolithic network load balancer can be expanded by expanding all network load balancing functions by replacing legacy load balancing equipment with more powerful network load balancing equipment. In contrast, expanding the network load balancing infrastructure can allow individually and / or independently expanding (sub) network load balancing functions. It can also allow expanding network load balancing functions together or individually between different numbers of devices. The following are examples of extensions for devices, components, and resources.

6 shows a first configuration of a network load balancing infrastructure with respect to devices. In this first configuration of a device-oriented network load balancing infrastructure, three devices 602 (1), 602 (2), and 602 (3) are shown. However, alternatively, one, two or more than three devices 602 may be used.

It is shown that on the device 602 (1) are present and run block 302 (1) forwarding, classifier 304 (1) and host 108 (1). On the device 602 (2) there are a forwarder 302 (2), a classifier 304 (2), and a host 108 (2). In addition, forwarding device 602 (3) includes a forwarder 302 (3), a classifier 304 (3), and a host 108 (3). Thus, in this first configuration of the device-oriented network load balancing infrastructure, the respective forwarder 302, the classifier 304, and the host 108 share the resources of each respective device 602.

During operation, forwarding units 302 are endpoints for the VIP address (s). Any classifier 304 may plot a route to connect to any host 108, depending on the host status information. For example, classifier 304 (2) may route a new incoming connection to host 108 (3). According to the new route element for this connection, the forwarding unit 302 (2) forwards the following packets to the host 108 (3).

In one alternative configuration of the network load balancing infrastructure for devices into which the first configuration can be expanded, a fourth device 602 (4) (not shown explicitly in FIG. 6) may be added, which comprises a forwarder 302 (4), a classifier 304 (4) and host 108 (4). If sufficient classification functions are already present with the classifiers 304 (1-3), but additional functions can facilitate the processing of requests on the hosts 108, a fourth device 602 (4) can be added, which contains a block 302 (4) forwarding and, optionally host 108 (4). For this advanced configuration, another classifier 304 (1, 2 or 3) may route routes for forwarding unit 302 (4) to any of hosts 108 (1, 2 or 3) and host 108 (4), if any.

The first configuration of the network load balancing infrastructure, oriented to the device depicted in FIG. 6, may be particularly suitable for smaller hosting situations in which separate devices for the network load balancing infrastructure are not technically and / or economically adequate or viable. However, when the hosting load expands to more (and / or more demand for the same number) hosts 108 or if the network load on the hosts 108 is significant, the first device-oriented network load balancing infrastructure configuration can be converted to accommodate this expansion represented by the second configuration of the device-oriented network load balancing infrastructure shown in FIG. 7.

7 shows a second configuration of a network load balancing infrastructure with respect to devices. In this second configuration of the device-oriented network load balancing infrastructure, three devices 602 (1), 602 (2) and 602 (3) are also shown. Again, illustratively, you can use one, two or more than three devices 602.

It is shown that on the device 602 (1) are present and run block 302 (1) forwarding and classifier 304 (1). On the device 602 (2), a forwarding unit 302 (2) and a classifier 304 (2) are present. In addition, forwarding device 602 (3) includes a forwarder 302 (3) and a classifier 304 (3). Thus, in this second configuration of the device-oriented network load balancing infrastructure, each respective forwarder 302 and classifier 304 do not share the resources of each respective device 602 with the host 108. In addition, the network load balancing infrastructure can serve any number of hosts 108.

During operation, forwarding units 302 are again endpoints for the VIP address (s). In addition, any classifier 304 may plot a route to connect to any host 108, depending on the host status information. For example, classifier 304 (3) may route a new incoming connection to host 108 (2). According to the new route element for this connection, the forwarding unit 302 (3) forwards subsequent data packets to the host 108 (2).

Therefore, the network load balancing infrastructure implemented by software can be expanded by moving the network load balancing infrastructure (or part thereof) from devices shared with hosts 108 to devices not shared with hosts 108. In addition, as described above with reference 6, another device 602 (4) can be added to the network load balancing infrastructure to provide additional forwarding functions, additional classification functions, additional functions both types, etc.

In FIG. 8A and 8B show a first and second configuration of a network load balancing infrastructure with respect to components. It is depicted that the first component-oriented configuration 800 network load balancing infrastructure contains four components. The second component oriented configuration 850 network load balancing infrastructure contains six components. An alternate second configuration 850 is a seventh component, indicated by a block represented by a dashed line, which will be described later.

In particular, the first component-oriented configuration 800 network load balancing infrastructure (or the first configuration 800) contains (i) two blocks 302 (1) and 302 (2) forwarding and (ii) two classifiers 304 (1) and 304 (2) . The second component-oriented network load balancing infrastructure configuration 850 (or second configuration 850) comprises (i) four forwarding units 302 (1), 302 (2), 302 (3) and 302 (4), and (ii) two classifiers 304 ( 1) and 304 (2). Thus, the first configuration 800 is expanded into the second configuration 850 by adding two components, which in this example are forwarding components.

In the described implementation, each functional component related to network load balancing corresponds to a corresponding device (not shown explicitly in FIGS. 8A and 8B); however, each component may alternatively correspond to a part of the device or more than one device. For example, forwarding units 302 (1) and 302 (2) can be distributed across three devices. Alternatively, the forwarding unit 302 (1) and the classifier 304 (1) may correspond to the first device, and the forwarding unit 302 (2) and the classifier 304 (2) may correspond to the second device.

To expand the first configuration 800, two functional components related to network load balancing are added to the second configuration 850. However, to expand the network load balancing infrastructure, you can alternatively add one component (or more than two). In addition, you can “simultaneously” expand two or more functional components of different types. For example, when expanding the first configuration 800 to the second configuration 850, you can also add another classification component (for example, classifier 304 (3)), indicated by the block shown by the dashed line.

In addition, the expansion of two or more functional components of different types can be carried out in similar (eg, equivalent) or inappropriate proportions to each other. It has been shown that the addition of components 302 (3) and 302 (4) without the addition of any classification component 304 or with the addition of one classification component 304 (3) represents an extension in unacceptable proportions. However, to expand in similar proportions when adding two forwarding components 302 (3) and 302 (4), two classification components 304 (3) and 304 (4) can be added (the latter case is not shown explicitly in FIG. 8B). However, different functional components related to network load balancing may consume different amounts of available network load balancing infrastructure resources, as described with reference to FIG. 9A and 9B.

In FIG. 9A and 9B show the first and second configurations of the network load balancing infrastructure in terms of resources. The first resource-oriented network load balancing infrastructure configuration 900 (or first configuration 900) comprises a first resource allocation or allocation for load balancing module 106. The second resource-oriented configuration of the network load balancing infrastructure 950 (or the second configuration 950) comprises a second allocation or allocation of resources for the load balancing module 106.

It is shown that the first configuration 900 contains a resource allocation of 70% -30%, and the second configuration 950 contains a resource distribution of 40% -60%. Such resources may include resources of the entire device (e.g., the number of devices), processing resources (e.g., the number of processor cycles), memory resources (e.g., a portion of the cache, main memory, etc.), bandwidth and / or interface resources Networks (e.g., bits per second and / or physical network adapters (CAs), etc.).

In particular, for the first configuration 900, the forwarder 302 consumes 70% of the resources of the load balancer 106, and the classifier 304 consumes 30% of these resources. After re-allocation during the expansion procedure to create a second configuration 950, the forwarder 302 consumes 40% of the resources of the load balancer 106, and the classifier 304 consumes 60% of these resources.

In the illustrated case, the first configuration 900 is intended to improve network load balancing performance when the corresponding hosts (not shown in FIGS. 9A and 9B) process fewer longer transactions since the classification functions are used after the initial connection to connect, and the forwarding functions are used later. The second configuration 950, by contrast, is designed to improve network load balancing performance when the corresponding hosts process a larger number of shorter transactions, since the classification functions are used for a larger percentage of the total number of packets tunneled through the network load balancing infrastructure. In this case, if query routing functions are also used, then the query router (s) 306 are also allocated a percentage of the total computing resources. The distribution of resources between the three functions can be adjusted during the processing of compounds (for example, adjusted on the fly) depending on current consumption and / or scarcity of resources.

According to FIG. 2 and 3, each load balancing module 106 may correspond to all or part of the entire network load balancing infrastructure 106. For each given physically, logically, arbitrarily, etc. of a predetermined or specified load balancing module 106, its resources can be re-allocated through an extension procedure. In particular, the distribution of resources between different shared functions related to network load balancing of the load balancing module 106 can be changed through an extension procedure. In addition, more than two different functions, as well as other functions related to network load balancing, which are not specifically shown in FIG. 9A and 9B, varying percentages of resources can be allocated.

The percentage of total system resources allocated to all load balancing functions can also be changed through an extension procedure. As an example of total processing power, the percentage of total processing power allocated for load balancing can be gradually increased as the amount of traffic for which load balancing is to be performed is increased.

Network load balancing software may optionally monitor to analyze and determine whether resources should be reallocated. For example, network load balancing software can track processor usage with various functions related to network load balancing. Actual redistribution can also, optionally, be done automatically by the network load balancing software, either offline or online.

It should be understood that the enhanced capabilities of the network load balancing infrastructure described here (for example, implemented, at least in part, by software) may relate to different installations and not necessarily to a change in one installation. In a resource-oriented example, the network load balancing infrastructure described herein can be configured according to one resource allocation in one installation environment and can be configured according to a different resource distribution in another installation environment having different operating parameters. Additionally, the features, features, options, etc. described above with respect to expansion are also applicable to narrowing. In other words, the resources allocated to the network load balancing infrastructure (or its sub-functions) can also be reduced.

Health and Load Handling

This section describes how host status information, such as health and / or load information, can be collected and used to balance network load. In this section, the links go mainly to FIGS. 10-18 and discusses the health and load functions, for example, provided by the health and load handler 314 (FIG. 3). As described above with reference to FIG. 3, each host 108 hosts one or more applications 316. The health and load handler 314 uses the health and / or load information related to applications 316 and / or hosts 108 for the specific described network load balancing implementations described.

Figure 10 shows an approach to balancing network load using information 1006 host status (ISX). Each host 108 (1), 108 (2), ..., 108 (n) includes one or more applications 316 (1), 316 (2), ..., 316 (n), respectively. These hosts 108 in general, and these applications 316 in particular, may change status from time to time.

For example, hosts 108 and applications 316 may accept new connections or not accept new connections. In addition, they can quickly process client requests or slowly process client requests. In addition, they can have many resources in reserve or few unused resources. All or part of such data or other data may contain host status information 1006. In general, the host status information 1006 provides an indication of the status of some aspect of the hosts 108 and / or their applications 316.

In the described implementation, each host 108 (1), 108 (2), ..., 108 (n) contains a qualifier 1002 (1), 1002 (2), ... and 1002 (n), host status information (ISX), respectively. Each host 108 (1), 108 (2), ..., 108 (n) also contains a distributor 1004 (1), 1004 (2), ... and 1004 (n), respectively, host status information (ISX). Each host status information determiner 1002 and / or host status information distributor 1004 may be part of a load balancing infrastructure (TDI) 106.

Each host status information determiner 1002 determines the host status information 1006 for a respective host 108 and / or its applications 316. Illustrative methods for determining such host status information 1006 are described below with reference to FIGS. 12-14 and, in particular, FIG. 13A. Each host status information distributor 1004 distributes the host status information 1006 for the corresponding host and / or applications 316 to the load balancing infrastructure 106 (for example, those / those parts / parts of the load balancing infrastructure 106 that are not located on the hosts 108). Illustrated methods for distributing such host status information 1006 are described below with reference to FIGS. 12-17 and, in particular, to FIGS. 13B and 15-17.

In particular, each host state information distributor 1004 distributes the host status information 1006 (directly or indirectly) to each load balancing module (MVS) of the load balancing infrastructure 106, which includes at least one health and load processor 314 and / or classifier 304. The load balancing infrastructure 106 refers to the host status information 1006 when implementing network load balancing. For example, as indicated by logic 1008, load balancing infrastructure 106 is capable of making load balancing decisions in accordance with host status information 1006.

In operation step (1), status information determinants 1002 determine host status information 1006 for respective hosts 108 and / or applications 316. In steps (1) and (2), host status information distributors 1004 distribute host status information 1006 from hosts 108 to infrastructure 106 load balancing. For example, host status information 1006 may be distributed to individual load balancing modules 106. At step (3), the logic 1008 makes decisions to balance the network load in accordance with the host status information 1006. In step (4), the connections are forwarded to destination hosts 108 based on these network load balancing decisions.

11 shows a flow chart 1100 of a method for balancing network load using host status information. Logical block diagram 1100 comprises three blocks 1102-1106. Although the actions of the logical flowchart 1100 may be carried out in other environments and through various software circuits, FIG. 1-3 and 10 are used, in particular, to illustrate certain aspects and examples of the method.

At 1102, host status information is sent from hosts to load balancing modules. For example, host status information 1006 may be sent from hosts 108 to load balancing modules 106. At 1104, host status information is received from hosts on load balancing modules. For example, load balancing modules 106 receive host status information 1006 from hosts 108. At block 1104, load balancing decisions are made in accordance with the received host status information. For example, logic 1008 on load balancing modules 106 may make decisions to balance network load in accordance with host status information 1006.

Thus, in FIG. 10, load balancing infrastructure 106 collects host status information 1006 from hosts 108 (and / or their applications 316) and incoming load balancing requests addressed to hosts 108 in accordance with host status information 1006. As described below with reference to FIGS. 12-18, this host status information 1006 may be application dependent. Also, as described below, examples of host status information 1006 include health and / or load information.

12 shows an approach to balancing network load using health and / or load information (IRI) 1206. Hosts 108 (1), 108 (2), ..., 108 (n) are connected to load balancing modules 106 (1), 106 (2), ..., 106 (u) via communication means 1210, such as a network.

Hosts 108 are shown to transmit health and load information 1206 to load balancing modules 106 using communication means 1210. Two-way communication of health and load information 1206, indicated by a two-way arrow, refers to two-way communication between load balancing modules 106 and hosts 108, which provides a certain completeness, coherence, accuracy, etc., resulting in hosts 108 and / or alignment modules 106 loads may fail independently of each other. Such two-way communications between load balancing modules 106 and hosts are described below with specific reference to FIG.

Health information reflects whether a given host and / or application is capable of processing client requests. The load information reflects the number, size and / or level of client requests that a given host and / or application is capable of (but) processing at a given moment in time. In other words, the load reflects directly or inversely the amount, amount and / or level of full capacity of a given host and / or application. As noted above, implementations described with reference to FIGS. 12-18 focus on health and / or load information; however, these implementations also apply to general status information for hosts (including their applications).

In the described implementation, each host 108 (1), 108 (2), ..., 108 (n) contains the corresponding component 1202 (1), 1202 (2), ..., 1202 (n) of the health and load infrastructure (IRiN). Each component 1202 of the health and load infrastructure can optionally be part of the load balancing infrastructure 106 that is located and runs on each host 108. The health and load information 1206 can be implemented by software. When operating, each infrastructure 1202 (1), 1202 (2), ..., 1202 (n) creates and maintains a table 1204 (1), 1204 (2), ..., 1204 (n) of health and load (RiN).

Health and load tables 1204 may include application-specific elements. Health and load information 1206 stored in health and load tables 1204 may be independent of load balancing infrastructure 106. For example, administrators, designers, etc. can set criteria for information 1206 health and load during configuration. Additionally, elements external to the device, which is the host 108 or contains it, can help determine the health information 1206 and the load for applications 316 on the device. An illustrative health and load table 1204 is described below with reference to FIG. 13A.

Each load balancing module 106 (1), 106 (2), ..., 106 (u) includes a corresponding combined cache 1208 (1), 1208 (2), ..., 1208 (u) of health and load (RiN). Each combined health and load cache 1208 contains information from each health and load table 1204 (1), 1204 (2), ..., 1204 (n). Therefore, each load balancing module 106 is provided with quick (eg, cached) access to health and load information 1206 for each host 108 for which load balancing modules 106 balance the load of network traffic.

During operation, the health and load infrastructure 1202 transfers health and load information 1206 from the health and load tables 1204 to the combined health and load caches 1208. The mechanism for providing health and load information 1206 is event driven, whereby changes to the health and load tables 1204 arrive in the combined health and load caches 1208 in a timely and scalable manner.

On figa shows the table 1204 health and load, indicated in Fig.12. In the described implementation, the health and load table 1204 contains multiple elements 1302, each of which is associated with a separate application 316. Each element 1302 may correspond to a row in the health and load table 1204, which has three columns. These columns correspond to application identifier (ID) 1302 (A), application status specification 1302 (B), and load balancer directive 1302 (C).

Since each element 1302 is associated with a specific application 316, each time the application is started (for example, by the administrator), a line is added. Similarly, every time you close the application, the line is destroyed / deleted. Similarly, the individual fields in columns 1302 (A), 1302 (B) and / or 1302 (C) change / update when their values change. For example, when you change the value of the status characteristic for this application 316, the value 1302 (B) of the application status characteristic field for the element 1302 of this application 316 is updated.

Additions and deletions of elements 1302 for applications 316 can be accomplished using input from the management manager on host 108. For example, the operating system management manager knows when application 316 starts and stops working because it is actively involved in starting and stopping applications 316. Therefore, the manager the control may indicate that he, at least partially, has started the application 316, and the control manager may establish that he, at least partially, has stopped the application 316. Thus, the manager management can inform the health and load infrastructure 1202 of starting and stopping applications 316. Therefore, it is not necessary to explicitly transfer data from applications 316 to the health and load infrastructure 1202. An example of a management manager is the Microsoft® Windows® Operating System Services Management Manager (DLS).

The application identifier 1302 (A) contains information used to uniquely identify the application 316 to which element 1302 is associated. The application identifier 1302 (A) may contain one or more of the following for the corresponding application 316: virtual IP address and port, physical IP address and port, protocol used and any information related to the protocol. The protocol can be HTTP, IPsec, SOAP, etc. The protocol-related information may be a URL pattern or string to further indicate the application associated with item 1302. Thus, the application identifier 1302 (A) more specifically refers to the endpoint of the application on a specific host 108.

Alternatively, other application identifiers may be used. For example, to reduce the load on the communication line, application identifier 1302 (A) may be a 32-bit binary number corresponding to the above illustrative information on health and load infrastructure 1202 and load balancing modules 106. In addition, any of the fields in element 1302 may actually contain a globally unique identifier (GUID) used as a key to search for true information for the field.

The application status characteristic 1302 (B) contains information reflecting the status of the application 316 to which the element 1302 is associated. The application status characteristic 1302 (B) contains the following for the corresponding application 316: application health, application load, and application capacity. Application health is a quasi-Boolean value indicating whether the application is running. The health of the application can take the values “operational”, “inoperative” and “unknown”. Application health is a relatively instantaneous value that is transmitted with a relatively small delay (for example, of the order of a second or several seconds) to load balancing modules 106 when the application health value changes.

Application load is a value that indicates how much the application is loaded or busy, and thus, directly or vice versa, how much additional load this application can handle. Application load is a relatively slowly varying or averaged value, which, if desired, can be smoothed out using the hysteresis excitation mechanism to eliminate the transient peaks of an increasing or decreasing load. It is transmitted to the load balancing modules 106 relatively rarely (for example, from one to four times per minute). The application load value makes sense in terms of application capacity.

Application Capacity is a value indicating the maximum application capacity. It is chosen in a general way so that it makes sense for a given context, but still is flexible enough for other contexts. Application capacity is a dimensionless quantity having a limited range of values (for example, 0-99) that can be determined during setup. It may depend on processing power, memory size / speed, network access, some combinations thereof, etc. Application capacity expresses the relative capacities between other applications of the same type in the host group 108 (1, 2, ..., n).

Thus, the load of the application makes sense in relation to the capacity of the application. Application load for a given application is the percentage of application capacity for a given application. Alternatively, the application load can be expressed as a dimensionless value, from which a percentage can be obtained using the application capacity value.

The load balancer directive 1302 (C) contains information reflecting the desired and / or expected state of the directive established by the health infrastructure 1202 and the load for load balancing modules 106 with respect to the application 316 to which element 1302 is associated. The load balancer directive 1302 (C) contains the following for corresponding application 316: target load balancing state and current load balancing state.

The target load balancing state reflects the state of the directive for load balancing modules 106 in accordance with the health and load infrastructure 1202. The current load balancing state reflects that the health and load infrastructure 1202 understands what the current state of the directive for the load balancing modules 106 should be written to the load balancing modules 106. The current load balancing state thus reflects the load balancing directive that the health and load infrastructure 1202 expects is currently being executed by load balancing modules 106 in accordance with the requirements of the communication protocol used. Such an illustrative communication protocol is described below with reference to FIG. The interaction and relationship between the target state of load balancing and the current state of load balancing are also further explained in the description of FIG.

The target load balancing state, like the current load balancing state, can take the values “active”, “inactive” or “depleting”. The “active” directive indicates that new requests / connections may arrive and be sent to the application associated with element 1302. The “inactive” directive indicates that no additional packets should be forwarded to the corresponding application. The dwindling directive indicates that no packets for new requests / connections should be sent to the corresponding application, but packets of existing requests / connections should continue to be forwarded to the corresponding application.

In the described implementation, the final version of the corresponding health and load information 1206 is stored in the health and load tables 1204 located on each respective host 108 of the multiple hosts 108. In this implementation, if the host 108 breaks down, the health and load information 1206 that is lost refers to to those applications 316, which are also destroyed. Thus, a high degree of reliability is achieved automatically without duplication of data. However, the final version of the health and load information 1206 may alternatively be stored elsewhere. Other such storage options include load balancing modules 106 themselves, host 108, which (as a standalone task or in conjunction with hosting tasks) stores and maintains health and load information 1206 for multiple other (including all others) hosts 108, other separate and / or external devices, etc.

If the final version of the health and load information 1206 is stored and maintained elsewhere, in addition to being distributed between the hosts 108 (1, 2, ..., n), then such health and load information 1206 may be redundant (for example, also stored in backup device, backed up, etc.) in order to increase reliability. Illustrative proxy scenarios for storing health and load information 1206 are described below with reference to FIG. 17A and 17B. 17A depicts a proxy scenario for health and load tables 1204, and FIG. 17B depicts a proxy scenario for combined health and load caches.

FIG. 13B depicts the combined health and load cache 1208 indicated in FIG. In the described implementation, each combined health and load cache 1208 in each load balancing module 106 contains at least a portion of the information stored in each health and load table 1204 for each health and load infrastructure 1202 for each host 108. Cached health and load information can be organized in any way in the combined cache 1208 health and load.

It is shown that the combined health and load cache 1208 contains a cache for each host 108 (1), 108 (2), ..., 108 (n), which partially or completely duplicates the information of the health and load table 1204 of each corresponding host 108 (1, 2 , ..., n). In particular, the combined health and load cache 1208 contains a cache for host number 1 1304 (1), a cache for host number 2 1304 (2), ..., a cache for host number n 1304 (n). Thus, the illustrated unified cache of health and load 1208 is organized at a broad level by host 108 (1, 2, ..., n), with each individual cache 1304 containing application-specific elements for the corresponding host 108 (1, 2, ..., n ) Alternatively, the combined health and load cache 1208 can be organized at a broad level as application 316 with separate blocks aimed at a specific type of application, further divided by host 108 (1, 2, ..., n). Other data structure formats may also be used.

On Fig shows a logical block diagram of a method of balancing network load using health information and load. Logical block diagram 1400 contains eight blocks 1402-1416. Although the actions indicated in the logical flowchart 1400 can be carried out in other environments and through various software circuits, FIG. 1-3 and 12-13B are used, in particular, to illustrate certain aspects and examples of the method. For example, the actions of two blocks 1402-1404 are performed by the host 108, and the actions of six blocks 1406-1416 are performed by the load balancing module 106.

At block 1402, health information and host load information is determined. For example, the health and load infrastructure 1202 (2) can receive health and load information 1206 for applications 316 (2) and store it in a table 1204 (2) on the host 108 (2). At block 1404, certain health and load information is sown to load balancing modules. For example, health and load infrastructure 1202 (2) can send health and load information 1206 for applications 316 (2) to load balancing modules 106 (1, 2, ..., u). Arrow 1418 indicates that the actions of blocks 1402 and 1404 are repeated, which allows you to continuously monitor the health and load (applications) and update them when changes occur.

At block 1406, health and load information is received from the hosts. For example, load balancing module 106 (1) may receive health and load information 1206 from multiple hosts 108 (1, 2, ..., n), which contains health and load information 1206 for applications 316 (2) of host 108 (2). At block 1408, the received health and load information is cached. For example, load balancing module 106 (1) may store health and load information 1206 from hosts 108 (1, 2, ..., n) in a combined health and load cache 1208 (1). According to the implementation of the combined health and load cache 1208 (1) shown in FIG. 13B, the health and load information 1206 for applications 316 (2) from the host 108 (2) can be stored in the cache 1304 (2) for the host No. 2. Arrow 1420 indicates that the actions of blocks 1406 and 1408 are repeated, which allows you to continuously monitor the health and load (applications) and update them when changes occur.

The dashed arrow 1422 indicates that load balancing modules 106 also process transmissions from clients 102, while processing health and load information. At block 1410, a packet is received requesting a new connection. For example, load balancing module 106 (1) may receive a TCP SYN packet from client 102 (2) over network 104. At block 1412, it checks against the cached health and load information. For example, load balancing module 106 (1) may check against the combined health and load cache 1208 (1). In particular, load balancing module 106 (1) can check against elements associated with the application to which the SYN TCP packet is addressed by caches 1304 (1, 2, ..., n) for hosts No. 1, No. 2, ..., No. n.

At block 1414, a host is selected in accordance with the cached health and load information. For example, load balancing module 106 (1) may select a host 108 (2) having application (s) 316 (2) in accordance with health and load information 1206 cached in the combined health and load cache 1208 (1). The selected application 316 (and host 108) must be functional and able to take on additional load (for example, if possible, the least loaded application among applications of the type of application to which the TCP SYN packet is addressed).

Reconciliation with cached health and load information (at block 1412) and host selection in accordance with the cached health and load information (at block 1414) can be performed before receiving a specific request packet for a new connection and / or using a group scheme. In addition, the selection can be made in accordance with any of numerous schemes. For example, you can use marker or circular patterns. In any design, the choice may include weighting the relative loads among the application options. These reconciliation and selection, together with marker and pie circuits, are described below with reference to FIG. 18 in the section entitled “Classification, Forwarding and Routing of Requests”, especially in connection with the classification functions.

After selecting the destination host at block 1414, you can send a packet request a new connection to it. At block 1416, a packet received from the client is forwarded to the selected host. For example, a TCP SYN packet is forwarded from load balancing module 106 (1) to a selected host 108 (2). Forwarding of this initial packet can be done directly by the classifier 304 or the forwarding unit 302, which is also described below in the section entitled “Classification, Forwarding and Routing of Requests”.

In the implementation described, the health and load infrastructure 1202 is hosted on multiple hosts 108 and distributed between them, and also hosted on load balancing modules 106 (as represented by the health and load handler 314). Health and load infrastructure 1202 has three functions. First, it opens the listening point (s) to receive application status updates for characteristics 1302 (B) of the application status of the health and load tables 1204. Secondly, it synthesizes application status information to determine what load balancing modules 106 should do, as embodied in load balancer directive 1302 (C). Third, the health and load infrastructure 1202 passes this directive from hosts 108 to load balancing modules 106.

The directory content of load balancer directive 1302 (C) is an efficiently classified version of the information for application status characteristics 1302 (B). However, load balancing modules 106 may also receive raw information about application status characteristics 1302 (B), as well as this processed directive. The contents of these and other fields of the health and load tables 1204 are transmitted using the messaging protocol, which is described below with reference to FIG.

FIG. 15 illustrates a messaging protocol 1500 for transmissions related to health and load information indicated in FIG. 12 between hosts 108 and load balancing modules 106. In the general case, an event-driven mechanism is used to transfer changes to the health and load tables 1204 from hosts 108 to load balancing modules 106. In other words, for the described implementation, information is transmitted from hosts 108 to load balancing modules 106 when updating health and load tables 1204. This avoids sending snapshots of all health and load tables 1204 and thus reduces network bandwidth consumption by the health and load infrastructure 1202.

The messaging protocol 1500 may be implemented using the existing messaging engine. Such mechanisms include a robust broadcast mechanism, point-to-point transmission (e.g., user datagram protocol (UDP)), etc. It is shown that the messaging protocol 1500 contains seven types of messages 1502-1514: a pulse message 1502, a goodbye message 1504, a row change message 1506, a receive snapshot of a table message 1508, a send snapshot of a table message 1510 ", Message 1512" postulate the state of the table "and message 1514" postulate the error ".

It should be understood that, with the exception of arrows 1516 and 1518, this illustration does not establish any time relationship between the different types of messages 1502-1514. For example, a 150 line change message 1506 is not required to follow a goodbye message 1504.

A heartbeat message 1502 indicates that a specific host 108 is operational, and provides some error control for the contents of the corresponding health and load table 1204 with respect to the corresponding specific cache for a specific host 1304 in the combined health and load cache 1208. Each health and load infrastructure 1202 on each host 108 sends a heartbeat message, directly or indirectly, to each health and load cache 1208 on each load balancing module 106.

Pulse messages 1502 solve the problem of data obsolescence in the combined health and load caches 1208, which occurs, in part, because a snapshot of the entire health and load table 1204 is not periodically transmitted to each load balancing module 106. A heartbeat message transmission scheme 1502 is described below with reference to FIG.

Pulse messages 1502 include an identifier for a host, error control data, and optionally a DNS name. The host ID can be a unique (32-bit) binary number selected during setup. The error control data may be a checksum, a state change sequence number, a generation number, a CRC value, etc., which allows the host load balancer 106 to verify that the contents of its combined health and load cache 1208 are consistent with the contents of the health table 1204 and load of the transmitting host 108. In the case of using the generation number, multiple generation IDs can be used, and each generation ID is assigned to a “piece” of applications. Then the messages can refer to a piece number or a pair of piece number / generation ID, depending on the context.

The error control data (or, more generally, the content indicator) may represent a single value for the entire health and load table 1204, or may be multiple values defined for each element 1302. The DNS name may optionally be transmitted (for example, every " x "heartbeat") to check or update the current correct host network address.

A goodbye message 1504 is sent from a specific host 108 to load balancing modules 106 to indicate that a particular host 108 is scheduled to shut down. A goodbye message 1504 includes a host identifier that can be indexed / mapped to a network address for a specific host 108. A “goodbye” message 1504 is used for clean, intentional outages by the hosts 108 to cause a “quick clean up”. However, in the event of a loss of goodbye message 1504, the caches ultimately lag behind the elements of a particular host 108, because heartbeat messages 1502 are no longer transmitted.

A line change message 1506 is transmitted from a specific host 108 to load balancing modules 106 to indicate that the health and load of a given application 316 of a particular host 108 has changed. The line change message 1506 includes a host identifier, an application identifier, an operation, and data for the operation. Illustrative host identifiers are described above in connection with heartbeat messages 1502 and goodbye messages 1504. The illustrated application identifiers are described above in connection with the application identifier 1302 (A) in the application related item 1302, health and load tables 1204.

A line change operation may be an addition, deletion, or update. In other words, data for an operation can be added (for an addition operation) or replaced (for an update operation) with information already present in the combined health and load caches 1208 on the load balancing modules 106. No data is provided for the delete operation. The messaging protocol 1500 is defined such that multiple operations can be provided for a single “row change” message 1506. Therefore, for a particular host identifier, sets of the application identifier, operation, and operation data may be repeated for multiple applications 316 of the host 108 identified by the specific host identifier.

A “receive snapshot of the table” message 1508 is sent from a specific load balancing module 106 for a specific combined health cache and load 1208 on a separate host 108 or hosts 108. This “receive snapshot of the table” message 1508 requests health and load infrastructure 1202 on the hosts 108 providing the appropriate health and load table 1204 for the corresponding host 108. This message includes the identification of the request load balancer 106 and may spolzovat load balancing unit 106 (i) after a failure and recovery; (ii) after host 108 experienced a failure, recovered, and again began sending heart rate messages 1502; (iii) if a “row change” message 1506 is sent to the load balancer 106 but the message is lost, resulting in a desynchronization between the health and load cache 1208 and the corresponding health and load table 1204 for the corresponding host 108; and (iv) etc.

For case (iii), loss of synchronization between the health and load cache 1208 and the corresponding health and load table 1204 for the corresponding host 108 is detected by a subsequent heartbeat message 1502 from the corresponding host 108, because the “error control” indicates that the combined health cache 1208 and load outdated. Then, the load balancing module 106 sends a “receive snapshot of the table” message 1508, which allows it to update its combined health and load cache 1208. Thus, in any of the three illustrative cases (i, ii, iii), the load balancing module 106 subsequently restores its combined health and load cache 1208 using the “receive snapshot of the table” message 1508. The 1508 “receive snapshot of the table” message may be sent multiple times to each host 108 in point-to-point mode, or may be sent once to multiple hosts 108 in broadcast mode.

A “send snapshot of the table” message 1510 is sent from a separate host 108 to a specific load balancer 106 after a separate host 108 receives a “receive snapshot of a table” message 1508 from a specific load balancer 106, as indicated by arrow 1516. Message Content 1510 “Send a snapshot of the table” is prepared by the health and load infrastructure 1202 and may include all or at least multiple rows of the health and load table 1204 for separate hosts 108, which allows a specific load balancing module 106 to recover its combined health and load cache 1208. The “send snapshot of the table” message 1510 may be a separately constructed message, or it may be equivalent to the sequence of operations added in the “row change” message 1506.

Message 1512 "postulate the state of the table" and message 1514 "postulate the error" refer to the target state of load balancing and the current state of load balancing directive 1302 (C) of the load balancer element 1302 of the table 1204 health and load. The target load balancing state is a directive according to which load balancing modules 106 should operate according to the desire of the health and load infrastructure 1202. The current state of load balancing is a directive according to which load balancing modules 106 are currently operating according to the expectation of the health and load infrastructure 1202. In general, the two load balancing states are identical.

However, the target load balancing state may differ from the current load balancing state during the transition period of the state directive. Let, for example, the target load balancing state and the current load balancing state be initially set active. If a problem is detected with the host 108 and / or its application 316, the load balancing state directive changes to “dwindling”. This dwindling directive is passed to load balancing modules 106 using the line change message 1506.

While this change in directive will be noted in all the combined health and load caches 1208 of all load balancing modules 106, there is a delay. During this transition period, the target load balancing state is “depleting,” while the current load balancing state is still “active” in host health and load table 1204 108. Before the current load balancing state changes to “depleting”, infrastructure 1202 health and workloads wants to make sure that the combined health and load caches 1208 have indeed been updated to a new “depleted” directory state.

In order to verify that the combined health and load caches 1208 of the load balancing modules 106 have been updated in accordance with the new state directive, the health and load infrastructure 1202 sends a "postulate table state" message 1512 to the load balancing modules 106. Message 1512 "postulate the state of the table" is transmitted after some time (for example, with a predetermined delay period) after the transmission of the message 1506 "row change", indicating that the status directive should change. In this example, the message “postulate table state” 1512 indicates that the state of the table should be “depleted”. The dashed arrow 1518 indicates that the load balancer 106 responds to this “postulate table state” message 1512 if its combined health and load cache 1208 is different from the postulated state directive.

If the directive in the combined health and load cache 1208 does not differ from the postulated state directive, then the load balancing module 106 sends a “post error” message 1514 to the health and load infrastructure 1202 of host 108, which issued message 1512 “post table state”. Then, this health and load infrastructure 1202 periodically resends the “postulate table state” message 1512 until messages “postulate an error” 1514 no longer arrive from the combined health and load caches 1208. At this point, the health and load infrastructure 1202 sends a new row change message 1506 with a new load balancing state. In this sense, the combined health and load caches 1208 are the final determinants of the current load balancing state, and the health and load infrastructure 1202 is the final determinant of the target load balancing state.

FIG. 16 shows a message flow diagram for the transmissions shown in FIG. 12 between hosts 108 and load balancing modules 106. An exemplary messaging scheme may reduce the bandwidth consumed by heartbeat messages 1502 on the communication medium 1210. The messaging circuit shown in FIG. 16 is specifically adapted to heartbeat messages 1502, but can be used for other messages of the messaging protocol 1500.

Multiple hosts 108 (1), 108 (2), 108 (3), ..., 108 (11) and 108 (12) are shown in conjunction with load balancing modules 106 (1), 106 (2), ..., 106 (u) . Each line represents a relationship between members or membership of a host group 108 (1, 2, ..., 12). The host group 108 (1, 2, ..., 12) forms a plurality of nodes that work together to distribute the pulse information to the load balancing modules 106. Although twelve hosts are shown, each given group of hosts can include more or less hosts. In addition, a complete group of hosts 108 served by load balancing infrastructure 106 can be divided into one, two, three, or more host groups.

In the described implementation, the nodes included in the host group 108 (1, 2, ..., 12) select a leader who is responsible for sending a pulse message 1502 to the load balancing modules 106. Each (non-leading) host 108 from the group of hosts 108 (1, 2, ..., 12) sends its messages 1502 "pulse" to the selected leader. In this example, the selected leader is host 108 (4).

The pulse information of each host 108 from the group of hosts 108 (1, 2, ..., 12), through the member nodes, is distributed to the leading host 108 (4) of the group. The host 108 (4) collects the information of the "pulse" and combines it in the combined message 1602 "pulse". The combined pulse messages 1602 (1), 1602 (2), ..., 1602 (u) are sent to the corresponding modules 106 (1), 106 (2), ..., 106 (u). These combined heartbeat messages 1602 may optionally be compressed to further reduce bandwidth consumption.

As another alternative, the leading host 108 (4) can only forward group composition changes to the combined health and load caches 1208. In other words, in this mode, the combined health and load caches 1208 deal mainly, if not exclusively, with state changes with respect to ownership. The leading host 108 (4) is designed to guarantee the forwarding of the first greeting when the host 108 is communicating, and sending a goodbye message 1504 when the host 108 is disconnected. Additionally, the host 108 may periodically indicate the need to “forward” the heartbeat message 1502. Thus, the leading host 108 (4) receives an order to send it to the combined health and load caches 1208, even if it does not express a change of ownership.

Heartbeat messages 1502 (including combined heartbeat messages 1602) are used by load balancing modules 106 when their combined health and load caches 1208 are out of sync with health and load tables 1204. This desynchronization may occur, for example, due to damage or other malfunction of the combined health and load cache 1208 and / or load balancing module 106. As described above, each heartbeat message 1502 contains error control data that is generated to verify equivalence between the combined health and load cache 1208 and the health and load tables 1204. In the event of unequality with respect to a particular host 108 and / or its application 316, the DNS name of the specific host 108 is retrieved from the heartbeat message 1502.

The combined health and load cache 1208 uses the DNS name to send a 1508 "receive snapshot of the table" message to a specific host 108 in order to receive updated health and load information 1206 in the form of a "send snapshot of the table" message 1510. Another or the same 1508 “receive snapshot of the table” message is sent to each host 108 for which nonequivalence is detected. In the end, the health and load information 1206 in the combined health and load cache 1208 is equivalent to the health and load information 1206 in the health and load tables 1204, which is verified by new heartbeat messages 1502. Thus, the operation of the failed cache 1208 health and load can be restored without external intervention using the protocol 1500 messaging and control circuit equivalence.

17A and 17B depict scenarios for storing health and load information on an intermediary for health and load tables 1204 and for combined health and load caches 1208, respectively. In the implementations described above with reference to FIGS. 12-16, hosts 108 comprise a health and load infrastructure 1202. However, in other implementations, the hosts may not contain the health and load infrastructure 1202.

For example, the host may have version of the application (s) and / or an operating system for which the health and load infrastructure is either not implemented or, for policy reasons, is not installed on the host. As a result, the health and load infrastructure 1202 is not running on these types of hosts. The host 1702 is such a host on which the health and load infrastructure 1202 is not running. However, host 1702 may utilize the health and load infrastructure 1202 that runs on one or more intermediaries, such as intermediary 1704.

At an intermediary 1704, health and load infrastructure 1202 is hosted and executed, including a health and load table 1204. The host 712 can utilize the functionality of the health and load infrastructure 1202 by presenting the health and load information 1206 to a table 1204. For applications running on the host 1702. Alternatively, the broker 1704 can output the health and load on the host 1702 by performing external tracking actions. Mediator 1704 is shown as mediator 1704 (1) and 1704 (2) for redundancy and, therefore, high reliability.

In the implementations described above with reference to FIGS. 12-16 and below with reference to FIG. 8, load balancing is performed using load balancing modules 106 containing the combined health and load caches 1208. However, other implementations may include load balancing without using the combined health and load caches 1208.

For example, load balancing can be performed using monolithic load balancing equipment or other load balancing infrastructure that does not store and / or cannot store or otherwise does not contain a combined health and load cache 1208. The load balancer 1706 reflects such load balancing device or devices that do not have a combined health and load cache 1208. However, load balancer 1706 may utilize a combined health and load cache 1208 existing on one or more intermediaries, such as intermediary 1708.

Mediator 1708 contains a combined health and load cache 1208 that stores health and load information 1206 for hosted applications served by load balancer 1706. The load balancer 1706 can use the health and load information 1206 of the combined health and load cache 1208 when performing load balancing functions by accessing such information using the application program interfaces (native) for the load balancer 1706 and supported by it. Alternatively, the combined health and load cache 1208 may invoke an API to transmit health and load information 1206, including directives, to load balancer 1706. The mediator 1708 is shown as the mediator 1708 (1) and 1708 (2) of redundancy and, therefore, high reliability.

On Fig shows the distribution process of the target endpoints of the application using the classifier 304 and the processor 314 health and load, which are part of the module 106 load balancing. After the health and load handler 314 gains access to the combined health and load cache 1208, the health and load information 1206 contained therein is used to select application endpoints for new requests / connections.

As described above with reference to FIG. 13B, the combined health and load cache 1208 contains cached health and load information 1206 for multiple hosts 108. To facilitate the creation and updating of the combined health and load cache 1208 based on the health and load information 1206 received from the multiple hosts 108, the health and load information 1206 is organized therein so that it is accessible by the identifier of each host 108. However, the health and load information 1206 is also it is organized in such a way that it is accessible by application type 316 in order to facilitate the selection of the application endpoint.

In other words, the health and load processor 314 is able to access health and load information 1206 for each application 316 individually from the health and load information 1206 for multiple hosts 108. After receiving the health and load information 1206 for this application 316 for each host 108, the incoming connection requests may be in accordance with this health and load information 1206. For example, possible endpoints for a given application 316 can be allocated to incoming connection requests by selecting the endpoints of this application 316, taking into account the available relative load capacity among operational endpoints for this application 316.

In the described implementation, the classifier 304 makes a request 1802 distribution of the target endpoints of the application processor 314 health and load. It is shown that the request 1802 distribution of the target endpoints of the application contains (i) a virtual IP address and port, (ii) the protocol and (iii) information associated with the protocol. Therefore, the application target distribution endpoint distribution request 1802 identifies the type of application 316 to which incoming connection requests are addressed.

The health and load processor 314 receives a request 1802 for distributing the application target endpoints and selects at least one physical endpoint corresponding to the identified type of application 316 using any one or more of a variety of selection mechanisms. To reduce latency, the health and load handler 314 selects the endpoint distribution to be used for a number of incoming connection requests. This distribution comes from the processor 314 health and load on the classifier 304 using the response 1804 on the distribution of the endpoints of the application. It is shown that the response 1804 on the distribution of application endpoints contains a distribution of physical IP addresses and ports (for example, endpoints IP1, IP2 and IP3) for the identified application type 316.

Response 1804 on the distribution of application endpoints may be performed using one or more distribution schemes. For example, a marker distribution scheme 1806 and a percentage distribution scheme 1808 are shown. Marker distribution scheme 1806 is a modular allocation scheme, and percentage distribution scheme 1808 is a temporary distribution scheme.

Marker distribution scheme 1806 allocates markers for each operable endpoint IP1, IP2, and IP3 according to their relative load and capacity ratios. In the illustrated example, of the total available capacity, IP1 has 40% of the available capacity, IP2 has 35% of the available capacity, and IP3 has 25% of the available capacity. Thus, the total number of markers is divided according to these percentages. The total number of tokens may be provided as part of a request 1802 for distributing application target endpoints, or determined by a health and load handler 314.

You can use any value of the total number of markers, for example 10, 45, 100, 250, 637, 1000, etc. This value can be set depending on the number of connection requests per second and the speed / frequency of changes in the health and / or load of the application. Classifier 304 “spends” / consumes one token, responding to each connection request when allocating application endpoints until the tokens run out; then, the classifier 304 requests another marker distribution using the application target distribution endpoint query 1802.

Percentage distribution scheme 1808 determines available relative capacity in a similar manner. However, instead of tokens, these specific available relative capacities per application endpoint are provided to classifier 304 in conjunction with a timer 1810 of duration. Classifier 304 allocates target application endpoints to incoming connection requests in accordance with these available percentages of relative capacity before the timer 1810 expires.

According to the percentage distribution scheme 1808, the classifier 304 maintains a continuous record of the endpoint allocations of the application to join the distributed percentages and tracks the duration timer 1810. At the end of time, the classifier 304 requests another percentage distribution using a request 1802 distribution of the target endpoints of the application.

Note that marker distribution scheme 1806 may also use a time limit. If the distributed markers are too old, you can discard them and get new ones. Otherwise, classifier 304 may consume stale tokens that were previously allocated based on health information and load, which is currently too outdated. The use of classifier 304 application endpoint distributions is described below in the section entitled “Classification, Forwarding, and Routing of Requests”.

Session Tracking

This section describes how host status information, such as session information, can be collected and used to balance network load. In this section, the links go mainly to FIGS. 19-24 and the functions of maintaining affinity for the session, for example, provided by the session tracking unit 308 (FIG. 3), are highlighted. As described above with reference to FIGS. 1-3, each host 108 hosts one or more applications 316 that provide service (s) to clients 102. Session tracking unit 308 uses session information related to contexts for connections established between applications 316 and clients 102 for certain described network load balancing implementations.

19 shows an approach to balancing network load using session information 1902. Connection [1] means that client 102 (1) creates a new connection with host 108 (2) through load balancing infrastructure 106. The load balancing infrastructure 106 may consist of one or more load balancing modules 106. When a connection request arrives at the load balancing infrastructure 106, the request is usually routed to the host 108 using network load balancing functions in accordance with the health and / or load information of the hosts 108 and / or their applications 316 (not explicitly shown in FIG. 19).

When a connection is established [1] between the client 102 (1) and the serving application 316, which in this example is hosted on the host 108 (2), a session is established. A session provides a context for two-way communication between client 102 (1) and host 108 (2). Session context information is stored on host 108 (2). Upon completion of connection [1], the session context may not be reused. On the other hand, a session context may again be useful if client 102 (1) attempts to initiate another connection with hosts 108 for services provided by application 316. If this other connection is not routed to the same host 108 (2) where this context is stored session, then the client 102 (1) has to establish a new session context, which may require time consuming, large amounts of data / processing and / or upset the human user of the client 102 (1). When balancing the network load based on the health and / or load information, the probability that the second connection will be routed to 108 (2) will be no more than a random chance.

If the load balancing infrastructure 106 has access to the mapping between the session information and the hosts 108, then the load balancing infrastructure 106 can route connection requests related to previously established sessions to the corresponding host 108. Some session information can be derived from the contents of packets carried through the infrastructure 106 load balancing. However, this approach is inaccurate and unfocused for a number of reasons. Firstly, the establishment and termination of the session is only assumed. Secondly, some sessions do not end “officially” with the proper indication included in the package. For example, some sessions simply pause. Thirdly, packets transmitted from the host 108 (2) to the client 102 (1) can travel along a path that does not include the load balancing infrastructure 106, which prevents the load balancing infrastructure 106 from monitoring such packets for session information.

As shown in FIG. 19, hosts 108 provide session (IC) information 1902 to load balancing infrastructure 106. Using session information 1902 from hosts 108, affinity storage session 1904 can maintain affinity between the established session and the host 108 on which the session was established. Session information 1902 includes a connection or mapping between each session established between client 102 and a specific host 108 and that particular host 108. This display is available to session affinity storage unit 1904 as part of the host information display 1906. More specific examples of session information 1902 are provided below, especially with reference to FIG. 20, 22, 23A and 23B.

In certain described session tracking implementations, the logical nature of clients 102 is appropriate. According to the above with reference to figure 1, the client 102 may be a specific device and / or a specific user of the device. Therefore, the affinity for the session for the user client 102, which accesses the hosts 108 from various devices, can still be maintained. Therefore, continuation of sessions using the information of 1902 sessions can still be carried out in intermediary scenarios (for example, as with some Internet service providers (ISPs)).

According to connection example [1], a session established on host 108 (2) is provided to load balancing infrastructure 106 as session information 1902. In particular, a connection / mapping between (i) the client session context 102 (1) and the host 108 (2) and (ii) the identifier for the host 108 (2) are created on the host-session information display 1906. When a connection request is subsequently received for the connection [2] for the same session context, the affinity for the session unit 1904 places this session context in the display 1906 of the host information of the session and finds out that the host 108 (2) is connected to the session context from the connection / display .

In accordance with the mapping of the host 108 (2) to the requested session context, detected by the affinity block 1904 for the session from the host-session information display 1906, the connection [2] is routed to the host 108 (2). In this sense, maintaining affinity for a session has a higher priority for load balancing infrastructure 106 than solutions for balancing network load based on application health and load. However, uptime and load can be a more important factor in balancing network load than session tracking, for example, in the case of extremely high load or failure of the session-related application and / or host.

Many types of connections can be associated with a session. Examples include: TCP connection, Transport Layer Security (TLS) / SSL session, PPTP session, IPSec / L2TP session, ISA session, HTTP cookie-based session, terminal server session, administrator-defined session, etc. d. For clarity, a TCP connection is considered as a TCP packet session. In addition, an administrator-defined session setting model can be listed and supported. In addition, client IP-based sessions delimited by downtime can also be supported. This is a relatively dumb session support, but is expected by some users.

The connection request from client 102 varies in the type of session needed. For example, for sessions of the TCP Connection type, the connection request contains a TCP packet. For SSL session type sessions, the connection request contains a TCP connection. Other such connection requests correspond to other types of session. These examples also show what session levels might be. At the lower level of the session, the session context for a TCP connection may include an ordered four TCP, session number, number of transmitted / received bits, etc. At a higher session level, the session context for the SSL session may include a 32-bit session ID, the public key of the client 102 provided to the host 108, etc.

FIG. 20 shows an illustrative approach to network load balancing using the transmission of session information through notifications 2006 and messages 2008. Multiple load balancing modules 106 (1), 106 (2), ..., 106 (u) and multiple hosts 108 (1 are shown. ), 108 (2), ..., 108 (n). Each respective host 108 (1), 108 (2), ..., 108 (n) includes one or more respective applications 316 (1), 316 (2), ..., 316 (n) hosted and executed on it. Notifications 2006 are used to provide session information from applications 316, and messages 2008 are used to provide session information from hosts 108 to load balancing modules 106.

It is shown that each corresponding host 108 (1), 108 (2), ..., 108 (n) contains the infrastructure 2002 (1), 2002 (2), ..., 2002 (n) session tracking (IOS). Each corresponding session tracking infrastructure 2002 (1), 2002 (2), ..., 2002 (n) contains a corresponding table of 2014 (1), 2014 (2), ..., 2014 (n) sessions (although only explicitly shown in FIG. 19 one table 2014 (1) sessions).

Each corresponding load balancing module 106 (1), 106 (2), ..., 106 (u) contains a corresponding function 2012 (1), 2012 (2), ..., 2012 (u) traffic routing (MTF). The traffic routing function 2012 may comprise, for example, a routing classification and / or query function, for example, provided by a classifier 304 and a request router 306, respectively. Distributed by modules 106 (1), 106 (2), ..., 106 (u) is the distributed session tracking manager 2010.

In the described implementation, the traffic routing function 2012 and the distributed session tracking manager 2010 are part of the load balancing infrastructure 106. Session tracking infrastructure 2002 may also be (e.g., remote) part of load balancing infrastructure 106.

API 2004 is used to provide session information from applications 316 to the session tracking infrastructure 2002. Using API 2004 allows applications 316 to communicate session tracking infrastructure 2002 with session information, including various changes to it. In particular, each application 316 is capable of issuing, and the session tracking infrastructure 2002 is capable of receiving notifications 2006.

When you re-establish or open a session, application 316 issues a session setup notification (or session establishment notification 2006 (E)). The session establishment notification 2006 (E) contains a session identifier and, optionally, an application identifier 316. When a session ends or closes, an application 316 issues a session end notification (or a session end notification 2006 (T)). The end of session notification 2006 (T) also contains a session identifier and, optionally, an application identifier 316.

Upon receiving the session establishment notification 2006 (E), the session tracking infrastructure 2002 inserts an element for a new session into the session table 2014. An example session table 2014 is described below with reference to FIG. Upon receiving the session end notification 2006 (T), the session tracking infrastructure 2002 removes an item from the session table 2014 for the old session.

Session table 2014 (1) is the official source of 1902 session information regarding applications 316 (1) on host 108 (1). However, when requesting the function 2012 of routing traffic to the contact with hosts 108 to access the session tables 2014 upon receipt of each incoming connection request having a session reference, there is too much delay. Therefore, session information 1902 is cached on load balancing units 106.

On load balancing modules 106, the distributed session tracking manager 2010 caches session information 1902, which is part of its responsibility for managing session tracking. In general, the distributed session tracking manager 2010 is a distributed application and / or virtual service hosted partially on each load balancer 106. For each logical session, the distributed session tracking manager 2010 stores at least one cached copy of the session information for it in a reliable and scalable manner that can be quickly used to route traffic when incoming connection requests that have a link to the session to the load balancing infrastructure 106 .

Communication between hosts 108 and load balancing modules 106 is accomplished using a reliable protocol that ensures that messages 2008 sent from host 108 arrive at the desired load balancing module 106. Each host 108 is associated with at least one specific load balancing module 106, which is a designated load balancing module 106 for messages 2008. This binding is created by assigning the IP address of a specific load balancing module 106 to each host 108 for sending session tracking messages 2008 between the session tracking infrastructure 2002 and the distributed session tracking manager 2010. To improve the reliability of the load balancing infrastructure in the event of a failure of the load balancing module 106, another load balancing module 106 assumes the IP address of the failed load balancing module 106. Failure detection for accepting an IP address can be done using a heartbeat or other health monitoring scheme.

Thus, messages 2008 transfer session information 1902 from the session tracking infrastructure 2002 to the distributed session tracking manager 2010. For example, when the session tracking infrastructure 2002 receives a session establishment notification 2006 (E), it also sends a session start message 2008 (U) to the distributed session tracking manager 2010. The session start message 2008 (U) contains a session identifier, a host identifier, and optionally other information. The contents of the session start message 2008 (U) are described below with reference to FIG. 23B with respect to information that can be stored for each session by implementing the distributed session tracking manager 2010. When the session tracking infrastructure 2002 receives the session end notification 2006 (T), it also sends a session end message 2008 (D) to the distributed session tracking manager 2010. Message passing 2008 can occur before, during, or after the session tracking infrastructure 2002 has appropriately modified the session table 2014 in accordance with the 2006 notices.

FIG. 21 is a flow chart 2100 of a method for balancing network load using the transmission of session information through notifications and messages. Logical block diagram 2100 contains fifteen blocks 2102-2130. Although the actions of the logic flowchart 2100 can be carried out in other environments and using various other software schemes, FIG. 1-3 and 19-20 are used, in particular, to illustrate certain aspects and examples of the method.

For example, the actions of the four blocks 2102-2104 and 2118-2120 are performed by the application 316, the actions of the six blocks 2106-2110 and 2122-2126 are performed by the session tracking infrastructure 2002, and the actions of the five blocks 2112-2116 and 2128-2130 are performed by the distributed session tracking manager 2010. The actions of eight of these blocks 2102-2116 are mainly aimed at opening a session, and the actions of seven of these blocks 2118-2130 are mainly aimed at closing a session.

At block 2102, a session is opened. For example, application 316 may open a session with client 102. At block 2104, a session establishment notification is provided. For example, application 316 may provide session notification 2006 (E) to session tracking infrastructure 2002 using API 2004 as a result of opening and / or sharing a session.

At block 2106, a session establishment notification is received. For example, session tracking infrastructure 2002 may receive a session establishment notification 2006 (E) from application 316 in accordance with API 2004. At block 2108, an element is inserted into the session table. For example, Session Tracking Infrastructure 2002 may insert an item into a session table 2014 for an open session. Examples of such an insertion are described below, in particular with reference to figa. At block 2110, a session start message is sent. For example, session tracking infrastructure 2002 may send a session start message 2008 (U) to the distributed session tracking manager 2010 using a reliable communication protocol.

At block 2112, a session start message is received. For example, the distributed session tracking manager 2010 may receive a session start message 2008 (U) from the session tracking infrastructure 2002 in accordance with a reliable communication protocol. At block 2114, a session information item is created. For example, the distributed session tracking manager 2010 may create a session information item for cached session information 1902 on one or more load balancing units 106. Examples of such creation and subsequent addition are described below, in particular with reference to FIG. 22 and 23B.

At block 2116, network traffic is routed using session information. For example, the traffic routing function 2012, in conjunction with the distributed session tracking manager 2010, can use the cached session information 1902, including the generated session information item, to route incoming connection requests that have a session link. An example of such traffic routing is described below, in particular with reference to FIG. Additional examples are described below in the section entitled “Classification, Forwarding, and Routing of Requests”.

At block 2118, the session is closed. For example, application 316 may close the session with client 102. At block 2120, a session end notification is provided. For example, application 316 may provide a 2006 (T) end of session notification to session tracking infrastructure 2002 using API 2004 as a result of and / or in conjunction with a session closing.

At block 2120, a session end notification is received. For example, Session Tracking Infrastructure 2002 may receive a 2006 (T) session end notification from application 316 in accordance with API 2004. At block 2124, an item is deleted from the session table. For example, the session tracking infrastructure 2002 may remove an item from the session table 2014 for a closed session. At block 2126, a session end message is sent. For example, the session tracking infrastructure 2002 may send a session end message 2008 (D) to the distributed session tracking manager 2010 using a reliable communication protocol.

At block 2128, a session end message is received. For example, the distributed session tracking manager 2010 may receive a session end message 2008 (D) from the session tracking infrastructure 2002 in accordance with a reliable communication protocol. At block 2130, the session information item is destroyed. For example, the distributed session tracking manager 2010 may destroy a session information item in cached session information 1902 on any load balancing units 106 having a session information item. Examples of such destruction and subsequent removal are described below, in particular with reference to FIGS. 22 and 23B.

22 shows an approach to managing session information on multiple load balancing modules 106. Each corresponding load balancing module 106 (1), 106 (2), ..., 106 (u) contains the corresponding portion 2202 (1), 2202 (2), ..., 2202 (u) of the distributed atomic atom manager 220 (RDA). RDA 2202 is an illustrative implementation of the distributed session tracking manager 2010. Each corresponding part of the RDA 2202 (1), 2202 (2), ..., 2202 (u) contains the corresponding part 2206 (1), 2206 (2), ..., 2206 (u) of the table RDA (TRDA) 2206.

RDA 2202 is a distributed application or virtual service that manages session information 1902 in a reliable and scalable manner that allows the traffic routing function 2012 to use it to maintain affinity for the session. For example, the traffic routing function 2012 may access the RDA 2202 using an API (not specifically shown) to search in the RDA 2206. The function calls 2204, operation of the RDA 2202 and other aspects of FIG. 22 are described below after describing FIG. 23A and 23B.

On figa shows a table 2014 sessions indicated in Fig.20. The 2014 session table contains the “v” of elements 2302 (1), 2302 (2), ..., 2302 (v). Each element 2302 is inserted by the session tracking infrastructure 2002 in accordance with the session establishment notification 2006 (E) received from application 316. Each element 2302 is deleted by the session tracking infrastructure 2002 in accordance with the session end notification 2006 (T) received from application 316.

As described above, each session establishment notification 2006 (E) contains a session identifier and, optionally, an application identifier 316. Each corresponding element 2302 (1), 2302 (2), ..., 2302 (v) of the 2014 session table contains corresponding field (i) of the identifier 2302 (1I), 2302 (2I), ..., 2302 (vI) of the session and (ii) the type of session and / or application 2302 (1T), 2302 (2T), ..., 2302 (vT).

The session type and / or application 2302 (T) may be “TCP”, “IPSEC”, “Terminal Server”, “HTTP cookie”, application type, as noted above, etc. Session ID 2302 (I) may be "<source IP address, source TCP port, destination IP address, destination TCP port>", "Client IP = 172.30.189.122", "User = 'joe_user'", "Cookie = '{b7595cc9-e68b-4eb0-9bfl-bb717b31d447}'", another, for example, the session identifier associated with the application, etc. For TCP connection / session types, session identifier 2302 (I) may, alternatively, be a canonical version of the ordered TCP four (for IPv4 or IPv6). Alternatively, other values may also be used for the fields of the session identifier 2302 (I) and application / session type 2302 (T).

On figv shows a table 2206 (TRDA) distributed dispatcher (RDA) of atoms, indicated in Fig.22. The RDA table 2206 contains the “w” of elements 2304 (1), 2304 (2), ..., 2304 (w). Each session information element 2304 is created by the RDA 2202 in accordance with the session start message 2008 (U) received from the session tracking infrastructure 2002. Each session information element 2304 is destroyed in accordance with the session end message 2008 (D) received from the session tracking infrastructure 2002. As described below, the session information elements 2304 from the RDA tables 2206 can actually be controlled by the RDA 2202 using function calls 2204.

As described above, the session start message 2008 (U) contains a session identifier, a host identifier, and, optionally, other information. Each corresponding element 2304 (1), 2304 (2), ..., 2304 (w) of the session information in the table 2206 of the RDA contains the corresponding fields (i) of the key 2304 (1K), 2304 (2K), ..., 2304 (wK), ( ii) data 2304 (1D), 2304 (2D), ..., 2304 (wD) and (iii) metadata 2304 (1M), 2304 (2M), ..., 2304 (wM). For example, the values of the key fields 2304 (K) may be alphanumeric strings, and the values of the data fields 2304 (D) may be bits. Key values 2304 (K) may also be bits.

Key 2304 (K) may correspond to session identifier 2302 (I). Data 2304 (D) may correspond to a host identifier, for example, the network address of a host 108 on which a session context exists. Metadata 2304 (M) may correspond to other, optional, information. An example of such metadata 2304 (M) is the data internally used by the RDA 2202 to resolve atomic conflicts and track the health of atoms (for example, through a suspension mechanism). (This presentation of 2304 elements as atomic is described in more detail in the next paragraph.) In particular, metadata 2304 (M) includes, among other things, the identification of an entity (object) (for example, an instance of the 2012 traffic routing function), adding a session information element 2304 to table 2206 RDA.

In the described implementation, each session information element 2304 is atomic in the sense that RDA 2202 can add, delete, copy, etc. elements 2304 as a whole, but RDA 2202 usually does not change part of any element 2304 as a whole. Thus, atomic elements 2304 are added, deleted, copied, otherwise processed, etc. according to the tables 2206 RDA through RDA 2202 for the implementation of reliability and scalability for the implementation of maintaining affinity for the session.

Functional calls 2204 (FIG. 22) are used by the RDA 2202 to manipulate the atomic elements 2304 of the RDA table 2206. Functional calls 2204 may come from one load balancing module 106 to one or more load balancing modules 106 in point-to-point or broadcast mode. These functional challenges include “add atom” 2204 (A), “remove atom” 2204 (D), “request atom” 2204 (Q), and “return atom” 2204 (R).

“Add atom” 2204 (A) has the form AddAtom (key, data) and is used to add atomic element 2304 to one or more tables 2206. Therefore, the functional call “add atom” 2204 (A) can be expressed as AddAtom (<session identifier> Host IP address). "Delete Atom" 2204 (D) has the form DeleteAtom (key) and is used to remove the atomic element 2304 from one or more tables 2206 RDA. Functional calls “remove atom" 2204 (D) can be directed to those tables 2206 RDA, about which it is known that they have a copy of the session identified by key 2304 (K), or can be sent to all tables 2206 RDA, which can guarantee the removal of any copies.

“Request Atom” 2204 (Q) has the form QueryAtom (key) and is used by a specific part of the RDA or a specific part of the RDA 2206 or a specific part of the RDA 2202 when the session identifier referenced by the incoming connection request. Functional requests "request atom" 2204 (Q) are sent to one or more (possibly all) other parts of the 2202 RDA. In response, each RDA part 2202 checks its local RDA table 2206 for a key / session identifier. If the key is detected by the other part of the RDA 2202, then this other part of the RDA 2202 responds by “return the atom” 2204 (R).

“Return atom” 2204 (R) has the form ReturnAtom (key, data) and is used to answer the functional call “request atom” 2204 (Q). The atom return function calls 2204 (R) are used when part of the RDA 2202 has the requested atomic element 2304 in its local RDA table 2206, identified by the key 2304 (K) indicated in the request atom atom function call 2204 (Q). Functional calls "return atom" 2204 (R) can be directed back to the part of the RDA 2202, which issued a functional call "request atom" 2204 (Q).

The “add atom” functional calls 2204 (A) are used in response to a session start message 2008 (U) and / or to duplicate an atomic element 2304 to one or more other RDA tables 2206. Such duplication can be performed for redundancy and / or scalability.

The “remove atom” function calls 2204 (D) are used in response to the 2008 (D) session end messages and can also be sent to one or more RDA tables 2206. After the removal of the atomic element 2304, the atomic element 2304 can enter the “zombie” state, in which it remains in the RDA 2202 and, optionally, is still stored in the RDA table 2206 with the zombie pointer in the metadata field 2304 (M) of the atomic item 2304.

Thus, after the removal of the atomic element 2304, it can remain in the RDA 2202 and the RDA table 2206 in the “zombie” state, as a result of which packets for this (now idle and closed) session are sent to the session context host 108 for an appropriate, depending on the protocol processing. For example, TCP packets received after a TCP connection has been resolved are routed to host 108, which terminated the connection. This host 108 may appropriately respond — perhaps by sending an RST or by sending a FIN-ACK again. The time that the atomic element 2304 spends in this “zombie” state coincides (as accurately as possible) with the protocol-specific downtime for the reliable communication protocol used.

The atomic request function call 2204 (Q) is used to access atomic element 2304 when the first load balancer 106 receives an incoming connection request that refers to a session that is not stored in the local RDA table 2206 for the RDA 2202 of the first load balancer 106. Note that other parts of the RDA 2202 can be simultaneously requested via the broadcast request “request atom” 2204 (Q) function or sequentially until a positive return “atom” 2204 (R) function call is received.

The atom return function call 2204 (R) is used by the RDA part 2202 of the second load balancing module 106 to provide the atomic element 2304 of the RDA 2202 of the first load balancing module 106 when the atomic element 2304 has a key 2304 (K) specified by the session key / identifier in the function call "request atom" 2204 (Q), previously issued part of the RDA 2202 of the first module 106 load balancing. Note that other components, for example, the traffic routing function 2012, may also use function calls 2204, in particular the “request atom” function call 2204 (Q), in accordance with an API or the like.

Parts of the RDA 2202 and tables 2206 of the RDA can be organized and administered in various ways. The illustrated methods relate to duplication / redundancy, local caching upon receipt, hashing for location selection, etc. You can use zero, first, second or higher level of duplication up to complete duplication. At a zero level of duplication, each atomic element 2304 is stored in the RDA 2202, receiving the message 2008 (U) of the beginning of the session for him, without duplication in other parts of the RDA 2202.

At the first duplication level, each atomic element 2304 is stored in the RDA 2202, receiving a session start message 2008 (U) for it, and is also added (copied) to another part of the RDA 2202 using the “add atom” function call 2204 (A). This allows one level of failure to be dealt with for load balancing module 106. Similarly, at the second level of duplication, each atomic element 2304 is stored in the RDA 2202, receiving the message 2008 (U) of the beginning of the session for him, and is also added to the other two parts of the RDA 2202. In general, one, two, etc. parts of the RDA 2202 into which this part of the RDA 2202 copies atomic elements 2304 are predetermined or arbitrarily selected. You can also apply the third, fourth, etc. duplication levels.

In addition, you can use full duplication, in which each atomic element 2304, which is stored on the RDA 2202, receiving message 2008 (U) of the beginning of the session, is also added to each other part of the RDA 2202. Several factors influence the choice of the level of duplication. As the level of duplication increases, reliability increases and latency decreases. Network traffic and memory usage, on the other hand, increase with increasing duplication.

When full duplication is not used, local caching is possible after receipt. For example, when the part of the RDA 2202 does not detect the identifier of the session referred to by the link in its part of the table 2206 of the RDA, the part of the RDA 2202 issues a request atom request 2204 (Q) to gain access to the atomic element 2304 associated with the session identifier referenced by reference through a function call "return atom" 2204 (R). Instead of discarding the atomic element 2304 after its use, the part of the RDA 2202 caches the received atomic element 2304 in its part of the table 2206 of the RDA. This option allows you to choose between the above factors.

Another option in the absence of full duplication may be to hash the location. The first atomic element 2304 for the session is stored in the part of the RD 2202, which receives the message 2008 (U) of the beginning of the session. The duplicated copy or copies are sent via the function call “add atom” 2204 (A) to the specific part (s) of the RDA 2202 using a hash function. Of the many possible hash values of each part of the RDA 2202, a subset thereof is assigned. Each session identifier is hashed using some hash function to obtain a hash value. This hash value is mapped to the assigned parts of the RDA 2202. The part of the RDA 2202, which first added the atomic element 2304, then duplicates the atomic element 2304 in the assigned part (s) of the RDA 2202.

Due to hashing for location selection, at least one part of the RDA 2202, which locally cached the desired atomic element 2304 in its RDA table 2206, is accessible by session identifier. Therefore, the “request atom” functional call 2204 (Q) can be routed to a known part (s) of the RDA 2202. This typically reduces network traffic and / or delay.

This hash to select a location can be used at the first, second, third or more levels of duplication, with each range of hash values mapped to one, two, three, etc. different parts of the RDA 2202, respectively. Additionally, hashing for location selection can be used in conjunction with local caching upon receipt.

24 is a flowchart 2400 of a method for managing session information on multiple load balancing modules. The logical block diagram 2400 contains eight blocks 2402-2416. Although the actions of the logical flowchart 2400 can be carried out in other environments and using various software circuits, FIG. 1-3, 19, 20, 22 and 23B are used, in particular, to illustrate certain aspects and examples of the method.

At block 2402, an incoming connection request is analyzed with reference to the session. For example, traffic routing function 2012 may receive an incoming connection request that refers to a previously opened / established session of a certain type. At block 2404, a search is performed in the local RDA table using the session link. For example, for the data of the load balancing module 106 and the traffic routing function 2012, a part of the RDA 2202 may search in its corresponding RDA table 2206 by reference to the session.

At block 2406, a determination is made whether the link to the session matches the key of the local RDA table. For example, part of the RDA 2202 may search the key fields 2304 (K) of the plurality of elements 2304 of the RDA table 2206 to determine if the link to the session matches any values of the key fields 2304 (K). If so, then logic flow diagram 2400 proceeds to block 2412.

If the link to the session does not coincide with any key, then the logical block diagram 2400 proceeds to block 2408. At block 2408, a functional call is made to “request an atom”. For example, part of the RDA 2202 may make a functional request “request atom” 2204 (Q) containing, as a key, a link to the session / session identifier. The “request atom” function call 2204 (Q) can be sent to at least one other part of the RDA 2202. Number, selection, order, etc. the possible parts of the destination RDA 2202 for “request atom” 2204 (Q) may depend on the options (eg, duplication level, hashing for location selection, local caching upon receipt, point-to-point / broadcast mode, etc.) used in RDA 2202.

At block 2410, the returned atom is received. For example, information can be received from the “return atom” function call 2204 (R) issued by another part of the RDA 2202. Another part of the RDA 2202 has successfully detected the atomic element 2304 in its corresponding RDA table 2206, the detected atomic element 2304 having a key matching link to the session. The information from the “return atom” function call 2204 (R) contains the values from the key field 2304 (K) and the data field 2304 (D) for the detected atomic element 2304. These values correspond to the session identifier for the session and the network address of host 108, which has an affinity to the session.

At block 2412, an atomic element is extracted. The atomic element is retrieved from the local RDA table if a match is found locally (at blocks 2404 and 2406), or from the returned atom, if a match is found elsewhere (at blocks 2408 and 2410). For example, the atomic element 2304 can be retrieved from the RDA table 2206 of the RDA portion 2202 or from information obtained through the “return atom” function call 2204 (R). The extracted atomic element 2304 can be cached in the local RDA table 2206 if it is received as a result of the “return atom” function call 2204 (R).

At block 2414, a host having an affinity for the session referred to by the link is identified from the atomic element. For example, the value of the data field 2304 (D) of the extracted atomic element 2304 can be found in order to thereby find out the network address of the host 108 having an affinity for the session. At block 2416, the incoming connection request is routed to the identified host, for example, the traffic routing function 2012 and / or the forwarding function can route the incoming connection request having a session link to the identified host 108 having an affinity for the session. The following section describes illustrative classification, query routing, and forwarding functions.

Request classification, forwarding and routing

This section describes how traffic routing can be implemented to balance network load, including with regard to the high reliability of such a traffic routing function. The traffic routing function may include a classification and / or routing request function, especially in connection with a forwarding function. In this section, the links go mainly to FIGS. 25-31. It highlights the function of the request router 306 (FIG. 3), the relationship between session tracking and the use of health and load information when routing traffic, operational implementations of traffic routing interactions with session information and / or health and load information, failover procedures for high reliability of the alignment infrastructure network load (including handling failures of classification components, forwarding and / or routing requests), additional configurations, and Network load balancing infrastructure, etc.

25 shows a network load balancing infrastructure having a request routing function implemented by a request router 306 (H / S). As noted above with reference to the traffic routing function 2012, traffic routing can be based on classification (e.g., forwarding) and / or routing request. The classification at the packet level, together with the forwarding, is described above, in particular with reference to FIG. Request routing is described here, in particular with reference to FIG.

Request-level routing occurs at a higher level than packet-level routing. In general, the request router 306 acts as an intermediary for the application 316 running on the host 108. The request router 306 terminates the TCP connections, analyzes (possibly partially) each request from the client 102, and redirects each request to the host 108. The request router 306 can Perform preprocessing on the connection, such as SSL decryption. In addition, the query router 306 may choose to absorb certain requests (for example, the query router supports a response cache) and may optionally modify the requests before forwarding them to hosts 108.

Request routers 306 are typically application dependent and can be quite extensible in terms of what they can do. Exclusively by way of example, in the following description, a single class of request routers 306 is considered - HTTP / SSL request routers 306 (H / S). It is shown that the client 102 having the network address C1 is connected over the network 104 with the hosts 108 (1) and 108 (2) having the network addresses H1 and H2, respectively. The communication is through a load balancing infrastructure that includes an HTTP / SSL request router 306 (H / S).

Router 306 (H / S) of HTTP / SSL requests terminates HTTP and SSL traffic, decrypts SSL traffic, checks each HTTP request from client 102, applies application-specific rules to classify each request and to determine the “best” endpoint for this request, at the same time, given the health and load information of the application endpoint, it sends a request to the endpoint. To submit a request to the endpoint, a separate TCP connection is used, different from that initiated by the client 102 (the last connection ends on the HTTP / SSL request router 306 (H / S)). These actions can be considered as logically equivalent to the actions performed by the classifier 304, but with the difference that these actions in the router 306 (H / S) of HTTP / SSL requests are carried out at the level of logical requests for each request in the TCP connection. The HTTP / SSL request router 306 (H / S) and, in general, the request routers 306 can use the same infrastructure (i) health and load and (ii) session tracking that are used by classifiers 304.

The HTTP / SSL request router 306 (H / S) acts as an intermediary between the client 102 and the two hosts 108 (1) and 108 (2). It processes two requests from client 102 over a single TCP connection. In the described implementation, the final routing of requests involves a series of actions. First, the client 102 establishes an HTTP or HTTPS connection [1] with the HTTP / SSL request router 306 (H / S) and sends a request No. 1 2502 (1).

Secondly, the HTTP / SSL request router 306 (H / S) ends the SSL session (if the traffic is encrypted using SSL), analyzes the request No. 1 2502 (1) and checks the contents of the request No. 1 2502 (1). Based on the health and load information, as well as the session, the HTTP / SSL request router 306 (H / S) determines that host 108 (1) is the “best” host for this particular request # 1 2502 (1) in this example.

Third, the HTTP / SSL request router 306 (H / S) establishes a secondary TCP connection [2] with the host 108 (1). This secondary TCP connection does not originate from the VIP address on network 104; instead, it comes from an address (not shown in FIG. 25) that is allocated to the request router 306 (H / S) to ensure that responses 2504 from the host (s) 108 come to the proper request router 306. (There may be several operational request routers 306, although in FIG. 25, for simplicity, one request router 306 (H / S) is shown.) Alternatively, you can use the existing connection [2] with host 108 (1). Then, the HTTP / SSL request router 306 (H / S) sends, for example, an unencrypted version of request No. 2502 (1) to host 108 (1). Fourthly, the host 108 (1) responds with a response No. 1 of 2504 (1). Fifth, the HTTP / SSL request router 306 (H / S) encrypts this response No. 1 2504 (1) and sends it back to client 102 over a TCP connection [1].

Sixth, client 102 sends another request, request No. 2 2502 (2). Request No. 2 2502 (2) is processed similarly to request No. 1 2502 (1) except that the router 306 (H / S) of the HTTP / SSL requests selects the host 108 (2). The reason for another choice may be that the host 108 (1) is currently in an idle state or is overloaded, because the request No. 2 2502 (2) was sent to a different URL than the request No. 1 2502 (1), etc. . One way or another, the HTTP / SSL request router 306 (H / S) establishes a different secondary TCP connection, but this secondary TCP connection [3] is established with host 108 (2). Unencrypted request No. 2 2502 (2) is routed to the host 108 (2), and, as a result, the response No. 2 2504 (2) comes from there. Then, the encrypted version of the response No. 2 2504 (2) is sent to the client 102 from the router 306 (H / S) HTTP / SSL requests.

Seventh, client 102 closes the TCP connection [1] with the HTTP / SSL request router 306 (H / S). Router 306 (H / S) of HTTP / SSL requests (at some point in the future) closes the connections [2] and [3] established with hosts 108 (1) and 108 (2), respectively, from client side 102. TCP- connection [2] can alternatively be closed after router 306 (H / S) of HTTP / SSL requests decides to open / use TCP connection [3] for request No. 2 2502 (2).

Since the HTTP / SSL request router 306 (H / S) ends the HTTP / HTTPS connection, the HTTP / SSL request router 306 (H / S) can not only route the requests. For example, the HTTP / SSL request router 306 (H / S) can, in principle, support its own response cache (for example, using an out-of-band mechanism to invalidate the cache). As noted in the above example, the HTTP / SSL request router 306 (H / S) can also, in principle, route other types of requests to other groups of hosts 108 based on, for example, the requested URL. Again, the HTTP / SSL request router 306 (H / S) can, in principle, aggregate requests from multiple short-lived client connections and send them over a few long-lived TCP connections to hosts 108. Such aggregation of connections can reduce the overhead of processing connections on hosts 108.

Request routers of other classes may conform to illustrative protocols other than HTTP. For example, a request router may be a SOAP request router. The SOAP request router acts similarly to the HTTP / SSL request router 306 (H / S). However, the SOAP request router is designed specifically for routing SOAP traffic. SOAP request routers understand SOAP headers and make routing decisions based on SOAP headers, as well as application health and load.

Classification and forwarding of the packet level (or routing of the packet level) and routing of the query level can provide some kind of level 7 load balancing. The level 7 load balancing is described below in the section entitled “Transferring connections with optional tunneling and / or load balancing at the application level”. Packet-level routing provides read-only access to the initial portion of the client’s TCP connection data, and query-level routing provides read-only access to the entire data stream.

Packet-level routing has several advantages over query-level routing. These benefits include transparency (client packets are delivered to the hosts in their original form, preserving the IP addresses and port numbers of the source and destination), low processing overhead (in general, traffic forwarding involves searching for a route), low latency (individual packets are forwarded, and packets are not queued after determining the destination of the TCP connection) and high reliability (in general, a failure on the forwarding unit does not stop the TCP connection). On the other hand, query-level routing usually has the following advantages over packet-level routing: the ability to check the entire data stream going to and from the client, and the ability to transform the data stream and even split the data stream between multiple hosts or aggregate data streams from multiple clients .

FIG. 26 shows a flow chart 2600 of an incoming packet routing method in accordance with (i) session information and (ii) health and load information. The logical block diagram 2600 contains eight blocks 2602-2616. Although the actions of the logical flowchart 2600 can be carried out in other environments and using various software circuits, FIG. 1-3, 12, 18-20, 22 and 23B are used, in particular, to illustrate certain aspects and examples of the method.

At block 2602, an incoming packet is received. For example, a packet from client 102 may arrive at forwarding unit 302 of load balancing module 106. At block 2604, a determination is made whether the received packet belongs to an existing session. For example, forwarding unit 302 may check the local RDA table 2206 () to determine that the received packet is already part of a TCP / IP session.

In addition, forwarding unit 302 may check the local RDA table 2206 () and determine that the received packet is no longer part of the TCP / IP session. In this case, the forwarding unit 302 submits the received packet to the classifier 304, which checks the affinity for the session at a higher level for the received packet, if it has a reference to the session. Examples of such actions are described above, in particular with reference to FIG. 24, and below, in particular with reference to FIG. 27 and 28.

If the received packet refers to an existing session (which is determined at block 2604), then proceed to block 2606. At block 2606, a host is found that has an affinity for an existing session. For example, a host 108 having an affinity for a session can be detected from a local RDA table 2206 () and / or a shared distributed RDA table 2206 by a forwarding unit 302 or classifier 304.

At block 2608, a determination is made whether a host that has an affinity for the session is operational. For example, classifier 304 may check the combined health and load cache 1208 to determine if host 108 has an affinity for a session, especially for received packets that are part of sessions that are at a higher logical level than TCP sessions / IP. The action (s) of this block can be implemented in conjunction with the processor 314 health and load.

If the host with the affinity for the session is operational (as determined at block 2608), then the process proceeds to block 2610. At block 2610, the received packet is routed to the host with the affinity for the session. For example, forwarder 302 (for TCP / IP sessions) or a classifier 304 (for higher-level sessions) can route the packet to host 108, which has an affinity for the session. In an alternative implementation, the classifier 304 may return the received packet to the forwarder 302 for routing to the host 108 having an affinity for the session, even for received packets that are part of higher-level sessions.

If the host with the affinity for the session is down (which is determined at block 2608), then the transition to block 2612 occurs. In addition, if, on the other hand, the received packet does not belong to an existing session (which is determined at block 2604), this proceeds to 2612. At block 2612, a host is selected in accordance with the health and load information. For example, the classifier 304 may select the host 108 from and / or using the distribution for the application based on the health and load (for example, from the response 1804 on the distribution of the target endpoints of the application) received from the health and load handler 314. Examples of these actions are described above, in particular with reference to FIG. 19 and 18, and below, in particular with reference to FIG.

At block 2614, the received packet is routed to the selected host. For example, classifier 304 may route (optionally, through forwarding block 302) a packet to a selected host 108. At block 2616, a route is laid for the connection path to the selected host. For example, the classifier 304 may add a session information element to the RDA table 2206, in particular to the RDA table 2206 (), which is local to the forwarding unit 302 that transmitted the received packet to the classifier 304. This session information element can be duplicated in accordance with an established redundancy policy for RDA 2202 (e.g., session tracking unit 308).

The actions of block 2614 and 2616 can be carried out in the order shown, when block 2616 is executed before block 2614, when the actions partially or completely overlap in any order, etc. Note that the above actions performed by the classifier 304 may alternatively be performed by the request router 306 (or, in general, the traffic routing function 2012).

In addition to routing at the packet level and at the request level, the traffic routing function described here (for example, the traffic routing function 2012, the request router 306, the pair of forwarder 302 / classifier 304, etc.) can also be used to implement the firewall function. Therefore, the traffic routing function may include a traffic blocking feature instead of automatically routing the traffic to the proper host 108. For example, the classifier 304 can inspect the traffic and interrupt it if it seems unsafe.

On Fig shows the sequence of actions for routing traffic in the absence of failures. It is shown that in front of the rest of the load balancing infrastructure 106 (not shown separately), there are one or more switches 202 (LBA) that are aware of load balancing. Forwarding and classification functions are distributed across three devices or nodes. The first device comprises a forwarder 302 (1) and a classifier 304 (1). The second device contains a classifier 304 (2). The third device comprises a forwarder 302 (2).

Using the classifier 304 (2) running on the second device and the forwarding unit 302 (2) running on the third device, each device can be specifically configured for its respective functions. For example, hardware, software, hardware and software, some combinations thereof, etc. the second device and the third device can be adapted to support the desired functions without attracting additional funds. Thus, the third device containing the forwarding unit 302 (2) may be akin to a switch and / or router in its hardware capabilities, and the second device containing the classifier 304 (2) may look more like a server and / or Personal Computer.

Although three devices are shown that provide functionality across four components, alternative logical and / or hardware configurations for forwarding and classification functions are applicable to the illustrated traffic routing sequence shown in FIG. 27. Furthermore, although routing destinations are shown as hosts 108, the routing implementations described here can alternatively be applied, in general, to the next destination node for the packet and not necessarily to the final node consuming the packet.

An implementation of the RDA 2202 of the session tracking unit 308 is used to implement the RDA table 2206. However, session affinity conservation blocks 1904 are also generally applicable to the exemplary traffic routing sequence shown in FIG. 27. Forwarding unit 302 (1) comprises an RDA table part 2206 (1), and a forwarding unit 302 (2) comprises an RDA table part 2206 (2). Incoming packets are routed to host 108 (1) or host 108 (2).

In the described implementation, the RDA 2202 is a distributed, stored in memory, table of “atoms” 2304 (for example, keyword / value pairs, with optional metadata) having session information. RDA 2202 and RDA table 2206 are described above, in particular with reference to FIGS. 22-24. Any node in the classifier group 304 can add, query, and delete atoms 2304. RDA 2202 maintains a highly reliable RDA table 2206, which contains information about existing routers (for example, TCP / IP level), as well as higher-level sessions. Examples of higher level sessions include: TLS / SSL session, PPTP session, IPSec / L2TP session, ISA session, HTTP cookie-based session, etc. In addition, the RDA 2202 may include session information elements in the RDA table 2206 that relate to other sessions not associated with TCP / IP, for example, RTF, UDP, etc.

Position (1) indicates that the switches 202 (LBA), aware of load balancing, direct the incoming packet to block 302 (1) forwarding. Position (2) indicates that block 302 (1) is checking against its internal routing table, table 2206 (1) RDA. When the forwarder 302 (1) does not find the atomic element 2304 for this packet, it forwards the packet to the assigned and / or associated classifier, classifier 304 (1).

Position (3) indicates that the classifier 304 (1) recognizes that the packet in this example is the first packet of a new session (for example, the SYN packet for a TCP connection). Therefore, classifier 304 (1) processes the packet as the beginning of a new TCP connection from client 102. Using health and load information from health and load handler 314 (not shown explicitly), classifier 304 (1) determines that host 108 (1) must take this session.

Classifier 304 (1) updates the RDA table 2206 (1), which serves as the local routing table for the forwarder 302 (1), and also inserts the atomic element 2304 representing the route into the RDA common table 2206. These can be separate operations, a single operation in which sessions of the TCP / IP level of the RDA table 2206 are located on forwarding units 302, etc. RDA 2202 internally duplicates this route into one or more members of the classifier 304 group in accordance with its agreed redundancy policy. Classifier 304 (1) may optionally contact the host 108 (1) to confirm the creation of a new session before updating the table 2206 (1) RDA block 302 (1) forwarding and general RDA 2202 / table 2206 RDA.

Position (4) indicates that the forwarding unit 302 (1) directly forwards subsequent packets for this connection to host 108 (1) without interacting with classifier 304 (1). RDA 2202 can be used to mask, at least in part, the failure of the forwarder 302, classifier 304, or forwarder / classifier pair 302/304. RDA 2202 can also be used, at least in part, to maintain client connectivity if the switches 202 (LBA), aware of load balancing, randomly start transmitting packets for the established connection to another forwarder 302.

On Fig shows the sequence of actions for routing traffic in the presence of failure (s). In contrast to the flow of traffic routing in the absence of failures shown in FIG. 27, FIG. 28 shows a failure that occurred in part of the network load balancing infrastructure 106 (not specifically indicated). In particular, the first device on which the forwarding unit 302 (1) and the classifier 304 (1) are located and operating, becomes inoperative after establishing the connection shown in FIG. 27. RDA 2202 at least partially masks this failure.

Position (1) indicates that the switches 202 (LBA), aware of load balancing, detect the failure of the forwarder 302 (1) and begin to transmit packets to connect to any other forwarder 302 in the group. In this example, another forwarding unit 302 is a forwarding unit 302 (2). Although a failure case is shown in FIG. 28, the LBAs 202 aware of load balancing can also direct this traffic to the forwarding unit 302 (2), even if the forwarding unit 302 (1) is still operational. This change of forwarding units 302, initiated in the absence of a failure, occurs, for example, because the switches 202 (LBA), aware of load balancing, do not retain the affinity of this traffic with the forwarding unit 302 (1). Any of several factors may cause the switches 202 (erroneously) to direct traffic to another (unrelated) forwarder 302. For example, traffic for the same higher-level session can flow to switches 202 from a different source IP address or source port when the source is on the other side of the proxy farm. The actions indicated by positions (2) - (5) are applied both in the event of failures and in the case of “incorrectly directed traffic”.

Position (2) indicates that the forwarding unit 302 (2) is checked against its routing table, RDA table 2206 (2). Not finding a route for this packet, it forwards this packet to its classifier 304 (2). Position (3) indicates that the classifier recognizes that this packet is a “mid-session” packet, and the classifier 304 (2) asks the RDA 2202 for the route for this packet. RDA 2202 responds via a route for connecting from its associated atomic element 2304.

Position (4) indicates that the classifier 304 (2) leads the route in block 302 (2) forwarding. The routing protocol is described below. Position (5) indicates that subsequent packets for this connection directed to the forwarder 302 (2) are routed directly to the proper host, which in this example is host 108 (1) without reconciling with classifier 304 (2).

In general, a routing protocol for communicating between classifiers 304 and forwarders 302 includes commands for adding and removing routes. In particular, the classifier 304 sends to the forwarder 302 a command to add a route to establish a route between the forwarder and host 108 for a given connection. For example, the classifier 304 (2) may send to the forwarding unit 302 (2) the add route command indicated at (4) in FIG. 28. The route (for example, the key and the corresponding value) is added to the local RDA table 2206 (2) for quick access to the forwarding unit 302 (2) in the future. In this example, the classifier 304 (2) is a device separate from the forwarding unit 302 (2), whereby the routing protocol may be a protocol between devices. However, the routing protocol can also be used for communication within the device.

In the described implementation, classifier 304 (2) contains a registry of 2802 compounds. Using the registry 2802 connections classifier 304 (2) tracks the sessions of any blocks 302 forwarding (for example, block 302 (2) forwarding), for which the classifier 304 (2) paves the way. In order for classifier 304 (2) to track connections, including terminations, forwarder 302 (2) forwards the final packets for sessions (e.g., TCP TCP packet) to classifier 304 (2). Then, the classifier 304 (2) removes the element that corresponds to the session from the connection registry 2802 and sends a route removal command to the forwarding unit 302 (2). Upon receiving the route deletion command, the forwarding unit 302 (2) deletes the corresponding route from the RDA table 2206 (2).

Thus, the classification function, together with the session tracking function, can manage the routing tables and their routes that are used by the forwarding function. Therefore, the transfer function, which is divided into another device, can be carried out using high-speed, but relatively simple equipment. Alternatively, classifiers 304 may rely on communication with hosts 108 rather than intercepted initial (or in addition to them) (e.g., SYN TCP) and final (e.g., FIN TCP) session packets to determine session durations. In other words, classifiers 304 may alternatively or additionally receive and use session 2008 (U / D) (start / end) messages described above in the section entitled “Session Tracking”.

On Fig shows additional procedures for overcoming failure to improve the reliability of the infrastructure 106 balancing network load. We describe the procedures for overcoming a failure for two different failures, failure 2902 and failure 2906. It is shown that the network load balancing infrastructure 106 (not specified separately) contains five components: transfer unit 302 (1), transfer unit 302 (2), unit 302 (3 ) forwarding, classifier 304 (1) and classifier 304 (2).

In the described implementation, each of these five components 302 (1), 302 (2), 302 (3), 304 (1) and 304 (2) corresponds to a separate device. However, similar or similar failover procedures can be applied to environments in which other load balancing components share devices. In addition, similar or similar failover procedures can be applied to environments that have different amounts, combinations, scales, etc. components.

Initially, according to [1], the router (s) / switch (s) 202 forward the incoming packet, which, as it turned out, refers to the new connection, to the forwarding unit 302 (1). Since the forwarder 302 (1) does not have a route for this connection in its local routing table, it sends the packet to the classifier 304 (1), which is indicated by the dotted double arrow indicated by (1). Classifier 304 (1) first checks the session information with reference to the session tracking unit 308 for possible affinity for a higher level session. In this example, the packet has no affinity for the existing session, therefore, the classifier 304 (1) selects the host 108 with reference to the health and load information with reference to the processor 314 health and load.

In particular, in this example, the classifier 304 (1) selects the host 108 (1). Assuming the packet belongs to a TCP / IP session, classifier 304 (1) adds this TCP / IP session bound to host 108 (1) to RDA 2202 using the add atom function call 2204 (A). Classifier 304 (1) or forwarder 302 (1) forwards the initial packet to host 108 (1). Classifier 304 (1) also routes in the local routing table of forwarder 302 (1). Forward packets, the forwarder 302 (1) forwards to the host 108 (1) without interacting with the classifier 304 (1).

At some point during the connection [1], the transfer unit 302 (1) fails. This 2902 failure is detected by the router (s) / switch (s) 202 (LBA) that are aware of load balancing. As a result, at point 2904, the router (s) / switch (s) 202 forward further packets that were to be forwarded to connection forwarding unit 302 (1) [1] to another forwarding unit 302, in this example, unit 302 (2) shipments.

Thus, the forwarding unit 302 (2) receives further packets over the connection [2]. Since the forwarding unit 302 (2) does not have an element in its local routing table for packets that were previously routed to the forwarding unit 302 (1), the forwarding unit 302 (2) directs the first received connection packet [2] to the classifier to which it is assigned / with which he is associated. In this example, the forwarding unit 302 (2) is assigned to the classifier 304 (2), as indicated by the dotted double arrow (2).

Classifier 304 (2) uses the "request atom" 2204 (Q) function call to retrieve an atomic element 2304 (not explicitly shown) from the RDA 2202, which is connected to an existing TCP / IP connection. This atomic element 2304 is provided through an RDA 2202 of the session tracking unit 308 via a “return atom” function call 2204 (R). Classifier 304 (2) retrieves host 108 (1), which has an affinity for this TCP / IP connection, from the returned atomic element 2304. Classifier 304 (2) forwards this first packet received for connection [2] to host 108 (1) and also routes in the local routing table of the forwarder 302 (2). Subsequent packets block 302 (2) forwarding forwards without interacting with the classifier 304 (2).

The above descriptions focus mainly on failures of the individual components of the forwarding unit 302. However, the components of classifier 304 may also fail. For example, at some point, 2906 fails on classifier 304 (2). Forwarding unit 302 (2) detects a failure 2906 when attempting to consume classification services or by notifying of the absence of some indication of operability, such as a pulse type indicator. To handle failure 2906, the forwarder 302 (2) is reassigned to or re-associated with another classifier 304, which in this example is classifier 304 (1). Classifier 304 (1) provides forwarding unit 302 (2) with additional classification functions as indicated by the dotted double arrow (3).

On Fig shows the operational implementation of the interaction of the routing of traffic with information health and load. Forwarder 302 and classifier 304 interact with a health and load handler 314 to route packets to hosts 108 (1), 108 (2), ..., 108 (n). Although the forwarder 302 and the classifier 304 are shown, the operational implementation is also applicable to the request router 306 (or, in general, to the traffic routing function 2012).

It is shown that host 108 (1) contains the application endpoints IP1, IP3, and IP4 for application No. 1 and application No. 2, respectively. The host 108 (2) contains the endpoints of the IP2 and IP6 applications for application No. 1 and application No. 2, respectively. The host 108 (n) contains the IP5 endpoint of the application for application No. 2. The health and load processor 314 monitors these hosts 108 (1), 108 (2), ..., 108 (n) and the application endpoints IP1, IP2, IP3, IP4, IP5 and IP6 (for example, using the health and load infrastructure 1202, unified cache 1208 health and load, etc.).

In the described implementation, (1) means that the classifier 304 requests one or more distributions of application endpoints (for example, by means of at least one query 1802 of distribution of application endpoints) in an environment where a token distribution scheme 1806 is used. The health and load handler 314 in this example responds by providing marker distributions 3002 (for example, through at least one response 1804 on the distribution of application endpoints).

In particular, the marker distribution for application No. 13002 (1) and the marker distribution for application No. 3002 (2) are available to classifier 304. The marker distribution for application No. 3002 (1) initially provides 40 tokens for IP1, 35 tokens for IP2 and 25 markers for IP3. Token distribution for application # 2 3002 (2) provides 10 tokens for IP4, 72 tokens for IP5 and 18 tokens for IP6. For each new connection to which classifier 304 has allocated routing to the application endpoint, classifier 304 consumes a token.

Position (2) indicates that the forwarding unit 302 receives the initial incoming packet for a new connection. Since there is no routing for this new connection in the local part of the RDA table 2206 of the forwarding unit 302, the forwarding unit 302 forwards the initial packet to the classifier 304, which is indicated by (3).

Position (4) indicates that the classifier 304 (for example, determining that the initial packet does not contain a session reference for a higher-level session) selects the application endpoint (and thus host 108) in accordance with the health and load information. In particular, for a new connection to be serviced by application No. 1, Classifier 304 may select any of IP1, IP2, and IP3 if the token for the corresponding endpoint still exists.

Classifier 304 may consume tokens in any of many possible ways. For example, classifier 304 may use a circular approach regardless of the number of markers per endpoint. Alternatively, according to the linear approach, Classifier 304 can simply start with IP1 and move through IP3, consuming all the markers for each endpoint, before moving on to the next endpoint. In addition, the classifier 304 can consume at any time a marker from the group of markers depending on the endpoint that currently has the largest number of markers. According to the latter approach, classifier 304 selects IP1. Other approaches can also be used.

Classifier 304 is shown to consume a token for the application's IP2 endpoint. Therefore, when a marker is consumed, the marker group for IP2 decreases from 35 tokens to 34 tokens. In addition, the initial packet for the new connection must be routed to the application's IP2 endpoint.

Position (5A) indicates the transfer of the initial packet from the classifier 304 to the application endpoint IP2 for the host 108 (2). Before, during or after this transfer, classifier 304, which is indicated by (5B), paves the route for this connection in the local part of the RDA table 2206. Classifier 304 may also add atomic element 304 for this session to RDA table 2206 for distribution and duplication. Position (6) indicates the forwarding of further packets for this connection / session from the forwarding unit 302 to the application endpoint IP2 for the host 108 (2) using the local routing table of the forwarding unit 302 implemented as the local part of the RDA table 2206 in FIG. 30.

On Fig shows the mechanisms for ensuring high reliability of the infrastructure 106 balancing network load. In particular, failure detection 3104, failure processing 3106, and error correction 3108 are shown. These high reliability mechanisms are described for various components of the network load balancing infrastructure 106. The components of the network load balancing infrastructure 106 include a forwarder 302, a classifier 304, a request router 306, a session tracking unit 308, and a health and load handler 314.

Reference numeral 3102 (A) indicates a local failure of the forwarding unit 302. Position 3104 (A) indicates that a failure has been detected by at least one switch that is aware of load balancing. To handle local fault 3102 (A), the switch, aware of load balancing, redirects packets to another forwarding block (s), which is indicated by 3106 (A). To correct the failure of the forwarding unit 302, the routes locally stored on the forwarding unit 302 are re-built, which is indicated by 3108 (A) on the forwarding unit (s) to which the packets are redirected using the distributed session tracking manager and its table, in particular, the RDA and its tables. Thus, a distributed session tracking manager can provide redundant data at one or more layers.

Reference numeral 3102 (B) indicates a local failure of classifier 304. Reference 3104 (B) indicates that a failure was detected by at least one forwarding unit. To handle local fault 3102 (B), the forwarder that detects the fault redirects packets to another classifier (s), which is indicated by 3106 (B). To correct the malfunction of the classifier 304, the session information locally stored on the classifier 304 is re-built, which is indicated by 3108 (B), on the classifier (s) to which packets are redirected using the RDA. This session information may be, for example, session information of a higher level than basic TCP / IP connections. In addition, this session information can be considered as part of the session tracking infrastructure hosted on the same device as the classifier 304.

Position 3102 (C) indicates a local failure of the router 306 requests. Reference numeral 3104 (C) indicates that a failure has been detected by at least one forwarder and / or switch that is aware of load balancing. To handle local fault 3102 (C), the forwarding unit and / or switch that is aware of load balancing redirects packets to the other request router (s), which is indicated by 3106 (C). The individual current logical queries that the query router 306 runs on after a local failure 3102 (C) occurs can be lost if each such separate logical query is duplicated while the request is being processed. To correct the failure of the request router 306, session information and / or routes locally stored on the request router 306 are re-built, which is indicated by 3108 (C) on the request router (s) to which packets are redirected (and thus new logical requests ) Reconstruction of the session information can be carried out using RDA. Again, such session information can be considered as part of a session tracking infrastructure hosted on the same device as the request router 306.

Reference numeral 3102 (D) indicates a local failure of the session tracking unit 308. Reference numeral 3104 (D) indicates that a failure has been detected by at least one forwarding unit and / or classifier. For example, if the session tracking unit 308 is located on the same device as the classifier, then a forwarding unit or other classifier may detect a failure. If the session tracking unit 308 is located on a separate device, then a classifier may detect the failure. To handle local fault 3102 (D), data redundancy of one or more levels and distribution across multiple devices are established for information from the monitored session, which is indicated 3106 (D). It should be noted that redundancy and distribution are set before failure 3102 (D). To correct the failure of the session tracking unit 308, the session information from the RDA tables can be redistributed and duplicated on at least two devices (if it is not already distributed and duplicated sufficiently), which is indicated by 3108 (D), for processing second level of failure.

Reference numeral 3102 (E) indicates a local failure of the health and load handler 314. Position 3104 (E) indicates that a failure was detected by at least one classifier and / or query router. For example, a failure can detect a component receiving health and load information from health and load handler 314 if the health and load handler 314 stops responding, especially if the health and load handler 314 is not located on the device where the requesting component is located. For processing a local fault 3102 (E), for the health and load information, the redundancy of the health and load data and the internal fault processing are used, which is indicated by 3106 (E).

For example, each health and load handler 314 may contain a combined health and load cache 1208 that duplicates information in the health and load tables 1204 on multiple hosts 108. In addition, consumers of the health and load information 1206 of this health and load handler 314 may reside on that volume. same device as the processor 314 health and load, as a result of which this failure will be internally valid. Similarly, the official version of the corresponding part of the health and load information 1206 is located on the corresponding host 108, because of which failure of the host 108 makes the loss of the corresponding part of the health and load information acceptable.

To correct a malfunction of the health and load handler 314, this network load balancing component that consumes health and load information may request a different health and load handler because each such health and load handler 314 contains a combined health and load handler information cache. In addition, when the health and load handler 314 becomes available again, the messaging protocol 1500, designated 3108 (E), can be used to rebuild its combined cache of health and load information. Using these illustrative high-reliability mechanisms, it is possible to detect, process, and correct the failed components of the network load balancing infrastructure 106 to mask such failures for clients 102.

Transferring connections with optional tunneling and / or load balancing at the application level

This section describes how connection manipulation, such as connection transfer, can be used to balance network load. In this section, the links go mainly to FIGS. 32-39 and the connection transfer function, for example, provided by the connection transfer unit 310 (FIG. 3), is described. As described above with reference to FIG. 3 and 4, each incoming connection to the load balancing infrastructure 106 may end there. After that, the connection can be transferred to the host 108, so that the connection then terminates on the host 108. The connection transfer unit 310 is capable of transferring the connections and can be partially hosted on the hosts 108 for transferring. Such transfer of connections can be done in conjunction with load balancing at the application level by classifier 304 and / or using tunneling through tunneling unit 312.

On Fig shows an approach to balancing network load at the application level with the transfer of connections. Load balancing at the application level or at level 7 is associated with decision making regarding the connection processing application. To perform application-level load balancing, load balancing infrastructure 106 typically takes into account a portion of the connection data. Until query routing is used, the classifier 304 usually reads the initial part of the connection, and then transfers the connection together with the connection transfer unit 310 to the selected host 108.

To balance the load at the application level in a TCP-based environment, in general, classifiers 304 read the initial portion of the client’s TCP data when deciding where to forward the client’s TCP connection. Thus, application-level logic validates client data and makes load balancing decisions based on that data. For example, if the connection is an (unencrypted) HTTP connection, then the classifier 304 can read the HTTP header of the first HTTP request in the connection and can make decisions based on some part of the header content (for example, URL, cookie, etc.). Although application-level load balancing, connection transfer, and tunneling are applicable to other protocols, the examples here use mainly TCP / IP.

The load balancing infrastructure 106 (not specifically specified) is shown to include a forwarder 302, a classifier 304, a tunneling unit 312, and a connection transfer unit 310 (and possibly, for example, routers / switches 202 (LBAs) that are aware of load balancing). Forwarder 302 corresponds to a virtual IP address and forwards packets to hosts 108 selected by classifier 304. Although this is not shown specifically in FIG. 32 for clarity, hosts 108 also include connection transfer function 310 and tunneling function 312.

In the described implementation, the forwarder 302, the classifier 304 and the connection transfer unit 310 (on the classifier 304 and on the hosts 108), together with the TCP protocol software on the classifier 304 and the hosts 108, act together to provide transfer of connections. The connection transfer shown in FIG. 32 refers to the connection from client 102 (1), which usually ends with classifier 304. After transferring the connection, the connection from client 102 (1) ends at host 108 (1). When the connection ends at the host 108 (1), packets for the connection can be tunneled using the tunneling unit 312 (at the forwarder 302 and the host 108 (1)).

Position (1) indicates that client 102 (1) sends a SYN packet to forwarding unit 302 to signal the start of a new TCP connection. Position (2) indicates that the forwarder 302 forwards this packet to classifier 304. Position (3) indicates that classifier 304 receives a TCP connection from host 108 (whose identifier is not yet known, the destination destination host 108 () has yet to be selected ) For TCP, the classifier 304 sends a SYN-ACK packet to client 102 (1).

Position (4) indicates that the client 102 (1) begins to transmit data. (The initial SYN packet may also contain data). Data is processed by classifier 304, which can be verified with specialized logic. Specialized logic may act depending on which host 108 is capable of processing, or what types of requests or connections are best processed. Therefore, the classifier 304 uses the data, as well as the health and load information of the application from the health and load handler 314, to determine the host 108 that is best or best suited to process this connection from the client 102 (1). In this example, host 108 (1) is selected.

Position (5) indicates that the classifier 304 sends a “blob” (“binary blob”) representing the state of the TCP connection to host 108 (1). This connection state is aggregated by the connection transfer unit 310 in cooperation with the TCP stack on the classifier 304. The binary blob contains the data from the client 102 (1), acknowledged by the classifier 304, and TCP parameters, for example, an ordered four TCP / IP, initial sequence numbers, etc. .

Position (6) indicates that the component of the connection transfer unit 310 on the host 108 (1) (not shown explicitly in Fig. 32) “inserts” this connection into the TCP stack on the host 108 (1) using the binary TCP connection status blob received from the classifier 304. This insertion of the connection state is carried out in cooperation with the TCP stack on the host 108 (1), as a result of which the applications 316 on the host 108 (1) think that this connection was initially accepted by the host 108 (1) itself. Client 102 (1) and applications 316 on host 108 (1) are not aware of the transfer of the connection.

Position (7) indicates that the classifier 304, in interaction with the TCP stack on the classifier 304, clears the internal state maintained for this connection. This purification of the internal state on the classifier 304 is carried out "silently", i.e. client 102 (1) is not notified of a reset of the connection state. Classifier 304 also adds a route to the local routing table of the forwarder 302, which indicates that host 108 (1) is the destination for packets of this connection.

Position (8) indicates that subsequent packets for connection are routed by forwarding unit 302 to host 108 (1) without forwarding to or through classifier 304. These packets can be processed by the same forwarding unit 302 as packets for connections that are classified and routed without use transfer connections. These subsequent packets may optionally be tunneled from the forwarding unit 302 to the host 108 (1) using the tunneling unit 312. The tunneling unit 312 is also indicated by (dashed lines) on the connection transferring unit 310 on the classifier 304, since the specific parameter (s) used by the tunneling unit 312 can be determined during connection transferring and / or associated with a portable connection. Exemplary implementations of tunneling unit 312 are described below, in particular with reference to FIG. 38 and 39.

33 is a flowchart 3300 of a method for transferring a connection from a first device to a second device. The logical block diagram 3300 contains seven blocks 3302-3314. Although FIG. 32 and 34-37 are devoted mainly to connection transfer in a network load balancing environment, the connection transfer described here can be performed between two general devices, each of which has a connection transfer function, for example, as in connection transfer unit 310.

At block 3302, the first device accepts the connection. For example, the first device may terminate an incoming connection in accordance with one or more protocols of a portion of the protocol stack of the network stack. At block 3304, data is received for the connection on the first device. For example, this data can be received in the initial packet that requests a connection, or in one or more packets that arrive after the connection is accepted.

At block 3306, aggregation of the connection state for the received connection from the protocol stack (more generally from the network stack) on the first device occurs. For example, the protocol state for one or more protocols from the protocol stack can be compiled and aggregated using any received data that has been acknowledged. At block 3308, a connection state is sent from the first device to the second device. For example, aggregated information of a first state may be sent using a reliable protocol to a second device.

At block 3310, the connection state for the portable connection is received from the first device to the second device. At block 3312, the connection state is inserted into the protocol stack (more generally, the network stack) of the second device. For example, a connection can be “rehydrated” using the protocols of the protocol stack of the second device so that programs above the level of the protocol stack do not know that the connection is a relocated connection. In particular, the state of the protocol can be injected into the protocol stack. Aggregated connection state data is also often included on the second device. At block 3314, the connection continues on the second device. For example, the connection may continue on the second device, as if the connection did not end earlier in another place.

34 shows an approach to transferring connections from the point of view of the sending device 3400. Connection transfer on the sending device 3400 is carried out by at least a connection transferring unit 310. In the described implementation, the sending device 3400 is a device that is part of the network load balancing infrastructure 106. For example, the sending device 3400 may include a classifier 304, possibly in conjunction with a forwarder 302, a request router 306, etc.

It is shown that the sending device 3400 contains, as part of its network stack, a physical network interface (FSI) 3410, a miniport 3408 FSI, a protocol-hardware interface 3406, a protocol stack 3404, and a socket level 3402. The sending device 3400 also includes a load balancing function 106, for example, an application level classifier 304 and a connection transfer unit 310. In particular, the connection transfer unit 310 comprises an intermediate transfer driver 3414 and a “spacer” 3412 transfer unit. A connection transfer unit 310 is capable of offloading the connection from the sending device 3400.

In the described implementation, the physical network interface 3410 may be a network adapter (CA) (e.g., CA Ethernet), a wireless interface, etc. Although only one physical network interface 3410 is shown, this device can have many such physical network interfaces 3410 (i.e., the sending device 3400 can be connected to several data lines). Each physical network interface 3410 typically corresponds to one or more physical network addresses.

The FSI miniport 3408 is a software module that understands and provides interfacing with a specific hardware implementation of the physical network interface 3410. The protocol and hardware interface 3406 is a layer containing one or more corresponding interfaces between two or more corresponding protocols and the FSI miniport 3408.

The protocol stack 3404 includes one or more respective modules, each of which is intended for one or more respective protocols. Examples of such protocols are described below with reference to FIG. 36 and 37. In the transition context, the protocol stack 3404 contains a protocol state 3420 for each connection existing on the sender 3400. The socket layer 3402 lies between the program, for example, load balancing function 106, and the protocol stack 3404. Socket layer 3402 provides an API between load balancing function 106 and protocol stack 3404 and allows, among other things, programs to register for connections.

The intermediate transfer driver 3414 or, more generally, the transfer driver 3414 is located at the protocol-hardware interface level 3406. Gasket 3412 transfer unit is placed transparently between the stack 3404 protocols and level 3402 sockets.

When an initial packet (not shown) requesting a new connection is presented to the sending device 3400, the packet is sent upstream from the physical network interface 3410 to the FSI miniport 3408, through the protocol-hardware interface layer 3406 and to the protocol stack 3404. When a packet crosses one or more protocols of the protocol stack 3404, a protocol state 3420 is created on it. In addition, as a result of this initial packet, or because load balancing function 106 receives the connection to read the request, data 3416 is sent to the sending device 3400.

During operation, the intermediate transfer driver 3414 allocates a copy of the data 3416 to the logic of the connection transfer unit 310. When the load balancing function 106 issues a transfer call functional call, the transfer function call arrives at the highest level of the protocol stack 3404 so that aggregation of the connection state 3418 can begin. Protocol state 3420 is compiled from one or more protocols of protocol stack 3404. In a TCP / IP implementation, protocol state 3420 may include (i) TCP ports and destination and source IP addresses (e.g., an ordered four TCP / IP), (ii) TCP window state, (iii) starting sequence numbers, ( iv) suspension information, (v) IP fragment ID, (vi) routing information, and (vii) etc.

Aggregation of the connection state 3418 also aggregates data 3416 allocated to the connection transfer unit 310 and already acknowledged from the sending device 3400 (for example, load balancing function 106). This aggregated connection state 3418 includes protocol state 3420 and data 3416 (and, optionally, other information related to the connection). Then, the aggregated state of the connection 3418 is transmitted as a binary blob 3422 from the sending device 3400 to the destination device.

The binary bloom 3422 can be sent from the sending device 3400 to the destination device using a reliable protocol. By “reliable” it can be understood, for example, that the binary blob 3422 is received at the destination device unchanged, even if the individual packets constituting the binary blob 3422 are lost or damaged. This binary blob 3422 may also be packetized with a flow identifier if the connection is to be further tunneled by tunneling block 312. The flow identifiers are described below, in particular with reference to FIG. 38 and 39.

35 shows an approach to transferring connections from the perspective of the destination device 3500. The destination device 3500 is similar to the sending device 3400 with respect to the various levels / modules shown, including a connection transfer unit 310. However, it is shown that at least one application 316 at the application level is mated to a socket level 3402. Therefore, the destination device 3500 may comprise a host 108. In addition, the connection transfer unit 310 is capable of loading a connection from the sending device 3400.

In the described implementation, application 316 is the destination of the packet initiating the connection received at the sending device 3400. The destination device 3500 receives the binary blob 3422 from the sending device 3400. The binary blob 3422 includes a connection state associated with the connection transferred to destination device 3500 and, optionally, a stream identifier. This connection state includes protocol state 3420 and acknowledged data 3416 (and possibly other information related to the connection).

During operation, when the binary blob 3422 reaches the protocol-hardware interface level 3406, the intermediate transfer driver 3411 recognizes it as a blob for transferring the connection and retracts it. The connection state is inserted at 3502 to make it visible to the application 316 that the connection initially ended on the destination device 3500.

In particular, the state 3420 of the protocol of the inserted state 3502 connection is embedded in the stack 3404 protocols. In the described implementation, the state 3420 of the protocol is implemented first on the protocols of the higher level, and then on the protocols of the lower level of the protocol stack 3404. After the state 3420 of the protocol is inserted into the protocol stack 3404, the data 3416 can be indicated to the application 316. This data 3416 can be provided to the application 316 as if they were part of a newly and locally terminated connection.

Upon completion of the connection status insert 3502, the connection initiated by the packet received on the sending device 3400 is successfully transferred from there to the destination device 3500. Subsequent packets for connection can be sent directly to the destination device 3500 without passing through the sending device 3400 or, by at least only with simple routing and without application level analysis applied to them. Optionally, these packets can be tunneled so that the intermediate transfer driver 3414 effectively operates as a software-based virtual CA that is bound to a virtual IP address. In other words, the intermediate transfer driver 3414 (FIG. 35) may comprise a virtual network adapter mapped to an unencapsulated packet destination address.

On Fig shows the approach to the procedure 3600 unloading to transfer the connection. The transfer upload procedure 3600 shows additional illustrative details of the connection transfer from the sending device 3400. It is shown that the common protocol stack 3404 contains a TCP stack 3404 (T), an IP stack 3404 (I) and an address resolution protocol (ARP) stack 3404 (A) . However, alternatively, other stacks 3404 () of specific protocols can be used.

For example, the protocol-hardware interface layer 3406 can be implemented as a layer based on the specification of the standard network adapter interface (NDIS) in the Microsoft® Windows® operating system (OS) environment. In addition, socket level 3402 can be implemented as a Winsock ™ layer in Microsoft® Windows® (OS) environments.

In the described implementation, the intermediate transfer driver 3414 includes protocol and hardware interfaces 3406 at interfaces with the ARP stack 3404 (A) and the FSI miniport 3408. Transfer driver 3414 serves as the unload target in the transfer unload procedure 3600. The purpose of the upload is the miniport of the protocol-hardware interface 3406 shown in this example. In the transfer loading procedure 3700 (in FIG. 37), the intermediate transfer driver 3414 serves as a download tap.

In particular, the intermediate transfer driver 3414 is associated with each physical network interface 3410 through which a TCP connection can be transferred. The intermediate transfer driver 3414 typically acts as a transit driver, passing packets up or down the network stack and not interacting with packets in any other way. However, the intermediate transfer driver 3414 does not interact with packets related to connection transfers (optionally including subsequently tunneled packets).

The intermediate transfer driver 3414 is responsible for the following: (i) accepting transfer offload requests; (ii) aggregating protocol status information related to a portable TCP connection compiled from specific protocol stacks 3404 (), together with acknowledged data, to obtain connection status information; and (iii) transmitting the aggregated state of the connection to the destination device 3500 for the transfer loading procedure 3700. A reliable wired communication protocol for such a transmission can be shared with that used by the session tracking components 2002 and 2010 to send and receive session information messages 2008 (for example, described above with reference to FIG. 20).

Another objective of the intermediate transfer driver 3414 (for example, in the transfer loading procedure 3700) is to initiate the download of the portable connections that it receives from other devices and to buffer any incoming packets related to the transfer of the connection when it is in the process of loading. To download the connection, the transfer block intermediate driver 3414 sends a download request to the transfer block gasket 3412. Gasket 3412 of the transfer unit issues a call to insert on the protocol stack 3404 on the TCP stack 3404 (A) to process the connection in the portion of the protocol stack 3404 of the network stack.

Layout 3412 of the transfer unit opens the transport layer client interface to the TCP stack 3404 (T) and opens the transport layer provider interface to the socket layer 3402. The transfer block gasket 3412 plays two roles: (i) initiate the transfer transfer upload procedure 3600 on the sending device 3400, and then the transfer loading procedure 3700 on the destination device 3500 and (ii) mediates the classification process between the host application 316, the classification program 304 load balancing and 3402 socket level. The transfer unit gasket 3412 and the transfer unit intermediate driver 3414 are described below with reference to FIG. 36 and 37.

For the illustrated transfer upload procedure 3600, the TCP connection is transferred after the classifier 304 classifies the incoming TCP connection using one, two or more of its packets. Transfer transfer procedure 3600 is described by means of <1> - <7>.

Position <1> indicates the initialization that takes place before the classification operations. The protocol stack 3404 makes requests at the protocol-hardware interface level 3406 to determine what upload capabilities, if any, are available. Intermediate driver 3414 transfer unit indicates that the unload transfer connection is available and distributes the request down to the miniport 3408 FSI. If the possibility of unloading the “chimney” TCP is provided by the physical network interface 3410, then the miniport 3408 FSI also indicates this. Unloading the TCP “chimney” allows uploading some TCP / IP processing to the equipment of the physical network interface 3410 and provides some compilation of the 3420 protocol state. Therefore, some compilation and aggregation logic can be shared by two unloading mechanisms.

Position <2> indicates that after the TCP connection is classified, the classifier 304 initiates the transfer of the TCP connection to the selected host 108. In particular, through the socket level 3402, a transfer command is sent to the transfer block 3412 indicating the destination device 3500.

Position <3> indicates that the gasket 3412 transfer unit initiates the transfer of the TCP connection to compile the state of the TCP protocol. In particular, laying 3412 transfer unit calls the TCP transfer initial upload API (or, more generally, a “transfer connection” function call or a transfer transfer command). This procedure compiles the appropriate state for the specified TCP connection, which is used to reconnect to the destination device 3500. The compiled state 3420 of the protocol includes the state of the intermediate levels of the stack, including the TCP stack 3404 (T), 3404 (I) stack IP and stack 3404 (A) ARP.

Position <4> means that after the protocol stack 3404 compiled the protocol state 3420 for the portable TCP connection, it calls the transport initial unload API on the miniport to which it is attached; in this example, this miniport is an intermediate driver 3414 transfer unit. However, in practice, other intermediate drivers, such as IP QoS, can be inserted between the protocol stack 3404 and the intermediate driver 3414 of the transfer unit. In this case, these intermediate drivers of the transfer unit may participate in the transfer if they relate by compiling / aggregating their state into connection status information for the transferring connection. Intermediate drivers continue to propagate the “start transfer unloading” call down to the network stack, which ultimately leads to the execution of the transfer unloading processor on the intermediate driver 3414 of the transfer unit. In this case, the intermediate driver 3414 of the transfer unit also aggregates any acknowledged data with the rest of the connection state to transfer the TCP connection to the destination device 3500.

Position <5> means that after saving / copying the connection status information for the transferred TCP connection, the intermediate driver 3414 of the transfer unit informs the network stack that the transfer is in its final stages, calling the API to complete the initial transfer unload. This API for completing the initial transfer unloading goes the return way up from the network stack, through the same intermediate drivers, if any, and, finally, to the protocol stack 3404. As each level processes this call, status information associated with the portable connection may be released. Until this call is processed, each layer can send update notifications down to the network stack to update any part of the connection state that has changed since the transfer began.

Position <6> means that when the procedure for completing the initial transfer offload reaches the TCP stack 3404 (T), TCP silently (that is, sending a reboot command to client 102) closes the connection, resetting all the state associated with the portable connection, and extends the call "initial transfer unloading completed" to the gasket 3412 transfer unit. In this case, the network stack is freed from any residual information of the transferred TCP connection.

Position <7> means that when the call “initial transfer unloading is completed” returns to the intermediate driver 3414 of the transfer unit (through part of the gasket 3412 of the transfer unit of transfer unit 310), the TCP connection is transferred from the sending device 3400 to the destination device 3500 may begin by transferring the connection state to it. Connection status can be transmitted asynchronously and reliably.

Once the transfer has begun, the sending device 3400 must also ensure that subsequent data from the client 102 is sent to the destination device 3500. Therefore, even after the connection is successfully transferred to the destination, the sender retains some amount of state for the connection (for example, a routing table element) to route correctly subsequent packets to the destination. When the connection ends, the recipient notifies the sender to allow him to clear all remaining status for the transferred connection.

In addition, due to the asynchronous nature of the transfer of the connection, data packets for transferring the connection, which are forwarded by the sending device 3400 (or the forwarding unit, considered as a separate device) may begin to arrive at the destination device 3500 before the destination device 3500 receives the status of the transferred connections. Intermediate driver 3414 transfer unit on the destination device 3500 is responsible for buffering these packets until the corresponding portable connection is established on the destination device 3500.

37 shows an approach to a download procedure 3700 for transferring a connection. Transfer download procedure 3700 shows illustrative details for transferring a connection from the destination device 3500.

When the portable connection arrives at the destination device 3500, it relies on the intermediate driver 3414 transfer unit for processing. After expanding and combining the state of the portable connection, the intermediate driver 3414 of the transfer unit, in combination with the gasket 3412 of the transfer unit, inserts the portable connection into the local network stack transparently for application 316. For the transfer loading procedure 3700, the transfer of the TCP connection is described at positions <1> - <8> .

Position <1>, as described above with reference to transfer upload procedure 3600, denotes initialization prior to application hosting operations. In particular, the protocol stack 3404 makes inquiries as to what upload capabilities, if any, exist. The intermediate driver 3414 of the transfer unit fills out a request for support for transferring a TCP connection to indicate that a connection transfer download is available, and also distributes the request down to the FSI miniport 3408 for possible TCP chimney discharge capabilities.

Position <2> means that when the connection transfer data arrives at the destination device 3500, the connection transfer information (for example, packetized binary blob 3422) is delivered to the intermediate driver 3414 of the transfer unit. The intermediate driver 3414 of the transfer unit reassembles the connection status, reconciles it with any relevant data received during the transfer, and prepares for loading onto the network stack. Any data from client 102 coming in during the download of the portable connection is buffered by the intermediate driver 3414 of the transfer unit. Upon successful completion of the transfer, the data will be delivered to application 316.

According to position <3>, in order to initiate the loading of the portable connection to the local network stack, the intermediate driver 3414 of the transfer unit notifies the gasket 3412 of the transfer unit of the receipt of the request for the portable connection. The intermediate driver 3414 of the transfer unit also delivers the connection state (or at least the state 3420 of the protocol) to the gasket 3412 transfer unit.

Position <4> indicates that the transfer unit gasket 3412 initiates the download of the portable connection, invoking the initial TCP insert procedure (or, more generally, the protocol state injection procedure) and issuing the state of the portable protocol 3420 onto the TCP stack 3404 (T). Position <5> indicates that TCP / IP restores the portable connection through the protocol stack 3404 using the provided protocol state 3420. This protocol state 3420 may include one or more of a transport state (TCP), a path state (IP), a neighbor state and a next hop (ARP), etc.

Position <6> means that if the portable connection is successfully re-established on the destination device 3500, then TCP will trigger a connection event with the client part of the gasket 3412 transfer unit to indicate the establishment of a new connection. There are many possible reasons for the failure, but common reasons may include a lack of an appropriate listener, a routing failure, etc. In these cases, when the network stack is not able to re-establish the portable connection, not a single connection event is indicated, and the status “failed” is set in the “initial insert completed” call. The connection transfer unit 310 is responsible for clearing the transfer and sending the reboot notification back to the client 102 to terminate the connection.

Position <7> indicates that the transfer block gasket 3412 acts as a provider propagating the connection event to socket level 3402 to indicate to the listening application 316 that a new connection has been established. If application 316 accepts the connection, it processes requests and responses through normal socket read and write operations; application 316 may not be aware that the connection has been moved. If application 316 did not accept the connection, then TCP terminates the connection but does not send a reboot notification back to client 102. Again, in the call “initial insert is completed” the status is set to “failure”, and the connection transfer unit 310 is responsible for clearing the transfer and sending restart notifications back to client 102 to terminate the connection.

A special situation arises when the application 316 and the classifier 304 are jointly located on the same device: the transfer unit gasket 3412 may be the judge between them. When both classes of programs are hosted on the same host 108, they can both listen on the same IP address (s) and port (s). However, TCP usually has one listener per unique IP address and port. Therefore, the transfer block gasket 3412 can obscure the configuration when two programs listen on the same IP address and port, multiplexing two sockets into a single listener at the TCP level.

In this case, when the connection events are sent to the client part of the transfer block gasket 3412, the transfer block gasket 3412, as a provider, determines to which listening socket the connection notification should be delivered at the level of 3402 sockets. If there is only one socket listening on the corresponding IP address and port, this socket receives a connection event. If there is more than one listening socket, the receiver depends on the context in which the connection event is indicated. If the connection event is a proprietary new connection for the virtual IP address, then the connection event is delivered to classifier 304; if the connection event refers to a dedicated IP address (IP address without load balancing) or is the result of loading a portable connection, then the connection event is delivered to the destination application 316.

Position <8> means that upon completion of the portable connection, TCP notifies the transfer block gasket 3412, invoking the provided initial insert completion handler. A status code is provided to notify the transfer block gasket 3412 whether the connection has been successfully updated. If the download of the portable connection fails, then the connection transfer unit 310 is responsible for clearing the transfer and for notifying the client 102 about the connection being terminated by sending it a restart command. If the portable connection was successfully inserted into the local network stack, the intermediate driver 3414 of the transfer unit may begin to deliver buffered data from client 102 by transmitting the received packet (s) through the packet receiving path of the protocol-hardware interface 3406.

When the portable connection ends (due to a failed download, due to the fact that the transferred connection was subsequently closed by normal means, etc.), the destination device 3500 notifies the sending device 3400. The sending device 3400 uses these notifications to efficiently and reliably clean inactive state for portable connections, including routing table elements. Therefore, to account for successfully transferred connections that arbitrarily end in the future, the transfer block routing 3412 can monitor their activity and notify the transfer block intermediate driver 3414 when the sockets are closed due to this.

FIG. 38 illustrates an approach to tunneling packets between forwarder 302 and host 108. Encapsulated packets 3808 can tunnel from forwarder 302 to host 108 without any overhead for each transmitted packet. As described below, the tunneling is performed using the flow identifier 3814 and the encapsulation mapping tables 3806 and 3810 of the tunneling units 312 (F) and 312 (H), respectively, of the forwarding unit 302 and the host 108, respectively. The identifier 3814 flow is inserted into the encapsulated packets 3808.

As noted above with reference to FIG. 32, packets for a connection that arrive after transferring a connection can be routed by the forwarding unit 302 to the host 108 (1) using tunneling using the tunneling unit 312. According to (8) (FIG. 32), the forwarding unit 302 forwards these subsequent packets from the forwarding unit 302 having the network address “F” to the host 108 (1) having the network address “H1”. As described above with reference to FIG. 4, the forwarding unit 302 may perform TCA [network address translation], semi-TCA, tunneling, etc., to route incoming packets to host 108 (1).

Such incoming packets contain the destination IP address of the virtual IP address (VIP) and the source IP address “C1” for packets arriving from client 102 (1). Packets routed to host 108 (1) have a destination IP address and a source address of C1 (for semi-TCA) or “F” (for full TCA). This rewriting of addresses may interfere with some protocols that expect client 102 (1) and host 108 (1) to have identical types of source and destination addresses.

Therefore, at least with respect to the complete TCA, the return paths from the host 108 (1) to the client 102 (1) that do not pass through the forwarding unit 302 are prohibited because the host 108 (1) does not know the address of the client 102 (1). Direct paths from host 108 (1) to client 102 (1) are desirable in situations where traffic from host 108 (1) to client 102 (1) is especially high and / or significantly exceeds traffic in the opposite direction (for example, when host 108 ( 1) provides streaming multimedia data to the client 102 (1)).

Tunneling via tunneling units 312 as described herein can provide identical views with respect to source and destination addresses (and ports) for clients 102 and applications 316 on hosts 108. For example and with reference to FIG. 34 and 35, the tunneling unit 312 on each of the forwarding unit 302 and the host 108 may act as part of, or in conjunction with, the transfer intermediate driver 3414 of the transfer unit 310.

In the implementation described with reference to FIG. 38, the connection transfer unit 310 provides an encapsulation mapping 3812 between the flow identifier 3814 and the TCP / IP ordered four 3804. A connection transfer unit 310 may be associated with a classifier 304, and a connection transfer unit 310 (optionally in conjunction with such a classifier 304) may reside on the same device as the transfer unit 302. Alternatively, the connection transferring unit 310 (as well as the classifier 304) may reside on a device other than the forwarding unit 302. The encapsulation display 3812 may alternatively be provided by or in conjunction with the function of the tunneling unit 312, i.e., for example, be located on or associated with the classifier 304.

Being mapped to TCP / IP ordered four 3804 by means of encapsulation mapping 3812, flow identifier 3814 serves to identify the encapsulated packet stream 3808 for a particular connection. The ordered four 3804 TCP / IP contains the network address (and ports, etc.) for the source and destination for a particular connection in accordance with the TCP / IP protocol or any similar or similar protocol. The flow identifier 3814 is 32-bit in the described implementation since it allows the flow identifier to be encoded in the source port and destination port fields of the TCP header segment in the tunneled packet, which allows the tunneled packet to be transmitted without any additional tunneling space overhead. At the destination, the ordered four TCP / IP can be determined by searching for the ordered four that is associated with the flow identifier extracted from the source port and destination port fields. However, alternatively, stream identifiers 3814 of a different length may be used, especially for other protocols such as Internet RTP, etc.

Each flow identifier 3814 may identify a unique connection from the device from which tunneling begins (which in this example is forwarding unit 302). Flow identifiers 3814 may be generated using any suitable mechanism, such as an incremental connection counter. Alternatively, the initial sequence number (NN) of the TCP / IP receiver generated by the connection transfer unit may serve as a stream identifier 3814. Furthermore, the ordered four 3804 TCP / IP is, in a more general case, a source / destination pair. Each source value and destination value of an individual source / destination pair may include an identifier of a network node (for example, network address, port, some combinations thereof, etc.) for a source and destination, respectively, of a given package distributed over specific compound.

The connection transfer unit 310 provides an encapsulation mapping 3812 to the host 108. The tunneling unit 312 (H) on the host 108 stores the encapsulation mapping 3812 in the encapsulation mapping table 3810 as the encapsulation mapping element 3810 (1). Tunneling unit 312 (H) may then use flow identifier 3814 to display and identify a particular connection corresponding to TCP / IP ordered four 3804. The encapsulation mapping 3812 may optionally be reported to the host 108 as part of a packetized binary blob 3422 in a connection transfer operation.

Forwarding unit 302 also contains a component of tunneling unit 312 (F) with encapsulation mapping table 3806. Encapsulation mapping table 3806 stores an encapsulation mapping element 3806 (1) that associates / maps an ordered four TCP / IP four 3804 for a particular connection into a stream identifier 3814. Tunneling unit 312 (F) also obtains mapping information for encapsulation display element 3806 (1) from connection transfer unit 310 (e.g., encapsulation mapping 3812).

Although only one encapsulation mapping element 3806 (1) and 3810 (1) is shown, the encapsulation mapping table 3806 and the encapsulation mapping table 3810 may have many such elements. These encapsulation mapping tables 3806 and 3810 may be combined with other information, such as tables for session information, of the session tracking unit 308.

When a device (e.g., forwarder 302) is a transmitter and a device (e.g., host 108) that receives encapsulated packets 3808 only provides tunneling between themselves, their encapsulation mapping tables probably have the same encapsulation mapping elements. Otherwise, the encapsulation mapping table 3806 and the encapsulation mapping table 3810 probably have different full sets of encapsulation mapping elements 3806 () and the encapsulation mapping elements 3810 (), respectively.

During operation, an incoming packet 3802 for a particular connection arrives at the forwarder 302. A specific connection is associated with an ordered four 3804 TCP / IP. Incoming packet 3802 contains an ordered four TCP / IP four 3804 with source IP address (client 102), destination IP address (virtual IP), source TCP port (client 102), and destination TCP port.

The tunneling unit 312 (F) receives the incoming packet 3802 for tunneling to the host 108. Using the ordered four TCP / IP 3804, the tunneling unit 312 (F) looks at the encapsulation mapping table 3806 to find the encapsulation mapping element 3806 (1). The flow identifier 3814 is retrieved from the encapsulation mapping element 3806 (1) as connected / mapped to the ordered four TCP / IP 3804.

To create the encapsulated packet 3808, the tunneling unit 312 (F) inserts the flow identifier 3814 into the port part of the source and destination of the ordered four TCP / IP. These two parts of TCP have 16 bits each, which allows you to insert a 32-bit identifier 3814 stream. In addition, for the TCP / IP ordered four header source IP address portion, the tunneling unit 312 (F) inserts the IP address “F” of the forwarding unit 302. For the TCP / IP ordered four header portion destination IP address portion, tunneling unit 312 (F) inserts the IP address “H” of host 108.

Forwarder 302 routes / transmits the encapsulated packet 3808 to host 108, and host 108 receives the encapsulated packet 3808 from forwarder 302. The component of the forwarder 312 (H) at the host 108 detects that the encapsulated packet 3808 is a tunneled packet that needs to be decapsulated.

The flow identifier 3814 is retrieved from the encapsulated packet 3808 and used to search for the corresponding ordered TCP / IP quadruple 3804 that is associated with the encapsulation display element 3810 (1) 38 of the encapsulation mapping table 3810. The TCP / IP ordered four 3804 is used by the tunneling unit 312 (H) to recover the ordered TCP / IP four four 3804 as originally received in the incoming packet 3802 on the forwarding unit 302.

In particular, the IP address F of the forwarder 302 is replaced by the source IP address, and the IP address H of the host 108 is replaced by the destination IP address. In addition, the flow identifier 3814 is replaced by the source TCP port and the destination TCP port. The unencapsulated packet is indicated through the network stack of the host 108 to the target application 316.

In general, a portion of the packet header, including a portion of the source / destination pair, for a given packet, which is not necessarily used to transmit this packet, can be used to carry the flow identifier 3814. By providing at least a portion of the source / destination pair to host 108, the flow identifier 3814 can be used to tunnel (e.g., encapsulate and / or decapsulate) packets without involving the encapsulation overhead on each packet. In addition, packets that are full size with respect to this protocol can be tunneled without fragmentation.

FIG. 39 is a flowchart 3900 of a packet tunneling method between a first device and a second device. For example, the first device and the second device may correspond to the sending device 3400 and the destination device 3500, respectively, of the load balancing infrastructure 106 and the host group 108, respectively. However, tunneling can be used in non-load balancing implementations.

The logical block diagram 3900 contains twelve blocks 3902-3924. Although the actions of the logical flowchart 3900 can be carried out in other environments and through various software circuits, FIG. 1-3, 32, 34, 35 and 38 are used, in particular, to illustrate certain aspects and examples of the method.

At block 3902, the sending device sends to the destination device the mapping of the stream identifier into an ordered four TCP / IP. For example, the sending device 3400 may send an encapsulation mapping 3812 that maps the flow identifier 3814 to the ordered four TCP / IP 3804. At block 3914, the destination device receives the mapping of the flow identifier to the ordered four TCP / IP from the sending device. For example, the destination device 3500 receives an encapsulation mapping 3812 from the sending device 3400, which maps the flow identifier 3814 to the ordered four TCP / IP 3804.

Alternatively, the destination device 3500 may receive an encapsulation mapping 3812 from another device. The dashed arrows 3926 and 3928 indicate that the actions of blocks 3904-3912 and blocks 3916-3924 can occur some time after the actions of blocks 3902 and 3914, respectively.

At block 3904, the sending device receives an incoming packet from the client. For example, a sending device 3400 may receive an incoming packet 3802 from a client 102 having a TCP / IP ordered four 3804 header. At block 3906, a stream identifier is searched for the connection corresponding to the client packet using the ordered four TCP / IP of the incoming packet. For example, you can search for thread identifier 3814 to connect to client 102 using the ordered four TCP / IP 3804 that maps to it in the encapsulation mapping element 3806 (1) of the encapsulation mapping table 3806.

At block 3908, the source IP and destination IP of the incoming packet are replaced with the IP address of the sender of the sending device and the destination IP address of the destination device, respectively. For example, a sender 3400 may replace portions of the IP address of a portion of the ordered four 3804 TCP / IP headers of the incoming packet 3802 with the IP addresses of the sender 3400 and the destination 3500.

At block 3910, the source port and destination port of the incoming packet are replaced by the stream identifier. For example, a sending device 3400 may replace the source and destination TCP ports of a portion of the ordered four 3804 TCP / IP headers of the incoming packet 3802 with flow identifier 3814. At block 3912, the sending device transmits the encapsulated packet to the destination device. For example, a sending device 3400 may send an encapsulated packet 3808 to a destination device 3500.

At block 3916, the destination device receives an encapsulated packet from the sending device. For example, the destination device 3500 can receive an encapsulated packet 3808 from the sending device 3400. At block 3918, an ordered four TCP / IP is searched for the connection corresponding to the packet received from the client using the flow identifier. For example, the destination device 3500 may refer to the encapsulation mapping table 3810 in the encapsulation mapping element 3810 (1), which maps the flow identifier 3814 to the ordered four TCP / IP 3804.

At block 3920, the sender’s IP address and the recipient’s IP address are replaced by the source IP address and destination IP address, respectively, using the TCP / IP ordered four. For example, the destination device 3500 can replace the IP addresses of the sending device 3400 and the destination device 3500 in the encapsulated packet 3808 with the source IP address and destination IP address from the ordered four TCP / IP 3804 obtained from the encapsulation mapping table 3810.

At block 3922, the flow identifier is replaced by the source port and destination port of the incoming packet using the TCP / IP ordered four. For example, the destination device 3500 can replace the flow identifier 3814 in the encapsulated packet 3808 with the source TCP and destination TCP ports from the ordered four TCP / IP 3804. At block 3924, the client package is indicated to the application on the destination device. For example, a decapsulated version of the encapsulated packet 3808 or an incoming packet 3802 is indicated to the application 316 of the destination device 3500.

The actions, aspects, features, components, etc. indicated in FIGS. 1-39 are presented in the form of diagrams consisting of a number of blocks. However, the order, relationships, layouts, etc., used to describe and present FIGS. 1-39 should not be considered in the sense of limitation, and for any number of blocks any combination, change of location, addition, exclusion, etc. . for implementing one or more systems, methods, devices, protocols, media, APIs, devices, configurations, etc. to balance network load. Furthermore, although the description provided here includes references to specific implementations (and the illustrative operating environment shown in FIG. 40), the shown and / or described implementations can be implemented using any suitable hardware, software, firmware or hardware or combinations and using any suitable network organizations, transport / communication protocols, application programming interfaces (APIs), client-server architectures, etc.

Operating environment of a computer or other device

On Fig shows the operating environment 4000 of a computer (or general purpose device), capable of (in whole or in part) to implement at least one system, device, apparatus, component, configuration, protocol, approach, method, procedure, media, API some combination thereof, etc. for network load balancing described here. Operating environment 4000 can be used in the following computer and network architectures or in stand-alone conditions.

Operating environment 4000 is just one example of the environment and is not intended to limit the use or functionality of the device architectures (including computer, network node, entertainment device, mobile device, general electronic device, etc.) in any way. In addition, the computing environment 4000 (or its devices) should not be construed as having any dependency or requirement with respect to any or a combination of components shown in FIG.

In addition, network load balancing can be implemented through numerous other environments or configurations of a general purpose device or a special purpose device (including a computing system). Examples of well-known devices, systems, environments and / or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, thin clients, thick clients, personal digital assistants (PDAs), or mobile phones, watches, handheld or portable devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, video game devices, game consoles, portable or handheld game devices systems, network PCs, minicomputers, universal computers, network nodes, distributed or multiprocessor computing environments, which include any of the above systems or devices, some combinations thereof, etc.

Network load balancing implementations can be described in the general context of instructions executed by a processor. In general, instructions executed by a processor include procedures, programs, protocols, objects, interfaces, components, data structures, and the like that perform specific tasks and / or implement certain abstract data types. Network load balancing, described here in some implementations, can also be practiced in distributed processing environments where tasks are performed by remotely-connected processing devices connected via a line and / or communication network. Especially in a distributed computing environment, instructions executed by a processor can be located on separate storage media, executed by different processors, and / or distributed across data transmission media.

Operating environment 4000 includes a general-purpose computing device in the form of a computer 4002, which may include any (e.g., electronic) device with computing / processing capabilities. Components of computer 4002 may include, but are not limited to, one or more processors 4004, system memory 4006, and system bus 4008 that connects various system components, including processor 4004, to system memory 4006.

Processors 4004 are not limited to the materials from which they are formed, or the processing mechanisms used therein. For example, processors 4004 may consist of semiconductors and / or transistors (e.g., electronic integrated circuits (ICs)). In this context, instructions executed by a processor may be electronically executed instructions. Alternatively, the mechanisms of processors 4004, and hence of computer 4002, may include, but are not limited to, quantum computing, optical computing, mechanical computing (e.g., using nanotechnology), etc.

The system bus 4008 represents one or more of many types of bus structures, including a memory bus or memory controller, point-to-point connection, switching fabric, peripheral bus, accelerated graphics port, and processor bus or local bus using a variety of bus architectures. For example, such architectures may include an industry standard architecture bus (ISA), microchannel architecture bus (MCA), an extended ISA bus (EISA), a local VESA bus, and peripheral component connection bus (PCI) , also called expansion bus, some combinations thereof, etc.

Computer 4002 typically contains a variety of environments available to the processor. Such media can be any available media that can be accessed by a computer 4002 or other (e.g., electronic) device, and includes both volatile and non-volatile media, removable and non-removable media, storage media, and data transmission media.

System memory 4006 contains media accessible to the processor in the form of volatile memory, such as random access memory (RAM) 4040, and / or non-volatile memory, such as read only memory (ROM) 4012. Basic input / output system (BIOS) 4014, containing basic procedures, which help transfer information between elements of computer 4002, for example, at startup, is stored in ROM 4012. RAM 4010 usually contains data and / or program modules / instructions that are directly accessible to processor 4004 and / or are currently being processed by it.

Computer 4002 may also include other removable / fixed and / or volatile / nonvolatile storage media. As an example, FIG. 40 shows a hard disk or an array of disk drives 4016 for reading from (usually) a stationary non-volatile magnetic medium (not shown separately) and writing to it, a magnetic disk drive 4018 for reading from a (usually) removable non-volatile magnetic disk 4020 (eg, a “floppy disk”) and writing to it and an optical disk drive 4022 for reading from and (usually) a removable non-volatile optical disk 4024, such as a CD, DVD, or other optical medium and writing to it. A hard disk 4016, a magnetic disk drive 4018, and an optical disk drive 4022 are connected to the system bus 4008 via one or more storage media interfaces 4026. Alternatively, the hard disk 4016, the magnetic disk drive 4018, and the optical disk drive 4022 may be connected to the system bus 4008 via one or more other separate or combined interfaces (not shown).

The drives and associated media available to the processor provide non-volatile storage of instructions executed by the processor, for example, data structures, program modules and other data for computer 4002. Although the illustrated computer 4002 shows a hard disk 4016, a removable magnetic disk 4020 and a removable optical disk 4024, it is obvious that for storing commands available to the device, you can also use other types of media available to the processor, for example magnetic cassettes or other magnetic storage devices, flash memory, compact discs (CDs), digital versatile disks (DVDs) or other optical storage media, RAM, ROM, electrically erasable programmable read-only memory devices (EEPROM), etc. Such media may also include so-called specialized or “wired” IPs. In other words, any media available to the processor can be used to implement the storage media of the illustrative operating environment 4000.

On the hard disk 4016, magnetic disk 4020, optical disk 4024, ROM 4012 and / or RAM 4010 can be stored any number of program modules (or other blocks or sets of commands / codes), including, for example, operating system 4028, one or more application programs 4030, other software modules 4032 and software data 4034.

A user may enter commands and / or information into a computer 4002 through input devices, such as a keyboard 4036 and pointing device 4038 (such as a mouse). Other input devices 4040 (not specifically shown) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, and / or other. These and other input devices are connected to the processor 4004 via input / output interfaces 4042 that are connected to the system bus 4008. However, input devices and / or output devices can alternatively be connected via another interface and bus structures, for example, a parallel port, a game port, a universal serial bus (USB), an infrared port , IEEE 1394 ("Firewire"), IEEE 802.11 wireless, Bluetooth® wireless, etc.

A visual monitor / screen 4044 or another type of display device may also be connected to the system bus 4008 through an interface, such as a video adapter 4046. Video adapter 4046 (or another component) may or may include a graphics card for processing graphics that require large computational resources , and to fulfill the requirements of the display. Typically, a graphics card contains a graphics processor (GPU), video memory (WHO), etc. to facilitate quick display of graphics and graphic operations. In addition to the 4044 monitor, other peripheral output devices may include components such as speakers (not shown) and a printer 4048, which can be connected to the computer 4002 via input / output interfaces 4042.

Computer 4002 may operate in a network environment using logical connections to one or more remote computers, such as a remote computing device 4050. For example, the remote computing device 4050 may be a personal computer, a laptop computer (eg, laptop, tablet computer, PDA, mobile station etc.), a handheld or handheld computer, a clock, a gaming device, a server, a router, a network computer, a peer device, another network node or other device about the type of the above, etc. However, the remote computing device 4050 is shown as a portable computer, which may contain many or all of the elements and features described herein with reference to computer 4002.

The logical connections between the computer 4002 and the remote computer 4050 are presented in the form of a local area network (LAN) 4052 and a common global network (HS) 4054. Such network environments are usually used in office, industrial computer networks, intranets, the Internet, landline and mobile telephone networks, special and infrastructural wireless networks, other wireless networks, game networks, in some of their combinations, etc. Such networks and communications are examples of communication media.

When implemented in a LAN network environment, computer 4002 is connected to the LAN 4052 via a network interface or adapter 4056. When implemented in a LAN network environment, computer 4002 typically contains a 4058 modem or other means of establishing connections to the 4054 GS. 4058 modem, which can be internal or external relative to the computer 4002, can be connected to the system bus 4008 via input / output interfaces 4042 or any other appropriate mechanisms. Obviously, the network connections shown are illustrative and that other means can be used to establish communication link (s) between computers 4002 and 4050.

In addition, you can use other equipment specifically designed for servers. For example, you can use SSL acceleration cards to upload SSL calculations. In addition, especially in the network load balancing operating environment, you can install and use TCP upload equipment and / or packet classifiers on server interfaces or 4056 adapters (for example, on network interface cards) on server devices.

In a network environment illustrated by operating environment 4000, program modules or other instructions described with reference to computer 4002, or a portion thereof, may be fully or partially stored on a remote storage device. For example, remote applications 4060 are located in the memory component of the remote computer 4050, but may be used or may otherwise be accessible through the computer 4002. Also, for purposes of illustration, applications 4030 and other instructions executed by a processor, such as operating system 4028, are shown here. as discrete blocks, although it is clear that such programs, components and other commands are placed at different points in time in different storage components of computer 4002 (and / or remote computer 4050) and are processor (s) 4004, the computer 4002 (and / or remote computer 4050).

Although systems, media, devices, methods, procedures, apparatuses, methods, circuits, approaches, procedures, configurations and other implementations have been described in a language specific to structural, logical, algorithmic and functional features and / or diagrams, it should be understood that the invention disclosed in the attached claims is not required to be limited to the particular features or diagrams described above. On the contrary, specific features and diagrams are disclosed as illustrative forms of implementing the claimed invention.

Claims (40)

1. A method of balancing network load, comprising stages in which:
in the load balancing module (106), connect to the client (102 (1), (102 (2) ... (102 (m)) by sending a confirmation to the client in response to receiving a connection request from the client;
aggregate (3418) in the load balancing module the connection state created for connecting to the client in the network stack (3404) in the load balancing module;
sending from the load balancing module to the host (108 (1), (108 (2) ... (108 (n)) the connection status related to the connection with the client;
receiving from the host load balancing module the connection state related to the client connection;
insert (3502) the connection state related to the connection with the client on the network stack (3404) of the host; and
continue at the host to connect to the client using the connection state inserted into the host network stack. 2. The method according to claim 1, in which the step of accepting the connection comprises the step of:
send a confirmation packet to the client in response to the connection request packet. 3. The method according to claim 1, additionally containing a stage in which:
receive data regarding the connection in the load balancing module (106);
moreover, the stage of aggregation of the state of the connection contains a stage in which:
aggregate the connection state from the protocol state of the network stack (3404) and said data. 4. The method according to claim 1, in which the step of aggregating the state of the connection comprises the step of:
compile the state of the protocol from the network stack (3404). 5. The method according to claim 4, in which the compilation step comprises the step of:
compile the state of the protocol from the network stack (3404), starting with the highest level of the network stack. 6. The method according to claim 4, in which the compilation step comprises the step of:
compile the state of the protocol from the network stack (3404) into portions of the Transmission Control Protocol (TCP) stack and portions of the Internet Protocol (IP) stack. 7. The method according to claim 1, in which the transmission step comprises the steps of:
packetizing a connection state with a stream identifier that corresponds to the connection to create a binary blob (3422); and
send a binary blob from the client (102 (1), (102 (2) ... (102 (m)) to the host (108 (1), (108 (2) ... (108 (n)). 8. The method according to claim 1, in which the sending step comprises the steps of:
packetizing the connection state with the identifier (3814) of the stream that corresponds to the connection to create a binary blob (3422); and
send the binary blob from the client (102 (1), (102 (2) ... (102 (m)) to the host (108 (1), (108 (2) ... (108 (n)) in a reliable way so that the host can accept the binary blob in its original form, even if one or more of the packages that make up the binary blob are lost or damaged. 9. The method according to claim 1, additionally containing stages in which:
selecting a flow identifier (3814) for the connection in accordance with the connection counter, and
send a stream identifier to identify packets corresponding to the connection to the host (108 (1), (108 (2) ... (108 (n)). 10. The method according to claim 1, in which the sending step further comprises a step in which:
send the connection state to the host (108 (1), (108 (2) ... (108 (n));
moreover, the method further comprises a step on which:
forward subsequent packets for connection to the host using a stream identifier (3814) to encapsulate subsequent packets. 11. The method according to claim 1, in which the continuation step further comprises a step in which:
continue the connection by indicating the received packets to the application in accordance with the inserted connection state. 12. The method according to claim 1, in which:
the receiving step comprises a step in which:
receiving a connection state, the connection state having a protocol state and data for the connection; and
the insertion step comprises the step of:
insert the protocol state into the protocol stack part of the network stack (3404). 13. The method of claim 12, wherein the step of inserting a connection state further comprises the step of:
indicate data for connection through the network stack (3404) to the application. 14. The method according to claim 1, wherein the insertion step comprises the step of:
inject the protocol state from the connection state into a part of the protocol stack of the network stack (3404). 15. The method according to 14, in which the implementation phase comprises the step of:
inject the state of the protocol into the network stack, starting with the highest level of the network stack (3404). 16. The method according to 14, in which the implementation phase comprises the step of:
inject the state of the protocol into the network stack (3404) on the part of the Transmission Control Protocol (TCP) stack and part of the Internet Protocol (IP) stack. 17. The method according to claim 8, in which the receiving step comprises the steps of:
receiving a binary blob (3422) from the load balancing module (106) in the host (108 (1), (108 (2) ... (108 (n)); and
de-packetize the connection state and stream identifier (3814) at the network stack level (3404), which is below the portion of the protocol stack of the network stack. 18. The method according to claim 1, wherein the method comprises the steps of:
accept host encapsulation mapping; and
save the received encapsulation mapping in the encapsulation mapping table (3806, 3810), access to which is possible by the stream identifier (3814) in the host. 19. The method according to claim 1, wherein the method further comprises the steps of:
receiving encapsulated packets having a flow identifier (3814) from the load balancing module; and
encapsulate packets are decapsulated using the encapsulation display element (3806 (1), 3810 (1)), which maps the stream identifier (3814) to the source / destination pair. 20. A storage medium accessible to the processor, comprising instructions that, when executed by a computer, cause the computer to execute the method according to any one of the preceding paragraphs. 21. A network load balancing module (106), comprising:
a connection transfer unit (310) configured to transfer connections from said module, the connection transfer unit being capable of compiling a protocol state for connection over a network stack (3404);
a connection transfer unit is configured to aggregate a compiled protocol state with data for a connection into an aggregated connection state for a connection;
the connection transfer unit is further configured to initiate sending the aggregated state of the connection to the host (108 (1), (108 (2) ... (108 (n)); and
a classifier (304) capable of receiving a connection, the classifier being configured to issue a connection transfer command to the connection transfer unit (310). 22. Module (106) according to claim 21, wherein the connection transfer unit (310) is implemented at least partially in the form of software. 23. Module (106) according to claim 21, wherein the data that aggregates with the compiled protocol state to the aggregated state of the connection contains data acknowledged by the classifier (304). 24. The module (106) according to item 21, in which the block (310) transfer connections contains:
“Laying” (3412) of the transfer unit, which is located above the protocol stack (3404) in the network stack of the module (106); and
an intermediate driver (3414) of the transfer unit, which is located below the protocol stack in the network stack (3404) of the module (106). 25. Module (106) according to claim 24, wherein:
The “laying” (3412) of the transfer unit is placed between the protocol stack (3404) and the socket level (3402) of the network stack of the module (106); and
an intermediate driver (3414) of the transfer unit is placed between the protocol stack (3404) and at least one miniport (3408) of the network stack (3404) of the module (106). 26. The module (106) according to claim 25, wherein the intermediate driver (3414) of the transfer unit is located at the protocol-hardware interface of the network stack (3404) of the module (106). 27. Module (106) according to claim 24, wherein:
The “laying” (3412) of the transfer unit is configured to receive the transfer command and distribute the transfer command to the protocol stack (3404), and
the intermediate driver (3414) of the transfer unit is adapted to retrieve a copy of the data for connection for subsequent aggregation with the compiled protocol state. 28. The module (106) according to paragraph 24, in which the intermediate driver (3414) of the transfer unit is configured to packetize the aggregated state of the connection and the identifier (3814) of the stream for connection to a large binary object (binary blob) (3422), representing the state of the connection . 29. Module (106) according to claim 21, wherein the connection comprises a Transmission Control Protocol / Internet Protocol (TCP / IP) connection, and the compiled protocol state includes information related to the TCP / IP connection. 30. Module (106) according to claim 21, wherein the module further comprises:
a protocol stack, the protocol stack being configured to compile a protocol state for a connection into a compiled protocol state in accordance with a connection transfer command. 31. A host (108 (1)), configured to establish and continue a connection with a client using a connection state inserted in a host network stack, the host comprising:
a connection transfer unit configured to transfer connections to a host;
moreover, the connection transfer unit is configured to intercept the connection state for the connection sent from the load balancing module (106), the connection state including the protocol state and data;
the connection transfer unit is further configured to insert a connection state into the network stack of said module;
the connection transfer unit is capable of implementing the state of the protocol for connecting over the protocol stack of the network stack (3404) and continuing the connection using the inserted connection state. 32. The host (108 (1)) according to claim 31, wherein the connection transfer unit (310) constitutes at least a portion of the load balancing infrastructure (106) located and running on the device. 33. The host (108 (1)) according to p, and the host further comprises:
hosted application
moreover, the connection transfer unit (310) is further configured to transfer the connections to the host in a manner transparent to the application. 34. The host (108 (1)) according to claim 31, wherein the data included in the connection state contains data acknowledged in the load balancing module (106). 35. The host (108 (1)) according to p, in which the block (310) transfer connections contains:
“Laying” (3412) of the transfer unit, which is located above the protocol stack (3404) in the network stack of the host (108 (1)); and
an intermediate driver (3414) of the transfer unit, which is located below the protocol stack (3404) in the host network stack. 36. The host (108 (1)) according to claim 35, wherein:
“Laying” (3412) of the transfer unit is located between the protocol stack (3404) and the level (3402) of the sockets of the host network stack (108 (1)); and
an intermediate driver (3414) of the transfer unit is located between the protocol stack (3404) and at least one miniport (3408) of the host network stack (108 (1)). 37. The host (108 (1)) according to claim 35, wherein:
“Laying” (3412) of the transfer unit is configured to receive notifications from the intermediate driver (3414) of the transfer unit about the transfer loading procedure and is configured to initiate a procedure for implementing a protocol state with a protocol stack; and
the intermediate driver (3414) of the transfer unit is configured to detect the arrival of the connection status for the connection, divert the connection status from the bottom of the protocol stack (3404) and notify the “gasket” (3412) of the transfer unit of the transfer loading procedure. 38. The host (108 (1)) according to clause 35, in which the intermediate driver (3414) of the transfer unit is adapted to de-package the received binary large object (binary blob) (3422), representing the connection state, which contains the connection state for the connection and the identifier ( 3814) the thread corresponding to the connection. 39. The host (108 (1)) according to claim 31, wherein the host further comprises:
a protocol stack (3404), the protocol stack including a Transmission Control Protocol (TCP) layer and an Internet Protocol (IP) layer. 40. The host (108 (1)) according to claim 31, wherein the host further comprises:
a protocol stack (3404), the protocol stack being configured to implement a protocol state for connecting on a protocol stack in accordance with the start of a protocol state implementation procedure.

Images