Levelling network load through connection control

FIELD OF THE INVENTION

This invention relates generally to network load balancing, and in particular, network load balancing via manipulation compounds, for example compounds of the tunneling transfer and / or migration of compounds in conjunction with load balancing at the application level.

BACKGROUND

The Internet has had a profound impact on the relationship and many aspects of life with communication. The Internet provides a quick and relatively simple data exchange between two people or objects (entities). Internet includes many network nodes connected to each other, which enables the transfer of information between them. Some network nodes may be routers that forward packets from one link to another, may be individual client computers may be a private network for a variety of entities (eg, intranet enterprises), etc.

In the case of a private network, and in other cases, the packets arriving at the node or nodes of the Internet, distributed to other nodes in the private network. Such private networks may be formed, for example, from the group of servers, each of which can process the packets coming into a private network. The private network of companies, universities, government agencies, etc. within a short time interval may be numerous packets. To respond in a timely manner and reduce the probability of failure or loss of incoming packets on a private network, you can use multiple servers that can simultaneously handle incoming packets.

Incoming packets are often a request relating to certain information, such as documents, item catalog, Web page, etc. Incoming packets can also relate to a financial transaction between the buyer and seller. The packet communications packages can also be used for other purposes. In any case, the incoming packets are distributed among the various servers in the server group to ensure quick package and / or the organization of complex communication.

Distribution of incoming packets between servers in the server group is often referred to as network load balancing. In other words, the operation of load balancing can be performed over the packages as they arrive at the node or nodes of the Internet, where a node or nodes constitute a private network and / or when they join the private network with the Internet.

Such a load leveling operation is carried out with special equipment, which is located "upstream" to the private network node or nodes connecting a private network with the Internet, and / or which ensures the presence of a private network on the Internet. Physical equipment, which performs a load balancing operation, typically fully duplicated to implement redundancy and improve reliability of the operation of load balancing. To increase the capacity of load balancing operations previous load balancing hardware replace more powerful equipment that repeats the previous load balancing hardware. Thus, the expansion of load balancing is limited to increasing the power of the equipment when it is replaced.

To implement the transaction load balancing equipment typically perform cyclical distribution of incoming connection requests. In other words, the incoming connection requests are distributed to the servers in the server group in a linear, repeating order, wherein the connection request unit is allocated to each server. This cyclic load distribution for compounds typically used regardless of the state of the private network or the nature of incoming connection requests. If a load balancing operation does not extend beyond the cyclic allocation, these other factors are considered only insofar as they can be derived from the network graph, and / or from a private network congestion level.

The publication US 6,427,171 discloses a central processing unit (CPU) of the host serving network protocol stack processing. This stack handling command provides not only for processing of network messages, but also for distributed processing network messages in certain specialized network communication device, whereby some of the pressure on the most time-consuming processing of protocols is transferred from the host CPU to a network communications device. Host CPU operating according to instructions from the stack, and network communication device together determine whether a particular message is processed the CPU host or network communication device, and to what extent it will be processed.

Publication US 2001/0039586 discloses a system for sending a request to the dynamic content to the application server that has access to a database containing updated data relating to the request. The system comprises a router dynamic content replication database and a web server plug-ins. The router manages dynamic content plug-ins implemented web server forwarding the request to the appropriate server application.

Publication 2002.0194342 described switching between applications, taking into account the content and methods that enable intelligent packet forwarding client in one server in the server group, a member of the server farm. Used for switching the content of the seventh-level network model or application, is extracted from the packet by analyzing for assistance in selecting a server for scheduling and transmitting a packet to the server. This allows an optimized load balancing and quality of service adapted to the application in respect of which the switch.

Accordingly, the required circuits and / or methods for improving network load balancing, particularly in systems consisting of a plurality of devices, and / or related operations.

DISCLOSURE OF INVENTION

According to a first aspect of the present invention provides a method according to claim 1.

According to a second aspect of the present invention, a load balancing unit according to item 21 of the claims.

According to a third aspect of the present invention, a host according to item 31 of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

To designate similar and / or corresponding aspects, features, and components in the drawings, like reference numerals are used.

1 - illustrates an exemplary network load balancing, where load balancing infrastructure shown and multiple hosts.

2 - illustrates an exemplary network load balancing, which shows multiple load balancing units and multiple hosts.

Figure 3 - schematic representation of load balancing units having separate functions and the host.

4 - illustrates an exemplary network load balancing infrastructure with separate classification and forwarding.

5 - illustrates an exemplary flowchart expanding network load balancing infrastructure into different configurations.

6 - illustrates an exemplary first configuration of network load balancing infrastructure to those devices.

7 - an exemplary configuration diagram of a second exemplary network load balancing infrastructure to those devices.

FIG. 8A and 8B - exemplary circuit configurations of the first and second exemplary network load balancing infrastructure to components.

FIG. 9A and 9B - exemplary circuit configurations of the first and second exemplary network load balancing infrastructure in terms of resources.

10 - illustrates an exemplary approach to network load balancing with host status information.

11 - an exemplary flowchart of a method for network load balancing with host status information.

12 - illustrates an exemplary approach to network load balancing with health and load information.

13A - exemplary health and load table, designated in Figure 12.

13B - exemplary joint health and load cache indicated at 12.

14 - an exemplary flowchart of a method for network load balancing that involves health and load information.

15 - illustrates an exemplary message protocol for transmission, shown in Figure 12, between the hosts and load balancing units.

16 - an exemplary message transmission scheme for transmission, shown in Figure 12, between the hosts and load balancing units.

FIG. 17A and 17B - illustrative scenarios storage circuit mediator health and load information for health and load tables, shown in Figure 13, and for joint health and load caches, as shown in Figure 13B, respectively.

18 - an exemplary diagram of a procedure for distribution of the target host, which is used in the health and load information.

19 - illustrates an exemplary approach to network load balancing using the session information.

Figure 20 - illustrates an exemplary approach to network load balancing using the information transfer session by notifications and messages.

21 - an exemplary flowchart of a method for network load balancing using the information transfer session by notifications and messages.

Figure 22 - illustrates an exemplary approach to managing session information at multiple load balancing units.

23A - an illustrative table sessions indicated in Figure 20.

23B - an illustrative table (TRDA) Distribution Manager atoms (RDA), presented on 22.

Figure 24 - an exemplary flowchart of a method for managing session information at multiple load balancing units.

Figure 25 - illustrates an exemplary network load balancing infrastructure function with routing requests.

26 - an exemplary flowchart of a method of routing incoming packets, in accordance with (i) session information and (ii) health and load information.

Figure 27 - illustrates an exemplary sequence of routing traffic in the absence of failures.

Figure 28 - illustrates an exemplary sequence for traffic routing in the presence of failure (s).

29 - further illustrates an exemplary failover procedures for improving the reliability of network load balancing infrastructure.

Figure 30 - illustrates an exemplary operational implementation of traffic routing interaction with health and load information.

Figure 31 - illustrates an exemplary high availability mechanisms for network load balancing infrastructure.

Figure 32 - illustrates an exemplary approach to network load balancing with connection migration.

33 - an exemplary flowchart method for transferring compounds from the first device to the second device.

Figure 34 - illustrates an exemplary approach to connection migration from the perspective of the sender device.

Figure 35 - illustrates an exemplary approach to connection migration from the perspective of the destination device.

Figure 36 - illustrates an exemplary approach to the discharge procedure for the transfer connection.

Figure 37 - illustrates an exemplary approach to the download procedure for the transfer connection.

Figure 38 - illustrates an exemplary approach to the tunneling of packets between the sending unit and the host.

Figure 39 - an exemplary flowchart of a method of tunneling packets between a first device and a second device.

Figure 40 - illustrates an exemplary operating environment of the computer (or general device) that is capable of (fully or partially) implementing at least one aspect disclosed herein network load balancing.

THE INVENTION

Network load balancing scheme

This section describes exemplary network load balancing scheme, and it is used to provide principles environments and contexts, etc. To describe in the following sections. This section references generally are 1-3.

1 depicts an exemplary circuit 100 for network load balancing, which shows the load balancing infrastructure 106 and multiple hosts 108. An exemplary diagram of the network load balancing 100 includes multiple clients 102 (1), 102 (2) ... 102 (m) and multiple hosts 108 (1), 108 (2) ... 108 (n), and a network 104 and 106 to load balancing infrastructure.

Each client 102 may be a device capable of network communication, such as a computer, a mobile station, an entertainment appliance, another network, etc. Clients 102 may also refer to a person and / or object, exploiting the client device. In other words, clients 102 may represent logical clients that are users and / or machines. Network 104 may be formed from one or more networks such as the Internet, an intranet, a 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 Figure 40 in the "Exemplary Operating Environment for Computer or Other Device".

Individual clients 102 are capable of binding to one or more hosts 108, and vice versa over the network 104 via load balancing infrastructure 106. Hosts 108 comprise one or more applications to interact / communicate with clients 102, 102 for use by clients, etc. Each host 108 may correspond to the server and / or device, multiple servers and / or multiple devices, part of the server and / or of the device, some combination thereof, etc. The partial realization of hosts 108 are described below with respect to various cases of network load balancing. (However, the support portion is applied to the host 108 for clarity of the invention as substantially not shown). Also with reference to Figure 40 in the section entitled "Exemplary Operating Environment for Computer or Other Device", describes examples of host devices 108.

Load balancing infrastructure 106 is achievable or detectable through a network of 104 on one or more virtual addresses Internet Protocol (IP). Transmissions from clients 102 (or other nodes) sent by the virtual IP-address load balancing infrastructure 106 are received here and sent to the host 108. Load balancing infrastructure 106 comprises hardware and / or software components (not explicitly shown in Figure 1) .

Though infrastructure 106 is shown as a single ellipse, infrastructure for load leveling may also be distributed to other aspects of the exemplary circuit 100 of distribution network load. For example, the program (s) component (s) of load balancing infrastructure 106 may be / may be located in one or more hosts 108, as described below. Examples of architectures load balancing infrastructure 106 are described below with reference to Figure 40 in the section entitled "Exemplary Operating Environment for Computer or Other Device".

According to this numeral (1), one or more hosts 108 can provide status information to the host 108 of hosts 106 to load balancing infrastructure. This status information may depend on the host application. Examples of such host status information are described below and include health and / or load information, session information, etc. for the hosts 108. The specific implementation, including the provision of health and / or load from hosts 108 to load balancing infrastructure 106, described below in the section entitled "Exemplary health and load management."

Reference numeral (2) denotes a request transmitted from the client 102 (1) over the network 104 to load balancing infrastructure 106 in its virtual IP-address. The contents, format, etc. request from the client 102 may depend on the application to which the request is addressed, and the term "query" may implicitly include a response or responses of the host (s) 108, depending on the context. Types of client requests include, but are not limited to:

1. Request GET hypertext transfer protocol (HTTP) from the client using a browser program. Depending on the application (in particular, from the unified pointer (URL) of the resource requests) can better serve the needs of different groups of hosts, and the existence of a client state "session" on host routing can prevent these requests from specific clients for specific hosts. Inquiries can be sent by connecting a working protocol Secure Sockets Layer (SSL) (or other encrypted connection).

2. Virtual Private Network (VPN) (for example, hosts are a group of servers, VPN). In this case, the "request" can be regarded as a "link" protocol tunneling second level (L2TP) or protocol point to point tunneling (PPTP) (the latter being a combination of a compound of the protocol (TCP) communication control and related data common routing encapsulation (GRE).

3. Compounds terminal server (e.g., the hosts are a group of terminal servers).

4. In-house searches in the form of individual TCP-connections (one on request) using a proprietary protocol, depending on the application.

5. Requests for the simple object access protocol (SOAP).

6. Request to communicate in real time, providing control information on TCP-connection and media streaming, latency sensitive protocol (RTF) real-time transmission.

Thus, requests may take a variety of forms depending on the applications. In some disclosed embodiments, load balancing infrastructure 106 may decide to forward depending on the applications.

At (3) indicates that the load balancing infrastructure 106 forwards the request 102 (1) to host 108 (2) (in this example). Load balancing infrastructure 106 may consider one or more factors in the selection of host 108 to forward the request depending on whether / which of the implementations described herein are used. For example, load balancing infrastructure 106 may be considered: the health and load information for each host application 108, session information relating to the client 102 (1) stored on the host 108, etc.

2 depicts an exemplary circuit 200 for network load balancing, which shows multiple load balancing units 106 and multiple hosts 108. In particular, in the exemplary circuit 200 for network load balancing infrastructure 106 is shown as a load of multiple modules 106 (1), 106 ( 2) ... 106 (u) of load balancing. Also shown are two routers and / or switch 202 (1) and 202 (2).

Router / switches 202, if present, can be regarded as part of load balancing infrastructure 106 (Figure 1) or separately from it. Routers / switches 202 are responsible for sending all requests and individual packets from the network 104, the shared (s) for the virtual (th) IP-address (es) (VIP) modules 106, load balancing. In case of failure of the first router / switch 202, it takes over the function of the second switch / router 202. Although shown two router / switch 202 alternatively may use one or more than two router / switches 202.

Router / switch 202 may not know about the infrastructure load balancing or may be aware of load balancing. If the routers / switches 202 are not aware load balancing, you can use one of two options. The first is that one load balancing unit 106 "is assigned to" VIP-shared address, and all network traffic is forwarded to it. Then this one load balancing unit 106 uniformly distributes traffic to other modules 106 to load balancing. However, in connection with the first option problems and issues a recovery point (which may be alleviated if there is a shared multiple-VIP addresses and separation between multiple load balancing units 106). The second option is that the routers / switches 202 "deceived" towards all network traffic load balancing units 106, each of which is independently decides whether to accept the traffic load balancing. However, this second option leads to insufficient duplication and the problems of performance / compatibility switches.

If the router / switches 202 are aware of load balancing, the routers / switches 202 can be made to distribute incoming network traffic among multiple load balancing units 106 (e.g., cycled). It should be understood that such router / switches 202, load-balancing-aware, and can perform the function of load balancing rudimentary (e.g., firmware). For example, routers / switches 202, load-balancing-aware can perform simple identification session affinity-based IP addresses to all packets from a particular IP-source address sent on the same module 106 of load balancing.

Each separately shown load balancing unit 106 from load balancing unit 106 may be the same physical device, multiple physical device or part of a single physical device. For example, the module 106 (1) load balancing may correspond to a single server, two or more servers. Alternatively, the module 106 (1) and a load balancing unit 106 (2) Load balancing may together correspond to a single server. An exemplary load balancing unit 106 is described below in terms of its function, with reference to Figure 3.

2 shows two exemplary ways of [1] and [2] the request. As for the path [1] the request, the client 102 (2) transmits a request over network 104, and this request is received at a router / switch 202 (1). The router / switch 202 (1) sends the package (s) requests from the client 102 (2) on the module 106 (1) load balancing. Then, control unit 106 (1) load balancing sends the packet (s) request to host 108 (1) in accordance with some load-balancing functionality (e.g., policy). As for the path [2] the request, the client 102 (m) transmits a request over network 104, and this request is received at a router / switch 202 (2). The router / switch 202 (2) send the package (s) requests from the client 102 (m), module 106 (u) load balancing. Then module 106 (u) load balancing sends the packet (s) request to host 108 (n) in accordance with some load-balancing functionality. Exemplary load balancing function described below with reference to Figure 3.

3 illustrates an exemplary load balancing unit 106 with the separated functions and a host 108. The exemplary load balancing unit 106 includes seven (7) of the functional blocks 302-314. These functional blocks load balancing unit 106 may be implemented, at least in part, in software. Host 108 includes one or more applications 316. In the exemplary embodiment, load balancing unit 106 includes a forwarder 302, a classifier 304, a request router 306, session tracker 308, connection migrator 310, the control unit 312 and the tunneling processor 314 health and load .

Processor 314 health and load placed on partly hosts 108 and partly on devices of load balancing units 106. Processor 314 monitors the health and load operation and / or the load (or, more generally, the status of) hosts 108 to his health and / or the load can be used for load balancing functions (for example, when making decisions on load balancing). Exemplary implementations processor 314 health and load are described below, in particular in the section entitled "Exemplary Health and load processing."

Session tracker 308 may also be placed partly on the hosts 108 and partly on devices of load balancing units 106. Session tracker 308 monitors sessions established clients 102 to facilitate load balancing functions restoration / continuation of the previously established sessions. For example, some applications support in the host application-specific client session data (which are also a kind of status information). These applications typically expect that clients use the same host for any given session. Exemplary types of sessions include: (i) TCP-connection (which, strictly speaking, is a session); (ii) SSL-session; (iii) a secure IP-session (IPsec); (iv) based on the session cookie HTTP; etc.

Although session tracker 308 is shown as a separate unit in the module 106 to load balancing, session tracking function block 308, session tracking, in reality, can be realized globally. In other words, the affinitized supported by multiple modules 106 to load balancing. Session tracking unit 308 includes a central database and / or a distributed database for storing session information session affinity. Exemplary implementations for session tracking block 308, focusing on a distributed database approach, described below, in particular in the section entitled "Track Session".

Classifier 304 uses the data collected by the processor 314 and supported by health and load and / or session tracking unit 308, possibly in conjunction with other factors to classify incoming requests. In other words, the classifier 304 identifies the destination host 108 for each incoming request from the client 102. Forwarder 302 forwards client requests (and / or packages) in accordance with the destination host 108, the selected classifier 304. Forwarder 302 and classifier 304 are described below in particular the section entitled "Exemplary Approach to Flexible Network Load Balancing" and "Exemplary Classifying, Forwarding, and Request Routing".

Request router 306, as opposed to batch-oriented implementations of forwarder 302 and classifier 304 may act as a proxy for an application operating on the host 108. For example, request router 306 may check TCP-connections analyzed (perhaps partially) each logical request from the client 102 and forward the request to each logical destination host 108. Therefore, each logical request from a client 102 may be directed to a particular host 108, depending on the decisions taken by the router 306 queries. Furthermore, request router 306 may perform pre-processing on the compound (e.g., decrypt SSL) may select the absorption of certain requests (e.g., because the request router 306 maintains a cache of responses), has discretion to modify requests before forwarding them to hosts 108, etc. Exemplary implementations request router 306 are also described below, in particular in the sections entitled "Exemplary Approach to Flexible Network Load Balancing" and "Exemplary Classifying, Forwarding, and Request Routing".

Connection migrator 310 provides first end connections for load balancing unit 106, and then it was transferred to the compound on the host subsequently ended 108. This transfer connections may facilitate load balancing application layer. Connection migrator 310 is capable of transferring the connection from the load balancing unit 106 to the host 108 so that the initial end of the module 106 to load balancing be transparent to the requesting client 102 and the application 316 again terminated the host 108. Block 312 can utilize tunneling encapsulation scheme for tunneling packets that does not introduce excessive stress in each tunneled packet.

Functions of block 312 of the tunneling can also be used in situations that do not involve transfer compound. Also, connection migrator 310 and / or the tunneling unit 312 may be additionally used in embodiments without load balancing. Exemplary implementations connection migrator 310 and 312 described below tunneling, particularly in the section entitled "Exemplary transport compound with Optional Tunneling and / or load balancing application layer."

Any given implementation of load balancing unit 106 may include one or more of the illustrated functions. Although each of the functions of blocks 302-314 is shown separately, it may in fact be linked to the overlap with other functions and / or enter into their composition. For example, classifier 304 may use the health and / or load handler 314 health and load. Also, connection migrator 310 and 312 operate in conjunction with tunneling forwarder 302 and classifier 304. The following describes certain other illustrative overlap and interact.

In the described implementation, host 108 runs one or more applications 316 and provides access thereto. Overall, 316 applications include file delivery programs, program management / server web-sites, remote access, e-mail program, a program of access to databases, etc. In particular, the application 316 may include, but are not limited to, Internet Information Server® (IIS) from Microsoft® Corporation, terminal servers, such as Terminal Server ™ company Microsoft® and firewall products and intermediaries, such as Internet Security and Acceleration Server ™ ( ISA). While specific examples of applications 316 in the previous sentence apply to the products Microsoft, described herein network load balancing is not limited to any specific supplier (s), application (s) or operating (bubbled) system (s).

Suitable for flexible network load balancing

This section shows how the implementation of network load balancing, described in this and other sections, provide a flexible approach to network load balancing. In this section, references are mostly to fig.4-9V.

As noted above, the function of network load balancing can be extended by replacing the first network load balancer second, larger and more powerful network load balancer. Hardware possibility of a second network load balancer repeats all of the hardware capabilities of the first network load balancer with the exception of providing higher capacity. It is an inflexible approach that can be very inefficient, especially when the only sign of network load balancing is to limit the performance and conditioning upgrade the network load balancer.

4 illustrates exemplary network load balancing infrastructure having separated classifying and forwarding functions. Separation of the functions of classification and transfer function represented by classifier 304 and forwarder 302, respectively. Although the functions of classification and forwarding are described below, particularly in the section entitled "Exemplary Classifying, Forwarding, and Request Routing", primary description is given here as an example of the interaction between the functional blocks of the network load balancing infrastructure 108 and hosts.

In a described implementation, forwarder 302 corresponds to a virtual-IP address (VIP) (or addresses) and is an endpoint network for it (them). Forwarder 302 is a relatively low-level component that receives simplified and / or basic political decisions if taken when routing packets to a further or final destination. Forwarder 302 consults the routing table to determine that destination. Classifier 304 fills in the routing table based on one or more factors (e.g., host status information) are described in other sections.

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

Figure 4 illustrates five communication paths (1) - (5). The path (1) passes communications between the client 102 (1) and the delivery unit 302, and the path (5) extends between the connection unit 302 and sending host 108 (1). Path (2) - (4) links extend between forwarder 302 and classifier 304. For simplicity, in this example, compounds associated with the paths (1) - (5) links would be considered HTTP TCP-connections. In addition, load leveling in this example relates to the routing of incoming connections to at least loaded host 108, at least, without any whatsoever explicit consideration of load balancing on the application level.

Road (1) - (5) connection point as forwarder 302 and classifier 304 are aligned one load-TCP HTTP connections from the client 102 (1). In the path (1), client 102 (1) initiates the TCP-connection, sending a TCP SYN packet, addressed by VIP-address. Infrastructure 104 routes the network routes the packet to forwarder 302 via a router / switch 202 (1), which is the "closest" router / switch 202 to block 302 of delivery.

In the path (2), forwarder 302 consults the routing table that may be internal to the delivery unit 302 or otherwise accessible to him to find the connection. This compound can be identified in the routing table ordered quadruple TCP / IP (ie IP-source address, TCP-source port, destination IP-address, TCP-destination). Since this is the first packet of the connection, the routing table no element. Therefore forwarder 302 applies the action of "default route," according to which it is necessary to send the package to the classifier 304.

In the path (3), classifier 304 checks with its (e.g., combined) cache host status information for hosts 108 (1), 108 (2) ... 108 (n). Classifier 304 concludes that host 108 (1) is available and the latter is loaded by the host 108 at this point in this example. Classifier 304 also "paving" the route in the routing table, which is referred to forwarder 302 for this TCP-connection. For example, the classifier 304 adds an element of the route or directs delivery unit 302 to add an element of the route in the routing table that maps TCP-connection (e.g., identified by an ordered quadruple TCP) to a particular destination host 108, which in this example is host 108 (1). In particular, the element of the route specifies the network address of host H1 108 (1).

On the way (4) classifier 304 sends a SYN TCP packet back to the forwarder 302. Alternatively, the classifier 304 can forward the initial TCP SYN packet to host 108 (1) without the use of forwarder 302. Other options available to the classifier 304 are described below.

On the way (5), forwarder 302 may access the route entry for the compound represented by SYN packet, to send a packet to host 108 (1) at H1. Forwarder 302 also forwards all subsequent packets from client 102 (1) for the connection directly to the host 108 (1). In other words, the forwarder 302 may prevent further interaction with classifier 304 for this connection. To remove the element of the route at the end of the compound can be used one or more mechanisms described below.

With regard to the path (5), in many environments protocols forwarder 302 can not simply send the packets from client 102 (1) as it is to host 108 (1) to the network address H1, as these packets are addressed by VIP-address, which is hosted by forwarder 302. Instead, the forwarder 302 may use one or more of the following exemplary options.

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

2. Forwarder 302 performs a "semi-TCA," writing instead of IP-addresses (VIP) destination IP-address (H1) of the host (108 (1)), which allows you to save the IP-address (C1) and the source port number (the customer 102 (1)).

3. Forwarder 302 "tunnels" packets received from the client 102 (1) from forwarder 302 to host 108 (1). In particular, in this example, the tunneling may be performed by encapsulating each packet to a new IP-packet that is addressed to host 108 (1). Software balancing-aware network load on the host 108 (1), reconstructs the original packet upon receipt at the block 302 of delivery client 102 (1). Then, the source packet indicated on a virtual interface at host 108 (1) (e.g., VIP-address corresponding forwarder 302, is tied to the virtual interface at host 108 (1)). Exemplary implementations of such tunneling are described below with reference to block 312 of tunneling, especially for scenarios transport compound and, in particular, in the section entitled "Exemplary transfer connections Optional Tunneling and / or load balancing application layer."

Although FIG. 4-9V comma shows two specific functions, namely, classification of mail, and it should be understood that other functions, such as router 306 query session tracking unit 308, connection migrator 310 and processor 314 health and load can also expand independently ( for example, independently increased proportionally) as described below. Furthermore, it should be noted that more than one or two functions can be separated and independently extend in different times and / or simultaneously. Moreover, although, for clarity, in many instances in this and other sections using TCP / IP, the principles described herein for network load balancing is applicable to other communication protocols and / or communication.

According to the example shown in Figure 4, the function of network load balancing (e.g., as shown in Figure 3) can be separated from each other to expand. They can also be separate and duplicated in different configurations to improve reliability. Illustrative configurations for scalability and / or reliability are described below with reference to the following description of a method fig.6-9V with reference to Figure 5.

5 shows a flowchart of an example method 500 expanding network load balancing infrastructure into different configurations. Flow diagram 500 includes three blocks 502-506. Although the actions of flow diagram 500 may execute in different environments by a variety of software schemes, FIGS. 6-9V and 1-4 are used in particular to illustrate certain aspects and examples of the method.

At block 502, the network load balancing infrastructure is operated in the first configuration. For example, each configuration can apply to one or more of the in Highlighted, proportions and / or the relationship between the different functions of load balancing; a number and / or type (s) of the various devices; to the organization and / or pattern of the various components; for distribution and / or allocation of resources; etc. At block 504 being expanded network load balancing infrastructure. For example, some functions of load balancing can be expanded and / or agreed to contract on an individual and / or independent basis. At block 506, the extended network load balancing infrastructure is operated in the second configuration.

As noted above, the monolithic load balancer network can be expanded by increasing all network load balancing functions by replacing the previous load balancing hardware more powerful network load balancing hardware. In contrast, expansion of network load balancing infrastructure may enable individually and / or independently expand (sub) function of network load balancing. This may also allow to extend the function of network load balancing together or separately between different quantities of devices. The following examples concerning expansion devices, components and resources.

6 shows a first configuration of the network load balancing infrastructure to those devices. In this first configuration, network load balancing infrastructure-oriented device shows three devices 602 (1), 602 (2) and 602 (3). However, alternatively, it is possible to use one, two, or more than three devices 602.

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

During operation forwarder 302 are endpoints for VIP-address (es). Any classifier 304 may plumb a route for a connection to any host 108, depending on host status information. For example, classifier 304 (2) may plumb a route for a new incoming connection to host 108 (3). In accordance with a new route entry for this connection, forwarder 302 (2) forwarding forwards these packets to host 108 (3).

In one alternative configuration, network load balancing infrastructure in respect of devices which can be expanded first configuration, can be added to the fourth device 602 (4) (not explicitly shown in Figure 6), which comprises a block 302 (4) forwarding classifier 304 (4) and host 108 (4). If sufficient classification functions already present classifiers 304 (1-3), but additional functions may contribute to processing requests to host 108 can be added to the fourth device 602 (4), which comprises a block 302 (4), Shipment and optionally , host 108 (4). For this extended configuration other classifier 304 (1, 2, or 3) may plumb a route for the block 302 (4) forwarding to any of hosts 108 (1, 2 or 3) and host 108 (4), when available.

The first configuration of network load balancing infrastructure-oriented device, the image 6 can be particularly suitable for hosting a smaller situations in which a device for separate network load balancing infrastructure are not technically and / or economically giving adequate results, or viable. However, when the load hosting expands to a larger amount (and / or a greater need for the same number) of hosts 108 or if the network load on the host 108 is significant, the first configuration of the network load balancing infrastructure-oriented device may be mapped to accommodate this expansion represented by a second configuration of network load balancing infrastructure-oriented device shown in Figure 7.

7 shows a second configuration of a network load balancing infrastructure to those devices. In this second configuration, network load balancing infrastructure-oriented device, also shows three devices 602 (1), 602 (2) and 602 (3). Again, illustratively, may be used one or two or more than three devices 602.

It is shown that the device 602 (1) were present and performed 302 (1) Shipping and classifier 304 (1). On the device 602 (2) there are 302 (2) Shipping and classifier 304 (2). In addition, the device 602 (3) contains 302 (3) Shipping and classifier 304 (3). Thus, in this second configuration, network load balancing infrastructure-oriented device, each respective forwarder 302 and classifier 304 are not sharing the resources of each respective device 602 to the host 108. Moreover, network load balancing infrastructure can support any number of hosts 108.

During operation forwarder 302 again are the end points for VIP-address (es). In addition, any classifier 304 may plumb a route for a connection to any host 108, depending on host status information. For example, classifier 304 (3) may plumb a route for a new incoming connection to host 108 (2). In accordance with a new route entry for this connection 302 (3), Shipment forwards subsequent packets to host 108 (2).

Therefore the network load balancing infrastructure, implemented in software, it is possible to expand the moving network load balancing infrastructure (or portion thereof) with devices used in conjunction with the host 108 to devices that are not shared with hosts 108. In addition, according to the above with reference 6, to the network load balancing infrastructure can add another device 602 (4) to provide additional functions of delivery, additional functions of classification, additional features of both types, etc.

FIG. 8A and 8B show the configuration of the first and second exemplary network load balancing infrastructure to components. It shows that the first component-oriented configuration 800 network load balancing infrastructure comprises four components. The second component-oriented configuration 850 network load balancing infrastructure comprises six components. Alternatively, the second configuration 850 - seventh component designated unit shown by the dotted line, which will be described below.

In particular, first component-oriented configuration 800 network load balancing infrastructure (or first configuration 800) includes (i) two blocks 302 (1) and 302 (2) Shipping and (ii) two classifier 304 (1) and 304 (2) . The second component-oriented configuration 850 network load balancing infrastructure (or second configuration 850) includes (i) four blocks 302 (1), 302 (2) 302 (3) and 302 (4), Shipment and (ii) two classifier 304 ( 1) and 304 (2). Thus, the first configuration 800 is expanded to the second configuration 850 by adding two components, which in this example are components of delivery.

In the described implementation, each functional component related to the network load balancing, corresponding respectively to the device (not explicitly shown in FIGS. 8A and 8B); however each component may alternatively correspond to parts of the device or more than one device. For example, blocks 302 (1) and 302 (2) delivery may be distributed across three devices. In another case, 302 (1), Shipment and classifier 304 (1) may correspond to the first device, and 302 (2) Shipping and classifier 304 (2) may correspond to the second device.

To expand the first configuration to the second configuration 800 850 Two additional functional components relating to network load balancing. However, to expand the network load balancing infrastructure could alternatively add a single component (or two). Furthermore, one can "simultaneously" extend two or more different types of functional components. For example, when expanding the first configuration to the second configuration 800 850 it is also possible to add another component labeling (e.g., classifier 304 (3)), designated block shown by a dotted line.

Furthermore, expansion of two or more different types of functional components can be performed in such (e.g., equivalent) or dissimilar proportions to each other. It is shown that the addition of components 302 (3) and 302 (4) without adding any component of the labeling or 304 with the addition of 304 of one component (3) is widening in the labeling of dissimilar proportions. However, the expansion in such proportions by adding the two components 302 (3) and 302 (4) forwarding the two components can be added 304 (3) and 304 (4) classification (the latter case is not shown explicitly in Figure 8B). Nevertheless, different functional components related to network load balancing may consume different amounts of available resources, network load balancing infrastructure that described with reference to FIG. 9A and 9B.

FIG. 9A and 9B show the configuration of the first and second exemplary network load balancing infrastructure in terms of resources. First resource configuration 900 oriented network load balancing infrastructure (or first configuration 900) includes a first distribution or resource allocation unit 106 for load balancing. Second resource configuration 950 oriented network load balancing infrastructure (or second configuration 950) includes a second allocation or a resource allocation unit 106 for load balancing.

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

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

In the illustrated case, the first configuration 900 is designed to increase network load balancing performance when appropriate hosts (not shown in FIGS. 9A and 9B) is treated with minimal number of longer transactions as classification functions are used after the initial connection for the connection, and forwarding functions are used afterwards. The second configuration 950, by contrast, is designed to increase network load balancing performance when appropriate hosts treated with a larger number of short transactions, since the function used for the labeling of a greater percentage of total number of packets tunneled through the network load balancing infrastructure. In this case also used routing queries, the router (s) 306 requests as a percentage of total allocated computing resources. The allocation of resources between the three functions can be adjusted during the connection processing (e.g., to adjust "on the fly") depending on the current consumption and / or resource scarcity.

Referring to FIG. 2 and 3, each load balancing unit 106 may correspond to the entire infrastructure 106 full network load balancing or part thereof. For each of the physical, logical, arbitrarily, etc. predetermined or specified load balancing unit 106 it is possible to re-allocate resources through the expansion procedure. In particular, the distribution of resources between the different separated functions related to network load balancing, load balancing unit 106 can be varied by extension procedure. Furthermore, more than two different functions, and other functions related to network load balancing that are not specifically shown in FIG. 9A and 9B, it is possible to allocate varying percentages of resources.

The percentage of total system resources allocated all the functions of load balancing, can also be changed by the procedure extension. As an example, the total percentage of the total processing power of computing power allocated for load balancing, you can gradually increase with the increase in traffic, for which the need to perform load balancing.

Software for network load balancing may, optionally, be monitored in order to analyze and determine whether perevydelyat resources. For example, software for network load balancing may monitor CPU usage various functions related to network load balancing. The actual reallocation may also optionally be performed automatically by software network load balancing in offline or online.

It should be understood that the extended capabilities described herein, network load balancing infrastructure (e.g., implemented at least partially in software) can refer to different installations and not necessarily to a change in one setting. The resource-oriented example described here the network load balancing infrastructure may be configured in accordance with an allocation of resources in a single installation environment and can be configured in accordance with another resource allocation in another installation environment having different operating parameters. Additional capabilities, features, options, and so on., As described above with respect to expansion are also applicable to the narrowing. In other words, the resources allocated to network load balancing infrastructure (or sub-functions) can also be reduced.

Treatment of health and load

This section describes how to host status information, such as health and / or the load can be collected for network load balancing, and use it. This section links are primarily at fig.10-18 and covers functions health and load, for example, provided by processor 314 health and load (3). As described above with reference to Figure 3, each host 108 the hosting one or more applications 316. Processor 314 uses the health and load information, health and / or load information relating to the applications 316 and / or host 108 for certain described implementations of network load balancing.

10 shows an approach for network load balancing with host status information 1006 (ORG). Each host 108 (1), 108 (2) ... 108 (n) includes one or more applications 316 (1) 316 (2), ..., 316 (n), respectively. These hosts 108 as a whole and these applications 316 in particular can from time to time to change the status.

For example, hosts 108 and application 316 can accept new connections or not to accept new connections. In addition, they can quickly process client requests or slow to process client requests. In addition, they may have a lot of resources in a reserve or little unused resources. All or part of such data, or other data may contain status information 1006 of the host. In general, host status information 1006 provides an indication of the status of some aspect of the host 108 and / or applications running on them 316.

In the described implementation, each host 108 (1), 108 (2) ... 108 (n) includes a determiner 1002 (1) 1002 (2) ... and 1002 (n), host status information (HOME), respectively. Each host 108 (1), 108 (2) ... 108 (n) also comprises a circulator 1004 (1) 1004 (2) ... and 1004 (n), respectively, host status information (HOME). Each determinant of host status information 1002 and / or retailer host status information 1004 may be part of load balancing infrastructure 106 (IVN).

Each determinant of host status information 1002 specifies the host status information 1006 for the respective host 108 and / or acting on the applications 316. Exemplary methods for determining such host status information 1006 are described below with reference to 12-14, and in particular, FIG. 13A. Each distributor 1004 host status information 1006 disseminates host status for the respective host and / or application 316 to load balancing infrastructure 106 (for example, that / those of the / of the load balancing infrastructure 106, which are not located on the host 108). The illustrated propagation methods such host status information 1006 are described below with reference to 12-17, and in particular, FIG. 13B and 15-17.

In particular, each distributor 1 004 state information of the host distributes status information 1006 of the host (directly or indirectly) to each load balancing unit 106 (MRI), load balancing infrastructure 106, which includes at least one processor 314 health and load and / or classifier 304. Load balancing infrastructure 106 refers to the status information 1006 of the host when network load balancing implementation. For example, as indicated by logic 1008, load balancing infrastructure 106 is able to decide on load balancing in accordance with the status information 1006 of the host.

In step (1) operation status information 1002 qualifiers determine host status information 1006 for the respective host 108 and / or applications 316. In steps (1) and (2) the distributors host status information 1004 status information 1006 propagate host of hosts 108 in the infrastructure 106 load balancing. For example, host status information 1006 may be distributed in the individual modules 106 to load balancing. In step (3) logic 1008 decides on network load balancing in accordance with the status information 1006 of the host. In step (4) compounds are forwarded to the destination host 108 on the basis of these decisions on network load balancing.

11 is a flowchart of a method 1100 for network load balancing with host status information. Flow diagram 1100 includes three blocks 1102-1106. Although the actions of flow diagram 1100 may be performed in other environments and by different software schemes, FIGS. 1-3 and 10 are used in particular to illustrate certain aspects and examples of the method.

At block 1102, host status information sent from the host to load balancing units. For example, host status information 1006 may be sent from the host 108 to load balancing units 106. At block 1104 is received host status information from the host to load balancing units. For example, load balancing units 106 receive host status information 1006 from hosts 108. At block 1104 decisions for load balancing based on the received host status information. For example, logic 1008 to load balancing units 106 may decide on network load balancing in accordance with the status information 1006 of the host.

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

12 illustrates an approach to equalization network load information 1206 health and / or load information (IRN). Hosts 108 (1), 108 (2) ... 108 (n) are connected to the modules 106 (1) 106 (2) ... 106 (u) Load balancing through connection means 1210 such as a network.

It is shown that the host 108 transmit information to health and load information 1206 for load balancing units 106 using the connection means 1210. Bidirectional transfer information 1206, health and load, indicated by arrow duplex refers to a two-way communication between the load balancing unit 106 and hosts 108, which provides a certain fullness, coherence, accuracy, etc., whereby the host 108 and / or balancing units 106 load may refuse independently. Such bilateral communication between the load balancing unit 106 and hosts are described below with particular reference to Figure 15.

Information reflects the performance capable (but) whether the (th) host and / or application to process client requests. Information load refers to the number, size and / or the level of client requests that a particular point in time is able to (but) the process (th) host and / or application. In other words, the load is directly or inversely reflects the available number, size and / or the level of the full capacity of the host and / or application. As noted above, implementations described with reference to fig.12-18, focusing on health and / or load; However, these implementations are also applicable to general status information for the hosts (including applications).

In the described implementation, each host 108 (1), 108 (2) ... 108 (n) includes a respective component 1202 (1) 1202 (2) ... 1202 (n) health and load infrastructure (IRIN). Each component 1202, health and load infrastructure may optionally be part of load balancing infrastructure 106, which is located and executed on each host 108. Information 1206, health and load can be realized by software. In operation, each infrastructure 1202 (1) 1202 (2) ... 1202 (n) creates and maintains a table 1204 (1) 1204 (2) ... 1204 (n) health and load information (RIN).

Tables 1204 and loads may include elements, depending on application. Information 1206 health and load tables 1204 stored in health and load can be independent of the load balancing infrastructure 106. For example, administrators, designers, etc. can specify criteria for the data in 1206, health and load during setup. Additionally, elements external to the device that is a host 108, or it contains, can assist in determining information 1206, health and load applications 316 on the device. An exemplary table 1204, and the load is described below with reference to Figure 13A.

Each module 106 (1) 106 (2) ... 106 (u) load balancing includes a respective combined cache 1208 (1) 1208 (2) ... 1208 (u) health and load information (RIN). Each Joint cache 1208 and comprises a load information from each table 1204 (1) 1204 (2) ... 1204 (n) health and load. Therefore, each module 106 provides a fast load balancing (such as cached) access to information, in 1206 the health and load 108 for each host for which load balancing units 106 equalize the load of network traffic.

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

13A shows a table 1204, and the load indicated in Figure 12. In a described implementation, table 1204 and the load 1302 comprises multiple elements, each of which is associated with a separate application 316. Each entry 1302 may correspond to a row in the table 1204 and the load which has three columns. These columns correspond to the identifier (ID) 1302 (A) application, characterization 1302 (B) the status of the application and directive 1302 (C) load balancer.

Since 1302, each element is associated with a particular application 316, every time you start (for example, administrator) applications are added line. Similarly, whenever the application is closed there is a destruction / removal line. Similarly, individual fields in columns 1302 (A), 1302 (B) and / or 1302 (C) are changed / updated when their values. For example, when the value of the characteristics of the status for the application 316, the value of 1302 (V) characteristics fields for the status of the application member 1302 of the application 316 is updated.

Add and remove items in 1302 to 316 applications can be implemented using the input information from the Control Manager on the host 108. For example, Control Manager of the operating system knows when the application 316 starts and stops working because it is actively involved in starting and stopping the application manager 316. Therefore, control may indicate that it is at least partially running the application 316, and control manager may determine that it is at least partially stopped by the application 316. Thus, the controller may inform the management infrastructure 1202, health and load on starting and stopping Application 316 therefore does not need to provide explicit data from applications 316 infrastructure 1202, health and load. An example is the Control Manager Manager (CRS) service management Windows® operating system from corporations Microsoft®.

Identifier 1302 (A) of the application contains information used to uniquely identify the application 316 is associated with element 1302. The identifier 1302 (A), the application may contain one or more of the following for the associated application 316: a virtual-IP address and port, a physical IP- address and port used by the protocol and any information related to the protocol. The protocol can act as HTTP, IPsec, SOAP, etc. As the information related to the protocol can be a pattern or string of URL for additional guidance application associated with element 1302. Thus, the identifier 1302 (A) applications and more particularly relates to an end point of the application 108 on a specific host.

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

Characteristics of 1302 (B) the status of the application contains information reflecting the status of the application 316 is associated with the element 1302. Feature 1302 (B) the status of the application includes the following for the associated application 316: performance applications, application load and capacity of applications. Application health is a quasi-Boolean value that indicates whether an application. The efficiency of the application can be set to "workable", "inefficient" and "unknown". Application health - is relatively instantaneous value which is transmitted with a relatively small delay (e.g., on the order of a second or few seconds) to load balancing units 106 when the value of the application operation.

The load application - is a value that indicates whether the application is loaded or busy, and thus, directly or inversely, much additional load the application can process. Load the application - this is a relatively slow change or average value, which, if desired, can be smoothed through the mechanism of excitation hysteresis to eliminate transient peaks increasing or decreasing load. It is transferred to load balancing units 106 are relatively rare (e.g., one to four times per minute). The value of load application makes sense in relation to the container application.

Capacity applications - is a value indicating the maximum capacity applications. It is chosen by a general method, that it makes sense for this context, but it was still sufficiently flexible to other contexts. Capacity applications - a dimensionless quantity, which has a limited range of values ​​(eg, 0-99), which can be defined during configuration. It may depend on the processing power, size / speed memory access network, some combination thereof, etc. Capacity application expresses the relative capacitance between the other applications of the same type in a group of hosts 108 (1, 2, ..., n).

Thus, the load application makes sense with respect to the container application. Load applications for this application - is the percentage of capacity applications for the application. Alternatively, the load application may be expressed dimensionless quantity, from which you can get a percentage of the value of the involvement of capacity applications.

Directive 1302 (C) load balancer comprises information reflecting a desired and / or expected state directive 1202 installed infrastructure efficiency, and load module 106 with respect to load balancing application 316 is associated with element 1302. The directive 1302 (C) contains a load balancer include the corresponding application 316: a target load balancing state and the current load balancing state.

The target load balancing state directive reflects the state of load balancing unit 106 in accordance with an indication of capacity and infrastructure in 1202 Load. The current load balancing state reflects what infrastructure 1202 health and load understands what should be the guideline for the current state of load balancing unit 106, recorded in the load balancing unit 106. The current load balancing state, thereby reflecting the directive to load balancing, which is expected infrastructure 1202, health and load, currently operate to load balancing units 106 in accordance with the communication protocol being used. Such exemplary communication protocol described with reference to Figure 15. The interaction between the target and the ratio of load balancing state and the current load balancing state is also further explained in the description of Figure 15.

The target load balancing state as the current state of load balancing can be set to "active", "inactive" or "draining." Directive "active" indicates that new requests / connections can come and sent the application associated with the element 1302. The Directive "inactive" indicates that no additional packets are not be forwarded to the appropriate application. Directive "dwindling" indicates that no packets for new requests / connections can not be sent to the appropriate application, but existing package requests / connections should continue to be forwarded to the appropriate application.

In the described implementation, the final version information 1206, health and load tables 1204 stored in health and load placed on each respective host 108 from multiple hosts 108. In this embodiment, if the host 108 breaks down, information 1206, health and load, which is lost, provides to applications 316 that are also destroyed. Thus, a high degree of reliability is achieved automatically, without duplicating data. However, the final version information 1206, health and load can alternatively be stored elsewhere. Other such storage options include own load balancing units 106, host 108, which (as a separate task or together with problems hosting) stores and maintains information 1206, health and load for multiple others (including all others) hosts 108, other individual and / or external devices, etc.

If the final version information 1206, health and load stored and maintained in a place other than that it is distributed between the hosts 108 (1, 2, ..., n), then this information 1206, health and load may be stored redundantly (for example, also be stored in duplicate devices are redundantly copied etc) in order to improve reliability. Illustrative Operation Scenarios for storing information 1206, health and load are described below with reference to FIG. 17A and 17B. 17A shows a scenario Operation for tables 1204 and loads and 17B shows a scenario for combined Operation health and load caches.

Figure 13B depicts the combined cache 1208 and the load indicated in Figure 12. In the described implementation, each unified cache 1208 and the load in each load balancing unit 106 comprises at least a portion of the information stored in each table 1204 and load infrastructure 1202 for each health and load information for each host 108. The cached health and load information It can be arranged in any manner in the combined cache 1208 and load.

It is shown that the combined cache 1208 and the load includes a cache for each host 108 (1), 108 (2) ... 108 (n), which is partially or completely duplicated information table 1204 and loads each respective host 108 (1, 2 , ..., n). In particular, the combined cache 1208 includes a cache and load the host number 1 1304 (1), the cache number to the host 2 1304 (2), ..., a cache for host 1304 n number (n). Thus, the illustrated combined cache 1208 and load organized at a broad level by host 108 (1, 2, ..., n), wherein each individual cache 1304 contains elements that depend on the application for the respective host 108 (1, 2, ..., n ). Alternatively, a combined cache 1208 and the load can be organized at a broad level by the type of application with the blocks 316, directed to a specific type of application, additional division by host 108 (1, 2, ..., n). It is also possible to use other data structure formats.

14 shows a flowchart of a method for network load balancing that involves health and load information. Flowchart 1400 comprises eight blocks 1402-1416. Although the steps for flowchart 1400 may be performed in other environments and by different software schemes, FIGS. 12-13V and 1-3 are used in particular to illustrate certain aspects and examples of the method. For example, the action of the two blocks 1402-1404 are performed by the host 108, and the actions of six blocks 1406-1416 are performed to load balancing unit 106.

At block 1402, a determination health and load information on the host. For example, infrastructure 1202 (2) health and load information 1206 may receive health and load applications 316 (2) and stored in the table 1204 (2) to host 108 (2). At block 1404 a specific health and load information sown in load balancing units. For example, infrastructure 1202 (2) health and load information 1206 may send a health and load applications 316 (2) units 106 (1, 2, ..., u) to load balancing. Arrow 1418 indicates that the actions of blocks 1402 and 1404 are repeated, which allows to continuously monitor the performance and load (applications), and update them when changes occur.

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

The dashed arrow 1422 indicates that the load balancing units 106 are treated as transmissions from client 102 simultaneously treating health and load information. At block 1410 the packet is received requesting a new connection. For example, the module 106 (1) load balancing may receive TCP SYN packet from the client 102 (2) over the network 104. At block 1412 a reconciliation is performed to the cached health and load information. For example, the module 106 (1) load balancing can check with the combined cache 1208 (1) health and load. In particular, the module 106 (1) load balancing may consult the elements associated with the application, which is addressed to TCP SYN packet, according to caches 1304 (1, 2, ..., n) for hosts №1, №2, ..., №n.

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

Reconciliation to the cached health and load information (at block 1412) and the choice of the host according to the cached health and load information (at block 1414) may be performed to obtain a particular request packet, a new connection and / or using a multicast scheme. Furthermore, the choice can be made by any of numerous schemes. For example, the marker may be used, or a circular pattern. When any selection scheme may involve the weighing of the relative loads among the application options. These verification and selection marker together with a circular pattern and are described below with reference to Figure 18 in the section entitled "Exemplary Classifying, Forwarding, and Request Routing", particularly in connection with the functions of classification.

After selecting a destination host on the block 1414 it is possible to send a packet requesting a new connection. At block 1416 the packet received from the client is sent to a selected host. For example, a TCP SYN packet sent from the module 106 (1) load balancing on the selected host 108 (2). Shipment of the initial packet may be directly or classifier 304 forwarder 302, which is also described below in the section entitled "Exemplary Classifying, Forwarding, and Request Routing".

In considering the implementation of infrastructure 1202 health and load placed on multiple hosts 108 and divided between them, and also placed on the load balancing unit 106 (as represented by processor 314 health and load). Infrastructure health and load 1202 has three functions. First, it opens a point (and) listen for updates to the status of the application characteristics of 1302 (B) the status of the application table 1204, and the load. Secondly, it synthesizes the application status information to determine what should do load balancing units 106, which is embodied in the directive 1302 (C) load balancer. Third, the infrastructure 1202, health and load transfers this directive from hosts 108 to load balancing units 106.

Legislative content of the directive 1302 (C) load balancer is effectively classified version information for the characteristics of 1302 (B) the status of the application. However, load balancing units 106 may also take raw information characteristics of 1302 (B) the status of the application as well as the treated directive. Transfer the contents of those fields and other tables 1204 and the load is carried out using a messaging protocol, which is described below with reference to Figure 15.

15 is a messaging protocol 1500 for transmissions relating to health and load information, designated 12, between hosts 108 and load balancing units 106. In general, the mechanism governing the events used to transfer changes in tables 1204 and load from hosts 108 to load balancing units 106. In other words, for a described implementation, the information transmitted from hosts 108 to load balancing units 106 when updating the tables 1204 and load. This avoids sending the snapshot all tables 1204, and loads and thus reduce the consumption of network bandwidth infrastructure 1202, health and load.

Messaging protocol 1500 may be implemented using existing messaging engine. Such mechanisms include reliable broadcast mechanism, two-point transmission (eg, User Datagram Protocol (UDP)), etc. It is shown that in 1500 messaging protocol contains seven types of messages 1502-1514: Post 1502 "pulse" Post 1504 "goodbye" message 1506 "change line" Post 1508 "to get a snapshot of the table," Post 1510 "send table snapshot "Post 1512" postulate table state "and the message 1514" postulated a mistake. "

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

Message 1502 "pulse" indicates that a particular host 108 operates, and provides some control of errors for the contents of the corresponding table 1204, and the load in respect of a particular cache for a particular host 1304 in the combined cache 1208 and load. Each infrastructure 1202 performance and load on each host 108 sends a "pulse", directly or indirectly, in each cache 1208 and the load on each load balancing unit 106.

Posts 1502 "pulse" solve the problem of stale data in unified caches 1208 and the load, which occurs partly due to the fact that a snapshot of the entire table 1204, and no load is periodically transmitted to each load balancing unit 106. Scheme messaging 1502 "pulse" is described below with reference to Figure 16.

Posts 1502 "pulse" includes an identifier for the host, error checking data, and optionally a DNS name. Host ID may be a unique (32-bit) binary number selected during configuration. Error control data may represent the checksum, the sequence number status change, the generation number, and a CRC value, etc., which allow the receiving load balancing unit 106 to make sure that the contents of its unified cache 1208 and the load agrees with the contents of the table 1204, and load transmitting host 108. In the case of the generation number, you can use multiple IDs generation, each generation ID assigned "pieces" of applications. Then the message may refer to a room or a couple of pieces of piece number / ID generation, depending on the context.

These error control (or, more generally, an indicator of the content) can be a single value for the entire table 1204 and load, and may represent multiple values ​​determined for each element 1302. Optionally, the DNS name may be transmitted (e.g., every " x "" shock pulse ") to check or update the current correct network address of the host.

Message 1504 "goodbye" is transmitted from a particular host 108 to load balancing units 106 to indicate that a scheduled shutdown particular host 108. Message 1504 "goodbye" includes a host identifier, which can be indexed / displayed on the network address for the particular host 108. Message 1504 "goodbye" is used to clean, intentional disconnections hosts 108 to determine "fast clean". However, in case of loss of communication in 1504 "farewell" caches in the end behind the elements of a particular host 108 posts since 1502 "pulse" is no longer transmitted.

Message 1506 "line change" is transmitted from a particular host 108 to load balancing units 106 to indicate that the performance and load of the particular host application 316 108 has changed. Message 1506 "change line" includes a host identifier, the application identifier, and operation data for the operation. Illustrative host IDs described above in connection with reports in 1502 "heartbeat" messages in 1504 and "goodbye." The illustrated application IDs described above in connection with the ID 1302 (A) application element 1302 associated with the application tables of 1204 and load.

Operation change line can be add, delete, or update. In other words, data can be added to the operation (operation to add) or replaced (for refresh operation) the information already present in the combined caches 1208 and load modules 106 to load balancing. For the delete operation does not provide any data. 1500 messaging protocol is set so that for one message 1506 "change line" may be provided for the execution of multiple operations. Therefore, for a particular host ID of the application identifier sets, operations and data operations may be repeated for multiple applications 316 of the host 108, the host identified specific identifier.

Message 1508 "get table snapshot" is transmitted from a particular load balancing unit 106 for a specific unified cache 1208 and the load on a single host or hosts 108 108. This message 1508 "get table snapshot" requests the infrastructure 1202, health and load on the hosts 108 providing corresponding table 1204, and the load for the respective host 108. This message includes an identification of a requesting load balancing unit 106 and can be used to load balancing unit 106 (i) after failure and subsequent recovery; (ii) after the host 108 experienced a failure, restore and re-launched in 1502 to send messages to "pulse"; (iii) if a message 1506 "line change" is sent to load balancing unit 106, but the message is lost, resulting in a desynchronization between the cache 1208 and load the appropriate table 1204 and the load for the respective host 108; and (iv) etc.

For the case of (iii) loss of synchronization between the cache 1208 and the load, and the appropriate table 1204 and the load for the respective host 108 is detected by a subsequent message 1502 "pulse" from the respective host 108 as "control error" indicates that the combined cache 1208 and Load out of date. Then, load balancing unit 106 sends a message 1508 "to get a snapshot of the table", allowing it to update its 1208 combined cash and the load. Thus, in any of the three illustrative cases (i, ii, iii) load balancing unit 106 then restores its combined cache 1208 and loads 1508, with using a "get table snapshot." Message 1508 "to get a snapshot of the table" can be repeatedly sent to each host 108 in two-point mode, or can be sent once on multiple hosts 108 in the broadcast mode.

Message 1510 "send table snapshot" is sent from a particular host 108 to a particular load balancing unit 106 after the host 108 has received a separate message 1508 "get table snapshot" of a particular load balancing unit 106, as indicated by arrow 1516. The contents of the message 1510 "send table snapshot" prepared infrastructure 1202, health and load, and may include all or at least plural rows of the table 1204, and the load for the individual hosts 108 that allows a specific load balancing unit 106 to restore its combined cache 1208 and load. 1510 Message "to send table snapshot" can be constructed separately or message may be equivalent to the sequence of operations in 1506 added to the message "change line".

Message 1512 "postulate table state" and the message 1514 "postulated error" refers to the target load balancing state and the current load balancing state directive 1302 (C) 1302 load balancer element table 1204 and load. The target load balancing state - this directive, according to which should work load balancing units 106 according to the 1202 request of infrastructure capacity and load. The current load balancing state - this instruction, according to which the currently working modules 106 to load balancing infrastructure according expectation 1202, health and load. In general, two identical load balancing state.

However, the target load balancing state may differ from the current load balancing state of transitional change state directive. Suppose, for example, the target load balancing state and the current load balancing state initially set active. If a problem with the host 108 and / or application 316 directive load balancing state is changed to "draining". This directive is "draining" is transmitted to the load balancing units 106 posts in 1506 with "change line".

While this directive will change noted in all caches combined 1208 and load all the load balancing unit 106, there is a delay. During this transitional period, the target load balancing state is "dwindling", while the current load balancing state is still "active" in the table 1204, and the load of the host 108. Before the current load balancing state will change to "dwindling" infrastructure 1202 health and load wants to make sure that the combined caches 1208 and the load really has been updated to the new state policy "exhaustion."

To verify that the combined caches 1208 and load load balancing unit 106 has been updated in accordance with the new directive states infrastructure 1202 health and load craps Post 1512 "postulate table state" in the load balancing units 106. Message 1512 "postulate table state" passed after a while (for example, a predetermined period of delay time) after transmitting a message 1506 "change line", indicating that the directive is to change the status. In this example, a message 1512 "postulate table state" indicates that the state of the table should be "dwindling". The dashed arrow 1518 indicates that the load balancing unit 106 responds to the message 1512 "postulate table state" if it is a combined cache of 1208 and load different from the postulated state directive.

If the cache directive in the combined 1208 and the load does not differ from the postulated state directive, the load balancing unit 106 sends a message 1514 "postulated error" on infrastructure in 1202, health and load host 108 that issued the message 1512 "postulate table state." Then this infrastructure 1202 health and load periodically re-sends the message 1512 "postulate table state", while from 1208 the combined caches and load do not cease to be reported in 1514, "to posit a mistake." At this point the infrastructure 1202 sends a health and load new message 1506 "change line" with the new state of load balancing. In this sense, the combined caches 1208 and load are final determinants of the current state of load balancing, and infrastructure 1202 health and load is the ultimate determinant of the target load balancing state.

Figure 16 shows a message flow diagram for transmission, shown in Figure 12, between hosts 108 and load balancing units 106. Illustrative messaging scheme may reduce the bandwidth consumed by communications 1502 "pulse" at the communication means 1210. The message flow diagram shown in Figure 16, specifically adapted for messages 1502 "pulse", but can be used for other communications messaging protocol 1500.

Multiple hosts 108 (1), 108 (2) 108 (3), ..., 108 (11) 108 (12) are shown together with the modules 106 (1) 106 (2) ... 106 (u) load balancing . Each line represents a bond between the members of or belonging to a group of hosts 108 (1, 2, ..., 12). The group of hosts 108 (1, 2, ..., 12) forms a plurality of nodes which work together to provide information "heartbeat" to load balancing units 106. Although shown twelve hosts, each host group this may include more or fewer hosts. Furthermore, the full group of hosts 108 serviced by load balancing infrastructure 106 may be divided into one, two, three or more groups of hosts.

In the described implementation, the nodes belonging to the group of hosts 108 (1, 2, ..., 12) is elected leader responsible for transmission of messages 1502 "pulse" to load balancing units 106. Each (nelidiruyuschy) host 108 from the group of hosts 108 (1, 2, ..., 12) sends its messages in 1502 "pulse" of the elected leader. This example is elected leader host 108 (4).

Information "pulse" of each host 108 from the group of hosts 108 (1, 2, ..., 12) through the nodes of the member extends to a leading host 108 (4) groups. Host 108 (4) collects information "pulse" and combines it in a joint statement in 1602 "pulse". The combined message 1602 (1) 1602 (2) ... 1602 (u) «pulse" are sent to the respective modules 106 (1) 106 (2) ... 106 (u). These combined messages 1602 "pulse" can be optionally compressed to further reduce bandwidth consumption.

As another alternative, the leading host 108 (4) may only send changes in the composition of the group combined caches 1208 and load. In other words, in this mode, the combined caches 1208 and loads are dealing mainly, if not exclusively, with regard to state changes in toiletries. High-end host 108 (4) is intended to guarantee the shipment of the first greetings, when the host 108 makes contact and sending a message to 1504 "goodbye" when disconnecting the host 108. In addition, the host 108 may periodically indicate the need for a "transfer" message 1502 "pulse". Thus leading host 108 (4) receives an order to send him to the combined caches 1208 and load, even if it does not represent a change accessories.

Posts 1502 "pulse" (including the combined message 1602 "pulse") are used to load balancing units 106 when they are combined caches 1208 and load are out of sync with the tables 1204 and load. This desynchronization may occur, e.g., due to deterioration or failure of a unified cache 1208 and the load and / or load balancing unit 106. As described above, each message 1502 "pulse" includes data error control that are formed to check the equivalence between the integrated cache 1208 and load tables 1204 and load. In case of nonequivalence for a particular host 108 and / or the application 316 of the posts 1502 'pulse' is extracted specific host DNS name 108.

Consolidated cash and the load 1208 uses the DNS name to send the message 1508 "to get a snapshot of the table" for a particular host 108 to obtain updated information in 1206, health and load as a message 1510 "to send a snapshot of the table." Another or the same message in 1508 "to get a snapshot of the table," is sent to each host 108, for which the observed non-equivalence. Finally, information 1206, health and load cache 1208 in joint health and load information 1206 is equivalent to the health and load tables 1204, and loads, which is checked by the new messages 1502 "pulse". Thus, the work of the failed cache 1208 and the load can be reduced without interference from the protocol in 1500 messaging and control scheme equivalence.

17A and 17B depict scenarios for the proxy information storage, health and load tables 1204 and load cache 1208 for joint health and load, respectively. In implementations described above with reference to 12-16, hosts 108 include infrastructure 1202, health and load. However, in other implementations, the hosts can not contain infrastructure 1202, health and load.

For example, the host can run version of the application (s) and / or operating system, for which the health and load infrastructure either not implemented, or, for reasons of politics, is not installed on the host. As a result, these types of infrastructure hosts health and load information 1202 is not performed. Host 1702 is such a host, which is not executed in 1202 infrastructure capacity and load. Nevertheless, the host 1702 may use the infrastructure of health and load information 1202 that is running on one or more intermediaries, such as proxy 1704.

On mediator 1704 is located and executed infrastructure 1202, health and load, which includes a table 1204 and load. Host 712 may use the functionality of the 1202 performance and load by providing information in 1206 about the health and load table 1204. For applications running on the host 1702. Alternatively, the mediator 1704 can output performance and the load on the host, in 1702, following the steps of external monitoring. Mediator 1704 is shown as a proxy 1704 (1) and 1704 (2) for redundancy and, consequently, high safety.

In implementations described above with reference to 12-16 and below with reference to Figure 8, the alignment of the load carried by the load balancing module 106 comprising combined caches 1208 and load. However, other implementations may provide for load leveling without combined caches 1208 and load.

For example, load balancing may be performed by hardware monolithic load balancing or other load balancing infrastructure that is not stored and / or can not store or otherwise cache contains the combined 1208 and load. Load balancer 1706 is reflecting (s) a device or devices of load balancing that are not unified cache 1208 and load. However, the load balancer 1706 may use the combined cache 1208 and the load current on one or more intermediaries, such as a mediator in 1708.

Mediator 1708 contains the combined 1208 and cache load, which stores information in 1206 for health and load application is hosted, serviced 1706 load balancer. 1706 load balancer can use the information in 1206, health and load cache of the combined 1208 and load the implementation of load balancing functions by accessing such information using application programming interfaces (API), «family» to load the equalizer 1706 and supported them. Alternatively, a combined cache 1208 and the load can call the API for transmitting information 1206, health and load, including directives 1706 to load balancer. Mediator 1708 is shown as a proxy 1708 (1) and 1708 (2) redundancy, and therefore, reliability.

Figure 18 shows the procedure for allocation of the target application endpoint using the classifier processor 304, and 314 health and load comprising the load balancing unit 106. Once processor 314 health and load gets access to the combined cache 1208 and load the information contained therein in 1206 health and load is used in the selection of endpoints applications for new requests / connections.

As described above with reference to Figure 13B, a combined cache 1208 and the load information contains the cached health and load information 1206 for multiple hosts 108. To facilitate the creation and updating unified cache 1208 and load information 1206, health and load received from multiple hosts 108, information 1206, health and load arranged in it so that it is available on each host identifier 108. However, the information 1206, health and load also arranged therein, so that it is available for the type of application 316 in order to facilitate the end point applications.

In other words, processor 314 health and load able to access information in 1206 health and load 316 for each application separately according to 1206 performance and load multiple hosts 108. Following the information received in 1206, health and load for a given application 316 for each host 108 members of the selection connection requests can be performed in accordance with this information 1206, health and load. For example, the possible end points for a given application 316 may be formed within the connection request by selecting the endpoints of the application 316 based on the relative capacity of the available load among bodied endpoints for a given application 316.

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

Processor 314 receives health and load distribution request 1802 target application endpoint and selects at least one physical endpoint corresponding to the identified type of application 316 by using any one or more of the multiple selection mechanisms. To reduce the delay processor 314 selects the health and load distribution of the end points to be used for a number of incoming connection requests. This comes from the distribution processor 314 health and load to classifier 304 using the response 1804 to target application endpoint allotment. It is shown that the answer 1804 to the distribution of the end points of the application contains the physical distribution of IP-addresses and ports (eg, endpoints IP1, IP2, and IP3) for the identified type of application 316.

Response 1804 to the distribution application endpoints may be implemented using one or more distribution schemes. For example, the diagram 1806 shows the marker distribution circuit 1808 and the percentage distribution. Marker distribution scheme in 1806 is a modular scheme selection, and the percentage distribution of the scheme in 1808 is a temporary scheme of distribution.

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

One can use any value for the total number of markers, such as 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 health and / or load application. Classifier 304 "spending" / consumes one token in response to each connection request when allocating endpoint applications until the end markers; classifier 304 then requests another token distribution using the distribution request 1802 target application endpoint.

Percent distribution circuit 1808 determines the available capacity relative similarly. However, instead of these specific markers available capacity relative to the endpoint application classifier 304 are provided together with a timer 1810 duration. The classifier 304 identifies the target application endpoint incoming connection request in accordance with those having a percent relative to the container before the timer expires 1810 duration.

According to the percentage distribution of the scheme in 1808, the classifier 304 maintains a continuous record of discharge endpoint application for accession to the distributed interest and keeps track of the duration of the timer 1810. After time classifier 304 requests another percentage distribution using the distribution request 1802 target application endpoint.

Note that the marker distribution circuit 1806 also may use time limit. If the distribution of the markers are too old, you can discard and get new ones. Otherwise, classifier 304 may consume stale markers that have been previously allocated on the basis of health and load information, which is currently too outdated. Using the distributions endpoint application classifier 304 is described below in the section entitled "Classifying, Forwarding, and Request Routing".

Track sessions

This section describes how to host status information, such as information sessions, can be collected and used for network load balancing. This section links are primarily at fig.19-24 function and illuminated session affinity preservation, such as provided by session tracking unit 308 (Figure 3). As described above with reference to Figures 1-3, each host 108 the hosting one or more applications 316 that provide service (s) to clients 102. Block 308 uses the session tracking session information relating to the context for the connection established between applications 316 and clients 102 for certain described implementations of network load balancing.

Figure 19 illustrates an approach to equalization network load information 1902 session. Compound [1] indicates that the client 102 (1) creates a new connection to host 108 (2) 106 through the load balancing infrastructure. Load balancing infrastructure 106 may comprise one or more modules 106 to load balancing. When a connection request arrives at load balancing infrastructure 106 request is typically routed to a host 108 using network load balancing function in accordance with the health and / or load of hosts 108 and / or applications 316 (not explicitly shown in Figure 19).

When a connection is [1], client 102 (1) and serving application 316, which in this example is located on the host 108 (2), a session is established. The session provides a context for bidirectional communication between the client 102 (1) and host 108 (2). Information for the session context is stored at host 108 (2). When connection [1], the session context can not be used again. On the other hand, the session context may be useful again if client 102 (1) attempts to initiate another connection with hosts 108 for the services provided by the application 316. If this other connection is not routed to the same host 108 (2), which stores the context session, the client 102 (1) is necessary to establish a new session context that may require time-consuming large amounts of data / processing and / or to upset human user client 102 (1). With network load balancing based on the health and / or load, the likelihood that the second connection is routed to 108 (2) will be no greater than random chance.

If the load balancing infrastructure 106 has access to the mapping between the session information and the hosts 108, the load balancing infrastructure 106 may route the connection request relating to the previously established session, the appropriate host 108. Some session information can be derived from the contents of a package transported through the infrastructure 106 load balancing. However, this approach is inaccurate and Unfocused for several reasons. Firstly, establishing and ending a session just assumed. Secondly, some sessions are not end "officially" with proper indication includes packet. For example, some sessions are simply suspended. Thirdly, the packets transmitted from the host 108 (2) to the client 102 (1) may move along a path that does not include the load balancing infrastructure 106 that prevents the load balancing infrastructure 106 such monitor information packets for the session.

According to Figure 19, host 108 provides session information 1902 (EC) 106 to load balancing infrastructure. Using the session information 1902 from hosts 108, section 1904 preserving session affinity can maintain affinity between the established session and the host 108 on which the session was established. Session information 1902 includes a link or mapping between each session established between a client 102 and a particular host 108, and that particular host 108. This mapping unit 1904 available session affinity preservation as the display portion 1906 host - the session information. More specific examples of session information 1902 are listed below, particularly with reference to FIG. 20, 22, 23A and 23B.

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

According to an example of the compound [1], the session is established on the host 108 (2), is provided a load balancing infrastructure 106 as the session information 1902. In particular, communication / mapping between (i) context session client 102 (1) and host 108 (2) and (ii) an identifier for host 108 (2) are displayed on the 1906 host - the session information. When thereafter a request to the compound [2] for the same session context section 1904 preserve session affinity locates the session context in the mapping 1906 host - the session information and determines that host 108 (2) associated with the session context of the communication / display .

In accordance with the mapping of host 108 (2) for the requested session context identified block 1904 preservation of session affinity display 1906 host - the session information, the compound [2] is routed to host 108 (2). In this sense, session affinity preservation has a higher priority for the load balancing infrastructure 106 than solutions for network load balancing based on application health and load. However, the performance and the load may be more important for network load balancing than tracking session, for example, in the case of extremely high load or the failed state of the application relating to the session, and / or host.

Many types of compounds can be associated with the session. Examples include: TCP-connection, the session protocol Transport Layer Security (TLS) / SSL, session PPTP, session IPSec / L2TP, the session ISA, the session-based cookie HTTP, terminal server session, the session defined by the administrator, and so on. d. For clarity, TCP-connection is considered as a TCP-session packet. Furthermore, it can be transferred and maintained a model job sessions administrator. In addition, the sessions may also be supported on the IP-based client demarcated downtime. It is relatively nonintellectual support session, but expected by some users.

The connection request from client 102 varies according to the type of the desired session. For example, treatments for type «TCP-connection" connection request comprises a TCP-packet. For the sessions of the "session SSL» connection request includes a TCP-connection. Other such connection requests correspond to other types of sessions. These examples also show what may be the session level. At the lower level, a session context for the session-TCP compound can include ordered quadruple TCP, session number, the number of transmitted / received bit etc. On a higher level, a session context for the session of the SSL session may include a 32-bit session ID, client's public key 102 provided to the host 108, etc.

Figure 20 shows an exemplary approach to network load balancing using the information transfer session by notification messages 2006 and 2008 showed multiple modules 106 (1) 106 (2) ... 106 (u) of load balancing and multiple hosts 108 (1 ), 108 (2) ... 108 (n). Each respective host 108 (1), 108 (2) ... 108 (n) includes one or more relevant applications 316 (1) 316 (2), ..., 316 (n), arranged and running it. Notification 2006 is used to provide session information from applications 316 and posts 2008 are used to provide session information from hosts 108 to load balancing units 106.

It is shown that each respective host 108 (1), 108 (2) ... 108 (n) includes infrastructure 2002 (1) 2002 (2) ... 2002 (n) session state (IOS). Each respective infrastructure 2002 (1) 2002 (2) ... 2002 (n) comprises respective monitoring session table 2014 (1) 2014 (2) ... 2014 (n) sessions (although clearly shown in Figure 19 only one table 2014 (1) sessions).

Each respective portion 106 (1) 106 (2) ... 106 (u) contains the corresponding load balancing function 2012 (1) 2012 (2) ... 2012 (u) routing (FTI). Traffic routing functionality 2012 may comprise, for example, the function of classifying and / or requesting a route, for example, provide a classifier 304 and request router 306, respectively. Distributed to modules 106 (1) 106 (2) ... 106 (u) is a distributed session tracking manager 2010.

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

API 2004 is used to provide session information from applications 316 to session tracking infrastructure 2002. Using the API 2004 enables applications 316 communicate session tracking infrastructure 2002 session information including its various modifications. In particular, each application 316 is able to give, and session tracking infrastructure 2002 is able to receive a notification in 2006.

Under the new setting or the opening session, the application 316 issues a notice of establishment of a session (or notification 2006 (E) on the establishment of a session). Notification 2006 (E) establishing a session includes a session identifier and optionally an identifier of application 316. When the end of the session closing or application 316 issues a notification of the session end (or notification 2006 (T) on the end of the session). Notification 2006 (T) on the end of the session also contains the session identifier and optionally an identifier application 316.

After receiving notification 2006 (E) on the establishment of a session, session tracking infrastructure 2002 inserts into a table element for the 2014 session of the new session. Exemplary Session table 2014 is described below with reference to 23A. Receiving notification 2006 (T) on the end of the session, session tracking infrastructure 2002 removes the session table 2014 for the old session element.

Table 2 014 (1) is an Session official source session information 1902 regarding applications 316 (1) to host 108 (1). However, when requesting traffic routing functionality 2012 on contact with the hosts 108 to access tables sessions in 2014 on receipt of each incoming connection request having a link to the session, there is too much delay. Therefore cached session information 1902 at load balancing units 106.

For load balancing units 106 distributed session tracking manager 2010 caches session information 1902 that is part of its duty to manage session state. In general, distributed session tracking manager 2010 is a distributed application and / or virtual service part placed on each module 106 to load balancing. For each logical session distributed session tracking manager 2010 stores at least one cached copy of session information for a reliable and scalable manner which can be quickly used to route traffic for incoming connection requests that have a session reference for load balancing infrastructure 106 .

Communication between hosts 108 and load balancing units 106 by using a reliable protocol that ensures that messages 2008 sent from the host 108, receives the desired load balancing unit 106. Each host 108 is attached to at least one specific load balancing unit 106 which is assigned load balancing module 106 for message 2008. This binding is created by assigning a specific IP-address load balancing unit 106 to the host 108 for each messaging session tracker 2008 between session tracking infrastructure 2002 and distributed session tracking manager 2010. To improve reliability, load balancing infrastructure in the event of load balancing unit 106 another load balancing unit 106 receives the IP-address of the failed module 106 to load balancing. Fault detection for making IP-addresses can be carried out using the "pulse" or other health monitoring scheme.

Thus, messages carry information 1902 2008 session from session tracking infrastructure 2002 to distributed session tracking manager 2010. For example, when tracking infrastructure 2002 accepts a session notification 2006 (E) establishing a session, it also craps up message 2008 (U) to distributed session start session tracking manager 2010. Message 2008 (U) includes the session start a session identifier, a host identifier, and optionally other information. Message content 2008 (U) session start is described below with reference to 23B with regard to information that can be stored for each session by implementing a distributed session tracking manager 2010. When session tracking infrastructure 2002 receives the notification 2006 (T) on the end of a session, it also sends a message 2008 (D) to distributed session ends session tracking manager 2010. Messaging 2008 may be performed before, during or after the session tracking infrastructure 2002 appropriately modified sessions table 2014 in accordance with the notification 2006.

21 is a flowchart of a process 2100 for network load balancing using the information transfer session by notifications and messages. Flowchart 2100 contains fifteen blocks 2102-2130. Although the actions of flow diagram 2100 may be performed in other environments and with a variety of other means of software schemes, FIGS. 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 made application 316, there are six blocks 2106-2110 and 2122-2126 are made session tracking infrastructure 2002, and the actions of five blocks 2112-2116 and 2128-2130 shall be distributed session tracking manager 2010. Actions eight of these blocks 2102-2116 are mainly directed to the opening of the session, and the actions of these seven blocks 2118-2130 are mainly aimed at closing the session.

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

At block 2106 is received notice of the establishment of the session. For example, session tracking infrastructure 2002 may receive notification 2006 (E) on the establishment of a session from the application 316 in accordance with API 2004. At block 2108, a session table element is inserted. For example, session tracking infrastructure 2002 may insert an item in the table for the 2014 session open session. Examples of such insertion are described further below especially with reference to 23A. At block 2110 occurs sending the message the session began. For example, session tracking infrastructure 2002 may send a message 2008 (U) to distributed session start session tracking manager 2010 using a reliable communication protocol.

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

At block 2116 the network traffic is routed via the session information. For example, traffic routing functionality 2012 in conjunction with a distributed session tracking manager 2010 may use the cached session information 1902 including the generated session information entry for routing incoming connection requests that have a session reference. An example of such routing is described below, particularly with reference to Figure 24. Additional examples are described below in the section entitled "Exemplary Classifying, Forwarding, and Request Routing".

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

At block 2120 is received notice of the end of the session. For example, session tracking infrastructure 2002 may receive notification 2006 (T) on the end of the session from the application 316 in accordance with API 2004. At block 2124 removes the session table of the elements. For example, session tracking infrastructure 2002 may remove the item from the table for the 2014 session closed session. At block 2126 occurs sending the message the end of the session. For example, session tracking infrastructure 2002 may send a message 2008 (D) to distributed session ends session tracking manager 2010 using a reliable communication protocol.

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

Figure 22 illustrates an exemplary approach to managing session information at multiple load balancing units 106. Each respective portion 106 (1) 106 (2) ... 106 (u) includes a respective load leveling portion 2202 (1) 2202 (2) ... 2202 (u) 2202 Distributed Manager atoms (DAM). DAM 2202 is an exemplary implementation of distributed session tracking manager 2010. Each respective part of the DAM 2202 (1) 2202 (2) ... 2202 (u) contains the corresponding part 2206 (1) 2206 (2) ... 2206 (u) DAM table (TRDA) 2206.

DAM 2202 is a distributed application or virtual service that manages session information 1902 reliable and scalable manner that allows traffic routing functionality 2012 to use it to preserve session affinity. For example, traffic routing functionality 2012 may access the DAM 2202 using the API (not specifically shown) for searching TRDA 2206. Function calls 2204 DAM 2202 work and other aspects of Figure 22 are described below after the description of FIG. 23A and 23B.

23A shows a session table 2014 indicated in Figure 20. Table 2014 includes a Session «v» elements 2302 (1) 2302 (2) ... 2302 (v). Each element 2302 inserted session tracking infrastructure 2002 in accordance with the notification 2006 (E) establishing a session, received from the application 316. Each entry 2302 is deleted session tracking infrastructure 2002 in accordance with the notification 2006 (T) on the end of the session received from the application 316.

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

Session type and / or application 2302 (T) may be "TCP", "IPSEC", «terminal server», «HTTP cookie», application type, as mentioned above, etc. ID 2302 (I) session may be "<IP-source address, TCP-source port, IP-destination address, TCP-port of destination>", "IP client = 172.30.189.122", "user = 'joe_user'", "Cookie = '{b7595cc9-e68b-4eb0-9bfl-bb717b31d447}'", the other, for example, the session ID associated with the application, etc. For type-TCP connection / session identifier 2302 (I) the session may alternatively be a canonical version of TCP ordered quadruple (for either IPv4 or IPv6). Alternatively, it is also possible to use other values ​​for the identifier 2302 (I) session and application / session type 2302 (T).

In 23B shows a table 2206 (TRDA) Distribution Manager (DAM) atoms indicated in Figure 22. Table 2206 contains «w» entry 2304 (1) 2304 (2) ... 2304 (w). Each session information entry 2304 DAM 2202 is created in accordance with a message 2008 (U) session start received from session tracking infrastructure 2002. Each session information entry 2304 is destroyed in accordance with the message 2008 (D) the end of the session received from session tracking infrastructure 2002. As described below, the elements 2304 of the session information table 2206 can be actually controlled by DAM 2202 using function calls 2204.

As described above, the message 2008 (U) includes the session start a session identifier, a host identifier, and optionally other information. Each respective entry 2304 (1) 2304 (2) ... 2304 (w) session information table 2206 includes respective fields (i) key 2304 (1K), 2304 (2K) ... 2304 (wK), ( ii) data 2304 (1D), 2304 (2D), ..., 2304 (wD) and (iii) the metadata 2304 (1M), 2304 (2M), ..., 2304 (wM). For example, the values ​​of the fields in 2304 (K) key may be an alphanumeric string, and 2304 field values ​​(D) data may be bits. The key value 2304 (K) may also be a bat.

Key 2304 (K) may correspond to an identifier 2302 (I) session. Data 2304 (D) may correspond to the host identifier, for example the network address of host 108, on which there is the session context. Metadata 2304 (M) may correspond to another, optional, information. Examples of such metadata 2304 (M) may be data internally used by DAM 2202 to resolve conflicts atoms and health monitoring atoms (e.g., via suspension mechanism). (This representation elements 2304 as the atomic described in more detail in the next section.) In particular, the metadata 2304 (M) include, inter alia, identification entity (object) (for example, copy traffic routing functionality 2012), adding information entry 2304 a session in table 2206.

In a described implementation, each session information entry 2304 is atomic in the sense that the DAM 2202 can add, delete, copy, etc. elements 2304 as a whole, but DAM 2202 typically does not change any part of the entry 2304 as a whole. Thus, the atomic entry 2304 is added, deleted, copied, and otherwise processed, etc. tables 2206 by DAM 2202 to implement the reliability and scalability to implement session affinity preservation.

Function calls 2204 (Figure 22) are used to manipulate the DAM 2202 atomic entry 2304 of the table 2206. Function calls 2204 may come from a load balancing unit 106 to one or more load balancing units 106 in the two-point or broadcast mode. These function calls include "add atom" in 2204 (A), "to remove the atom" in 2204 (D), «query atom" in 2204 (Q) and "to return the atom" 2204 (R).

"Add atom" 2204 (A) has the form AddAtom (key, data) and is used to add an atomic entry 2304 to one or more tables 2206. Therefore, function call "add atom" 2204 (A) can be expressed as AddAtom (<session id> IP-address of the host). "Delete atom" 2204 (D) has the form DeleteAtom (key) and is used to remove the atomic entry 2304 of one or more tables 2206. Function calls "remove atom" in 2204 (D) may be directed to the tables 2206, about which we know that they have a copy of a session, identified the key 2304 (K), or can be sent to all of the tables 2206 that ensures the removal of any copies.

"Demand atom" 2204 (Q) has the form QueryAtom (key) and is used particular part 2202, the session ID when referenced by an incoming connection request is not stored in a particular local DAM table 2206 or specified portion 2202. Function call "request atom" 2204 (Q) are sent to one or more (possibly all) other parts 2202. In response, each of the 2202 checks its local table 2206 for key / session ID. If the key is detected another portion of 2202, then the other part 2202 responds with a "return atom" 2204 (R).

"Return atom" 2204 (R) looks ReturnAtom (key data) and used to respond to a function call "request atom" in 2204 (Q). Function calls "return atom" 2204 (R) are used when the DAM portion 2202 has requested atomic entry 2304 in its local DAM table 2206 identified key 2304 (K), in said function call "request atom" 2204 (Q). Function calls "return atom" 2204 (R) can be directed back to the DAM portion 2202 that issued a function call "request atom" 2204 (Q).

Function calls "add atom" 2204 (A) used in response to the message 2008 (U) session start and / or overlapping atomic entry 2304 to one or more other tables 2206. This duplication may be performed for redundancy and / or scalability.

Function calls "delete atom" 2204 (D) is used in response to the message 2008 (D) the end of the session and may also be sent on one or more tables 2206. After removal of the atomic entry 2304 atomic entry 2304 may enter into a state of "zombie", in which it remains in the DAM 2202 and, optionally, still stored in the table 2206 a pointer "zombie" in the metadata 2304 (M) atomic element 2304.

Thus, after removal of the atomic entry 2304, it may remain in the DAM 2202 and DAM table 2206 in a "zombie", whereby packets for this (now inoperative and closed) of the session are directed to the host 108 the session context for proper, depending on the protocol , processing. For example, TCP-packets received after the removal of TCP-connections are routed to host 108, which terminated compound. The host 108 may properly answer - perhaps sending a RST or resend the FIN-ACK. The time that the atomic entry 2304 spends in this state, "zombie" is the same (as precisely as possible) with a protocol dependent downtime used to secure communications protocol.

Function call "request atom" 2204 (Q) is used to access the atomic entry 2304, when the first load balancing unit 106 receives an incoming connection request that references a session that is not stored in the local table 2206 for DAM 2202 of the first load balancing unit 106. Note that other parts of the DAM 2202 can simultaneously request broadcast by the function call "request atom" 2204 (Q) or sequentially, until a positive function call "return atom" 2204 (R).

Function Call "to return the atom" 2204 (R) uses a portion 2202 of the second load balancing unit 106 for providing atomic entry 2304 of the DAM 2202 the first load balancing unit 106, when the atomic entry 2304 has a key 2304 (K), the specified key / session identifier in function call "request atom" in 2204 (Q), formerly part of the DAM 2202 issued the first load balancing unit 106. Note that the other components such as traffic routing functionality 2012 can also use function calls 2204, in particular, function call "request atom" 2204 (Q), in accordance with API or the like.

Parts of DAM 2202 and 2206 of the table you can organize and manage all kinds of ways. The illustrated methods relate to duplication / redundancy, local caching upon receipt, hashing for location selection, etc. It is possible to use zero, one, two or more high level duplication until complete duplication. When zero overlap each atomic entry 2304 is stored at the DAM 2202 that receives a message 2008 (U) to start a session, without duplication of other parts of the DAM 2202.

At the first level of duplication, each atomic entry 2304 is stored in the DAM 2202 that receives a message 2008 (U) the beginning of the session for him, and also added (copied) to another part of DAM 2202 using the function call "add atom" in 2204 (A). This makes it possible to cope with a failure level for the module 106 to load balancing. Similarly, when the second level of duplication, each atomic entry 2304 is stored at the DAM 2202 that receives a message 2008 (U) to start a session, and is also added to the other two parts DAM 2202. In general, one, two, etc. part of DAM 2202, in which this part of the DAM 2202 copies atomic elements 2304 are predefined or chosen arbitrarily. It is also possible to apply the third, fourth, etc. levels of redundancy.

In addition, you can use the full duplication, where each atomic entry 2304, which is stored in the DAM 2202 that receives a message 2008 (U) the beginning of the session, also added to every other part of the DAM 2202. The choice of the level of duplication is influenced by several factors. With the increasing level of duplication increases reliability and decreases the delay. On the other hand, network traffic, and memory usage increases with higher levels of duplication.

When the full duplication is not used, a local caching upon receipt. For example, when a part of DAM 2202 does not detect a session identifier being referenced, in its part of DAM table 2206, part DAM 2202 provides a function call "request atom" 2204 (Q), to gain access to atomic entry 2304 associated with the session identifier on which the referenced by the function call "return atom" 2204 (R). Rather than discard the atomic entry 2304 after its use, the DAM portion 2202 caches the resulting atomic entry 2304 in its part of DAM table 2206. This option allows you to select between the above factors.

Another option is to use no duplication may consist hashing for location selection. Origin atomic entry 2304 for the session is stored in the DAM portion 2202 that receives the message 2008 (U) session start. Duplicated copy or copies sent via function calls "add atom" in 2204 (A) for a specific (s) portion (s) DAM 2202 using a hash function. From the set of all possible hashes each of the DAM 2202 is assigned a subset. Each session identifier is hashed using a hash function to obtain a hashed value. This hashed value is displayed on the assigned DAM 2202. Part of the DAM 2202 that the first atomic entry 2304 is added, and then duplicate the atomic entry 2304 in the assignment (s) portion (s) DAM 2202.

Due hashing for location selection, at least one part of the DAM 2202 that is cached locally desired atomic entry 2304 in its table 2206, available on the session ID. Therefore, a function call "request atom" 2204 (Q) may be directed to certain (s) part (s) 2202. DAM This usually reduces network traffic and / or delay.

This hashing for location selection may be used in the first, second, third or more of the level of overlap, each band is hashed values ​​displayed on one, two, three, etc. different parts DAM 2202, respectively. Further, hashing for location selection may be used in conjunction with a local caching upon receipt.

24 is a flowchart of a control method 2400 session information at multiple load balancing units. Flowchart 2400 comprises eight blocks 2402-2416. Although the actions of flow diagram 2400 may be performed in other environments and using different software schemes, FIGS. 1-3, 19, 20, 22, and 23B are used in particular to illustrate certain aspects and examples of the method.

At block 2402 analyzes the incoming connection request with reference to the session. For example, traffic routing functionality 2012 can receive incoming connection request that refers to a previously opened / established session of a certain type. At block 2404 searches the local DAM table with references to the session. For example, data unit 106 to load balancing and traffic routing functionality 2012 DAM portion 2202 can search its corresponding DAM table 2206 by reference to a session.

At block 2406, it is determined whether the link to the same session key with the local DAM table. For example, DAM portion 2202 may be in the search fields 2304 (K) plural items of the key 2304 of the table 2206 to determine whether the link to the session with any values ​​of the fields 2304 (K) of the key. If yes, then flowchart 2400 proceeds to block 2412.

If the link to the session does not coincide with any key, then flowchart 2400 proceeds to block 2408. At block 2408 performs a function call "request atom." For example, DAM portion 2202 may carry out a function call "request atom" 2204 (Q), comprising, as a session key for link / session identifier. Function call "request atom" 2204 (Q) may be sent to at least one other DAM portion 2202. The number of selection, order, etc. DAM 2202 parts possible destination for the "request atom" 2204 (Q) may depend on the options (e.g., replication level, hashing for location selection, local caching upon receiving two-point / broadcast mode, etc.) used in the DAM 2202.

At block 2410 is received the returned atom. For example, information can be obtained by calling the function "return atom" 2204 (R), issued by the other part of RDA 2202. Another part of the DAM 2202 successfully located atomic entry 2304 in their respective table 2206, and discovered atomic entry 2304 is key, coinciding with Referring to the session. Information from the function call "return atom" 2204 (R) contains the values ​​of the fields 2304 (K) and key field 2304 (D) for the detected data atomic entry 2304. These values ​​correspond to the session identifier for the session and the network address of host 108, which has an affinity a session.

At block 2412 is extracted atomic entry. The atomic element is removed from the local DAM table if a match is found locally (in blocks 2404 and 2406), or from the returned atom if a match is found elsewhere (in blocks 2408 and 2410). For example, the atomic entry 2304 may be removed from the table portion 2206 DAM 2202 or from information obtained by the function call "return atom" 2204 (R). The extracted atomic entry 2304 may be cached in local DAM table 2206 if obtained as a result of function call "return atom" 2204 (R).

On the 2414 block of atomic element identify host affinitized to which the link points. For example, the value of the field 2304 (D) data extracted atomic entry 2304 may be found to thereby find the network address of host 108, having an affinity for the session. At block 2416 the incoming connection request is routed to the identified host, for example, traffic routing functionality 2012 and / or the transfer function can route incoming connection request having a reference to the session on identifying the host 108 affinitized. The following section describes exemplary function classification, routing and forwarding of requests.

Classifying, Forwarding, and Request Routing

This section describes how to implement routing for network load balancing, including in relation to the high reliability of a function of traffic routing. Routing function may include a function of the classification and / or requesting routing, especially in connection with the transfer function. In this section, references are mostly to fig.25-31. It illuminates the function request router 306 (3), the relationship between tracking sessions and using the health and load information for routing traffic, operational implementation of traffic routing interaction with session information and / or health and load information, failover procedures for high reliability balancing infrastructure network load (including fault handling component classification, forwarding and / or routing requests), additional configurations of network load balancing infrastructure, etc.

Figure 25 shows the network load balancing infrastructure having request routing function, implemented router 306 (H / S) queries. As mentioned above with reference to traffic routing functionality 2012, the routing of traffic may be based on classification (such as shipment), and / or requesting routing. Classification at the packet level, together with the shipment, as described above, in particular with reference to Figure 4. Routing requests described herein, particularly with reference to Figure 25.

Level routing request occurs on a higher level than the routing at the packet level. In general, a request router 306 acts as an intermediary for the application 316 running on the host 108. The query router 306 terminates TCP-compounds analyzed (perhaps partially) each request from the client 102 and redirects the request to each router 108. The host 306 may query perform pre-processing on a connection-for example SSL decryption. Furthermore, request router 306 may select the absorption of certain queries (for example, the router supports the query cache responses) and may, at its discretion, to change requests before forwarding them to the hosts 108.

Request router 306 typically depend on the application and may be sufficiently extensible in relation to what they do. Purely by way of example in the following description, the only class of request router 306 - routers 306 (H / S) request HTTP / SSL. It is shown that the client 102 having the network address of C1, the network 104 communicates with host 108 (1) and 108 (2), having network addresses H1 and H2, respectively. Communication takes place by means of load balancing infrastructure that includes a router 306 (H / S) request HTTP / SSL.

The router 306 (H / S) HTTP / SSL request completes traffic HTTP and SSL, decrypts traffic SSL, checks every HTTP request from the client 102 uses the application-specific rules to classify each request and to determine the "best" endpoint for this query, at the same time taking into account the health and load information, an application endpoint, and sends a request to the endpoint. To request an endpoint using a separate TCP-compound other than the client 102, initiated (finishes the last connection to the router 306 (H / S) request HTTP / SSL). These steps can be seen as logically equivalent actions performed by classifier 304, but with the difference that this action in the router 306 (H / S) HTTP / SSL request made at the level of logical requests for each query in a TCP-connection. The router 306 (H / S) HTTP / SSL request, and, in general, request router 306 may utilize the same infrastructure (i) health and load and (ii) tracking sessions that use a classifier 304.

The router 306 (H / S) HTTP / SSL request acts as an intermediary between the client 102 and the two hosts 108 (1) and 108 (2). It handles two requests from the client 102 on one TCP-connection. In the described implementation, the final routing of requests provides a number of actions. In-n ervyh, the client 102 sets HTTP- or HTTPS-compound [1] with the router 306 (H / S) HTTP / SSL request and sends the request №1 2502 (1).

Secondly, router 306 (H / S) HTTP / SSL request completes the SSL session (if traffic is encrypted by SSL), analyzes the request №1 2502 (1), and checks the contents of the request №1 2502 (1). In view of the health and load information, and the session router 306 (H / S) HTTP / SSL request determines that host 108 (1) is "best" for the particular host request №1 2502 (1) in this example.

The third router 306 (H / S) HTTP / SSL request, establishes a secondary TCP connection [2] to host 108 (1). This secondary TCP-connection is not from VIP-104 network addresses; instead, it is based on the address (not shown in Figure 25), which is allocated to the router 306 (H / S) request to ensure that the responses 2504 from the host (s) 108 come to the appropriate router 306 queries. (There may be several valid request router 306, although in Figure 25, for simplicity, shows a router 306 (H / S) queries.) Alternatively, one can use an existing connection [2] to host 108 (1). Then, the router 306 (H / S) HTTP / SSL request sends, for example, an unencrypted version 2502 №1 request (1) to host 108 (1). Fourthly, host 108 (1) responds with a response №1 2504 (1). Fifthly, the router 306 (H / S) HTTP / SSL request encrypts the response №1 2504 (1) and sends it back to the client 102 over TCP-compound [1].

Sixth, the client 102 sends another query request №2 2502 (2). Request №2 2502 (2) is processed similarly request №1 2502 (1) except that the router 306 (H / S) HTTP / SSL request selects host 108 (2). Cause choice may be that the host 108 (1) currently is inoperative or overloaded because the request №2 2502 (2) directed along another URL, request №1 than 2502 (1), etc. . Anyway, the router 306 (H / S) HTTP / SSL request more secondary sets TCP-connection, but this is a secondary-TCP connection [3] arranged to host 108 (2). Unencrypted request №2 2502 (2) is routed to host 108 (2), and as a result, the response №2 2504 (2) comes out. Then, the encrypted version of the response №2 2504 (2) is sent to the client 102 from the router 306 (H / S) request HTTP / SSL.

Seventhly, the client closes the TCP-102 compound [1] with the router 306 (H / S) request HTTP / SSL. The router 306 (H / S) request HTTP / SSL (at some point in the future) closes the compound [2] and [3] set to hosts 108 (1) and 108 (2), respectively, from the client 102. TCP- Compound [2] can be alternatively closed after the router 306 (H / S) HTTP / SSL request decides to open / use a TCP-compound [3] to request №2 2502 (2).

Since the router 306 (H / S) HTTP / SSL request terminates HTTP / HTTPS-connection, the router 306 (H / S) HTTP / SSL request can not only route requests. For example, the router 306 (H / S) HTTP / SSL request can, in principle, to maintain its own cache the responses (e.g., using out of band mechanism to make the cache invalid). As mentioned in the above example, the router 306 (H / S) HTTP / SSL request can also, in principle, other kinds of route requests to other host groups 108 based on, e.g., the requested URL. Again, the router 306 (H / S) HTTP / SSL request can, in principle, to aggregate requests from numerous short-lived client connections and pass them on the few long-lived TCP-connections to hosts 108. Such aggregation connections can reduce the processing overhead on the host connections 108.

Routers requests of other classes can match another exemplary protocols in addition to HTTP. For example, the router queries can be a router queries SOAP. The router acts like SOAP request router 306 (H / S) request HTTP / SSL. However, the SOAP request router designed specifically for routing SOAP. SOAP request routers understand SOAP headers and routing decisions based on SOAP headers, as well as health and load applications.

Classification level and forwarding of packets (or packet-level routing) and routing level requests could provide some sort of load balancing level 7. Level 7 Load balancing is described below in the section entitled "Transferring compounds with Optional Tunneling and / or load balancing application layer." Routing packet level provides read-only access to the data of the initial TCP-client connection, and routing-level queries can access with the ability to read and modify all data stream.

Level routing packets has several advantages over the routing level requests. These advantages include transparency (client packages are delivered to the hosts in its original form, keeping the IP-address and source and destination port), low overhead of processing (in general, traffic forwarding provides a route), low latency (individual packets are sent, and packets are queued after determining the destination TCP-connection) and high reliability (in general, fail to block transfer does not terminate TCP-connection). On the other hand, the routing level queries typically has the following advantages over the routing at the packet level: the ability to check the entire data stream, going to and from the client, and the ability to convert the data stream and even to split the flow of data among multiple hosts or aggregate data streams from multiple clients .

26 is a flowchart of a method 2600 of routing incoming packets, in accordance with (i) session information and (ii) health and load information. Flowchart 2600 comprises eight blocks 2602-2616. Although the actions of flow diagram 2600 may be performed in other environments and using different software schemes, FIGS. 1-3, 12, 18-20, 22, and 23B are used in particular to illustrate certain aspects and examples of the method.

At block 2602 to the incoming packet. For example, a packet from the client 102 may act to transfer block 302 to load balancing unit 106. At block 2604, a determination whether the received packet belongs to an existing session. For example, forwarder 302 may consult the local table 2206 () XRD to determine that the received packet is already part of a session TCP / IP.

Furthermore, forwarder 302 may consult the local table 2206 () and XRD to determine that the received packet is not a session is part of TCP / IP. In this case, the delivery unit 302 delivers the received packet to classifier 304, which checks affinitized at a higher level for the received packet, if it has a session reference. Examples of such actions are described above in particular with reference to Figure 24 and below, particularly with reference to FIG. 27 and 28.

If the received packet belongs to an already existing session (as determined at block 2604), then proceeds to block 2606. At block 2606 is detected host having an affinity to the already existing session. For example, host 108 affinitized can be identified from the local table 2206 () DAM and / or shared distributed table 2206 forwarder 302 or classifier 304.

At block 2608, a determination is efficient if the host affinitized. For example, the classifier 304 may consult the combined cache 1208 and load to determine workable if the host 108, the affinitized, particularly those received packets that are part of the sessions that are at a high logic level than TCP sessions / IP. Step (I) of this block may be performed in conjunction with the processor 314, the health and load.

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

If the host affinitized, inoperative (as determined at block 2608), then proceeds to block 2612. Moreover, if, on the other hand, the received packet does not belong to an already existing session (as determined at block 2604) proceeds to 2612. At block 2612 is used to select the host according to the health and load information. For example, the classifier 304 may select from a host 108 and / or using an application distribution based on the health and load (e.g., from the response 1804 to the distribution target application endpoint) obtained from the processor 314, the health and load. Examples of these actions are described above in particular with reference to FIG. 19 and 18 and below, particularly with reference to Fig.30.

At block 2614 the received packet is routed to the selected host. For example, the classifier 304 may route (optionally via forwarder 302) the packet on the selected host 108. At block 2616 a route for a connection path to the selected host. For example, the classifier 304 may add an entry in the session information table 2206, in particular, in table 2206 () DAM, which is local to the sending unit 302 which transmitted the received packet classifier 304. This session information entry can be duplicated in accordance with established policies for redundancy DAM 2202 (e.g., session tracking block 308).

Action block 2614 and 2616 may be performed in exactly the order shown, when block 2616 is executed to block 2614, where the actions of partially or completely overlap in any order, etc. Note that the above steps carried out by classifier 304 may alternatively be performed by the router 306 requests (or, in general, traffic routing functionality 2012).

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

27 shows the steps for routing traffic in the absence of failures. It is shown that, before the rest of the load balancing infrastructure 106 (not separately shown) has one or more switches 202 (LBA), load-balancing-aware. Forwarding and classification divided into three devices or nodes. The first device 302 comprises (1) delivery and classifier 304 (1). The second device comprises a classifier 304 (2). A third device comprises a block 302 (2), Shipment.

With classifier 304 (2) operating on the second device, and a block 302 (2) forward operating at the third device, each device may be specifically tuned to its respective functions. For example, hardware, software, firmware, some combination thereof, etc. the second device and third device can be adapted to support the desired function, without involving additional costs. Thus, the third device comprising a block 302 (2) sending, by their hardware capabilities may be similar to the switch and / or router, and a second device comprising a classifier 304 (2), in its hardware features may be more like a server, and / or Personal Computer.

While shown three devices providing the functionality of four components, alternative logic and / or hardware configurations for classification and forwarding functions are applicable to the illustrated sequence for traffic routing, shown in Figure 27. Furthermore, although the routing destinations are shown as host 108 described herein may alternatively implement routing apply in general to the next destination node for the packet, and not necessarily to the final node that consumes the package.

Implementation DAM 2202 session tracking block 308 is used to implement the table 2206. However, the blocks 1904 preserve session affinity is generally also applicable to the exemplary workflow for routing, shown in Figure 27. 302 (1) comprises a delivery portion 2206 (1) of Table DAM and 302 (2) comprises a forward portion 2206 (2) DAM table. Incoming packets are routed to host 108 (1) and host 108 (2).

In a described implementation DAM 2202 is a distributed, in-memory, a table of "atoms" 2304 (e.g., steam keyword / value with optional metadata) having session information. DAM 2202 and DAM table 2206 described above, particularly with reference to Figures 22-24. Any node in the group classifier 304 can add, delete, and query atoms 2304. DAM 2202 maintains a highly table 2206, which contains information on existing routers (such as the level of TCP / IP), as well as higher-level sessions. Examples of higher-level sessions include: Session TLS / SSL, session PPTP, session IPSec / L2TP, session ISA, a session-based cookie HTTP, etc. Also, DAM 2202 can include elements in the session information table 2206 that apply to other sessions, non-TCP / IP, for example, RTF, UDP, etc.

Position (1) indicates that the switches 202 (LBA), load-balancing-aware, direct incoming packet at block 302 (1), Shipment. Position (2) indicates that 302 (1) is reconciled with its internal routing table, a table 2206 (1) DAM. When 302 (1) Shipping is not atomic entry 2304 for the packet, it forwards the packet to its assigned and / or the associated classifier, classifier 304 (1).

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

Classifier 304 (1) updates the table 2206 (1) DAM, which serves as a local routing table 302 (1) forward, and inserts the atomic entry 2304 represents a route to the common table 2206. This operation can be selected, a single operation in which a session TCP / IP level tables 2206 are placed on a forwarder 302, etc. DAM 2202 duplicates the internal route to one or more members of the group classifier 304 in accordance with its policy specified redundancy. Classifier 304 (1) may, optionally, bind to the host 108 (1) to confirm the establishment of the new session before update table 2206 (1) DAM 302 (1) and general forwarding DAM 2202 / table 2206.

Position (4) indicates that 302 (1) sends directly forwarding subsequent packets for this connection to host 108 (1) without interaction with classifier 304 (1). DAM 2202 can be used for masking at least partly the failure of forwarder 302, classifier 304 or the pair 302/304 unit delivery / classifier. DAM 2202 can also be used, at least partially, to maintaining the ability of the compound to the client, if the switches 202 (LBA), load-balancing-aware, by chance, transmit packets begin to establish a connection to another forwarder 302.

Figure 28 shows the sequence of traffic routing flow in the presence of failure (s). In contrast, the sequence of actions for routing traffic in the absence of failures, as shown in Figure 27, Figure 28 shows a failure, which occurred in 106 of the infrastructure network load balancing (not specifically mentioned). In particular, the first device that hosts and work 302 (1) Shipping and classifier 304 (1), becomes inoperative when the connection is shown in Figure 27. DAM 2202 that at least partially masks the failure.

Position (1) indicates that the switches 202 (LBA), load-balancing-aware, detect the failure 302 (1), Shipment and begins transmitting packets for the connection with any other forwarder 302 in the group. In this example, the other transfer block 302 is a block 302 (2), Shipment. Although Figure 28 illustrates the case of failure, the switches 202 (LBA), load-balancing-aware may also be sent on the traffic flow 302 (2) delivery, even if the block 302 (1), Shipment still valid. This change forwarder 302, initiated in the absence of failure, occurs, for example, because the switches 202 (LBA), load-balancing-aware, do not preserve the affinity of traffic 302 (1) forward. Any of a number of factors may cause switches 202 (erroneously) that traffic to another (unrelated), forwarder 302. For example, the traffic for the same session of a higher level can be supplied to switches 202 to another IP-source address or the source port when the source is on the other side of the truss proxies. The actions indicated in (2) - (5) are used in case of failure or in case the "wrong direction of traffic."

Position (2) indicates that 302 (2), Shipment reconciled with its routing table, a table 2206 (2) XRD. Unable to find a route for the packet, it forwards the packet to a classifier 304 (2). At (3), classifier detects that the packet is a "mid-session ', and classifier 304 (2) requests the DAM 2202 to route the packet. DAM 2202 responds with a route for a compound of the associated atomic element 2304.

At (4), classifier 304 (2) lays a route at block 302 (2), Shipment. Routing protocol is described below. At (5) indicates that the subsequent packets for this connection directed to block 302 (2), Shipment routed directly to the appropriate host, which in this example is host 108 (1) without checking with classifier 304 (2).

In general, the routing protocol for communication between the classifier 304 and forwarder 302 includes a command to add or delete paths. In particular, the classifier 304 sends a 302 block forwarding route add command to establish a route between the sending unit and the host 108 to this connection. For example, classifier 304 (2) can apply for a 302 (2) transfer the route add command, specified at 28 positions (4). Route (for example, the key and the corresponding value) is added to the local table 2206 (2) RDA for rapid access to a block 302 (2) delivery in the future. In this example, classifier 304 (2) is a device separate from the block 302 (2) forward, thereby routing protocol may be a protocol between devices. However, the routing protocol can also be used to connect the device.

In a described implementation, classifier 304 (2) contains a register of 2802 compounds. With the registry 2802 compounds classifier 304 (2) keeps track of any sessions forwarder 302 (e.g., 302 (2), Shipment) for which the classifier 304 (2) routed. To classifier 304 (2) can track connections including their termination unit 302 (2) forwards the final delivery sessions for packets (e.g., TCP FIN packet) to classifier 304 (2). Then the classifier 304 (2) removes from the register in 2802 compounds the element that corresponds to the session, and sends 302 (2) command to delete the route of delivery. Receiving the command to delete a route, 302 (2) removes the appropriate route of delivery from the table 2206 (2) XRD.

Thus, the function classification, together with the function of tracking sessions can manage routing tables and routes that use the shipment. Therefore, the function of delivery, which is divided in another device may be performed using a high speed but relatively simple equipment. Alternatively, classifiers 304 can be based on communication with the host 108, rather than the initial captured (or additionally thereto) (e.g., TCP SYN) and end (for example, TCP FIN) packets the session to determine the duration of the session. In other words, the classifier 304 may alternatively or additionally receive and use message 2008 (U / D) (start / end) of the session as described above in the section entitled "Track Session".

29 shows additional procedures failover to improve reliability of the infrastructure 106 for network load balancing. We describe failover procedures for two different malfunctions, failure and failure 2906 2902 It is shown that the infrastructure network load balancing 106 (not separately shown) has five components: 302 (1), Shipment, 302 (2), forwarder 302 (3 ) forwarding, classifier 304 (1) and classifier 304 (2).

In a 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 analogous procedures failover can be applied to the environment in which other components share the load balancing device. Also, similar or analogous procedures failover can be applied to media having other numbers, combinations, scale, etc. components.

Initially, according to the position [1], a router (s) / switch (s) 202 directs incoming packet, which proved relates to a novel compound, to a block 302 (1), Shipment. Since 302 (1) does not have a forwarding route for this connection in its local routing table, it forwards the packet to classifier 304 (1), as indicated by the dashed double arrow marked (1). Classifier 304 (1) first checks the session information with reference to block 308, session tracking for possible session affinity higher level. In this example, the packet does not have affinity to an existing session, so classifier 304 (1) selects host 108 with reference to information from health and load handler 314 reference to health and load.

In particular, in this example, classifier 304 (1) selects host 108 (1). Assuming that the packet is a session TCP / IP, classifier 304 (1) adds the session TCP / IP, tethered to the host 108 (1) to the DAM 2202 using function call "add atom" 2204 (A). Classifier 304 (1) or 302 (1) sends an initial delivery packet to host 108 (1). Classifier 304 (1) also paves the route in the local routing table 302 (1), Shipment. Subsequent packets 302 (1) sending to the host 108 sends (1) has no interaction with classifier 304 (1).

At some point during the compounds [1] 302 (1) forwarding fails. This fault is detected in 2902 by the router (s) / switch (es) 202 (LBA), aware of the load balancing. As a result, at point 2904, the router (s) / switch (s) 202 is sent further packets that were to be sent to a block 302 (1) send by the compound [1], on the other forwarder 302, in this example 302 (2) shipment.

Thus, 302 (2) receives the further forwarding packets to compound [2]. Because 302 (2), Shipment has no entry in its local routing table for packets that were previously sent at block 302 (1), Shipment, 302 (2), Shipment sends the first received packet compound [2] to a classifier which it is assigned / with which it is associated. In this example, 302 (2), Shipment assigned classifier 304 (2), as indicated by the dashed double arrow (2).

Classifier 304 (2) uses the function call "request atom" 2204 (Q) to obtain an atomic entry 2304 (not explicitly shown) of the DAM 2202 that is associated with the existing connection TCP / IP. This atomic entry 2304 is provided by DAM 2202 session tracker 308 through the function call "return atom" 2204 (R). Classifier 304 (2) extracts the host 108 (1), which has an affinity for this compound TCP / IP, the return of the atomic element 2304. Classifier 304 (2) forwards the first packet received for the compound [2] to host 108 (1) and also paves the route in the local routing table 302 (2), Shipment. Subsequent packets 302 (2) forwards the delivery without the interaction with classifier 304 (2).

The above descriptions are focused mainly on the failure of individual components of the forwarder 302. However, the classifier component 304 can also experience a failure. For example, at some point there is a failure 2906 at classifier 304 (2). 302 (2) Shipping 2906 detects a failure when you try to consume service classification or by notice to the absence of some indication of efficiency, such as a pointer type "pulse". For treatment failure 2906, 302 (2), Shipment reassigned to another or re-classifier 304 associated with it, which in this example is a classifier 304 (1). Classifier 304 (1) provides the block 302 (2) sending additional classification function indicated by the dashed double arrow (3).

30 shows the operational implementation of traffic routing interaction with health and load information. Forwarder 302 and classifier 304 communicate with processor 314 health and load for routing packets to hosts 108 (1), 108 (2) ... 108 (n). While shown forwarder 302 and classifier 304, operational implementation is also applicable to a request router 306 (or, in general, to the traffic routing functionality 2012).

It has been shown that host 108 (1) contains the endpoints IP1, IP3 and IP4 applications and application №1 №2 applications, respectively. Host 108 (2) contains the endpoints IP2 and IP6 applications and application №1 №2 applications, respectively. Host 108 (n) comprises an application endpoint IP5 №2 application. Processor 314 health and load monitors these hosts 108 (1), 108 (2) ... 108 (n) and the endpoints IP1, IP2, IP3, IP4, IP5 and IP6 applications (e.g., using the infrastructure 1202, health and load, unified cache 1208 and load, etc.).

In a described implementation, (1), classifier 304 requests one or more distributions of application endpoints (e.g., by at least one distribution 1802 Query application endpoints) in a medium where the marker used distribution circuit 1806. Handler 314 loads and operability in this example answers, providing marker distribution 3002 (e.g., by at least one response 1804 to target application endpoint allotment).

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

At (2) means that the forwarder 302 receives an initial incoming packet for the new connection. Since no routing for this new compound as part of a local table 2206 forwarder 302 is not present, then the forwarder 302 forwards the initial packet to classifier 304, as indicated by numeral (3).

At (4), classifier 304 (e.g., determining that the initial packet contains a reference to a session for a session of a higher level) selects an application endpoint (and thus, the host 108) in accordance with the health and load information. In particular, new compounds, which must be serviced №1 application, classifier 304 may select any of IP1, IP2 and IP3, if the marker to the corresponding end point still exists.

The classifier 304 may consume markers any of many possible ways. For example, classifier 304 may use circular approach regardless of the number of tokens to the endpoint. Alternatively, according to the linear approach, the classifier 304 may just start to move through the IP1 and IP3, consuming all the markers for each endpoint before moving on to the next endpoint. Further, classifier 304 may consume at any time marker from the group of markers, depending on the endpoint, which currently has the highest number of markers. According to the latter approach, classifier 304 selects IP1. You can also use other approaches.

Results, classifier 304 uses the marker to application endpoint IP2. Consequently, the consumption for the group of markers marker IP2 decreases markers 35 to 34 markers. Furthermore, the initial packet for the new connection should be routed to the application endpoint IP2.

Position (5A) represents the initial shipment packet classifier 304 to application endpoint IP2 of host 108 (2). Before, during or after delivery classifier 304, as indicated by (5B), paves the route for this connection in the local area of ​​the table 2206. The classifier 304 may also add an atomic entry 304 for this session in a table 2206 for distribution and duplication. At (6) represents forwarded further packets for this connection / session with the forwarder 302 to application endpoint IP2 of host 108 (2) using the local routing table of forwarder 302, implemented as a local area of ​​the table 2206 in Figure 30.

Figure 31 shows the mechanisms for ensuring high reliability of the infrastructure 106 for network load balancing. In particular, it shows the failure detection 3104, processing 3,106 correction of 3108 and the failure of failure. These mechanisms ensure high reliability described with respect to various components of infrastructure 106 for network load balancing. Components infrastructure network load balancing 106 includes a forwarder 302, a classifier 304, a request router 306, session tracker 308 and processor 314 health and load.

At 3102 (A) a local failure of forwarder 302. 3104 (A) indicates that a failure is detected, at least one switch, load-balancing-aware. To handle local failure 3102 (A) of the switch, load-balancing aware, it redirects packets to the other (s) flow (s) of delivery that indicated at 3106 (A). To recover from the failure of forwarder 302 routes, locally stored at block 302 the forwarding again constructed that indicated at 3108 (A) on the block (s) of the shipment, which redirected packets using Distributed Manager session tracking and tables, in particular DAM and table. Thus, distributed session tracking manager can provide redundant data for one or more levels.

At 3102 (B), a local failure classifier 304. At 3104 (B) indicates that a failure is detected, at least one delivery unit. To handle local failure 3102 (C) forwarding unit, to detect a fault, redirects packets to the other (s) classifier (s), as indicated by reference numeral 3106 (B). To recover from the failure of the classifier 304, the session information, locally stored on the classifier 304 re-constructed, which is indicated by reference numeral 3108 (B), on the classifier (s) to which packets are redirected using DAM. This session information may be, for example, session information of a higher level than the basic compounds of TCP / IP. Furthermore, the session information may be considered as part of session tracking infrastructure, hosted on the same device as the classifier 304.

At 3102 (C) a local failure of the router 306 queries. 3104 (C) indicates that a failure is detected, at least one delivery unit and / or switch-aware load balancing. To handle local failure 3102 (C) forwarding unit and / or the switch, knowing the load-balancing, redirects packets to the other (s), router (s) requests as indicated by reference numeral 3106 (C). Some current logical queries that are running the router 306 queries after the occurrence of local failure 3102 (C) may be lost if a duplicate every single logical request until the request is processed. To recover from the failure of the router 306 query session information, and / or routes, locally stored on the router 306 requests re-constructed, which is indicated by reference numeral 3108 (C) to the router (s) of the query, which forwards the packets (and thus, new Boolean query ). Re-construction of the session information can be carried out using XRD. Again, such session information may be considered as part of session tracking infrastructure, hosted on the same device as the router 306 queries.

At 3102 (D) a local failure monitoring unit 308 of the session. 3104 (D) indicates that a failure is detected, at least one delivery unit and / or the classifier. For example, if the session tracker 308 is placed on the same device as the classifier may detect the failure of delivery unit or other classifier. If the session tracker 308 is placed on a separate device, it can detect a failure qualifier. To handle local failure 3102 (D), for information tracked session established redundancy one or more levels and distribution of multiple devices, as indicated by 3106 (D). It should be noted that the redundancy allocation and set to failure 3102 (D). To recover from the failure block 308 session tracking session information from the tables of DAM can be redistributed and re-duplicated at the at least two devices (if they have no allocated and not duplicated sufficiently), as indicated by reference numeral 3108 (D), for processing the second level of failure.

At 3102 (E), a local failure handler 314 health and load. At 3104 (E) indicates that a failure is detected, at least one classifier and / or router queries. For example, the component can detect failure of receiving information from health and load handler 314 health and load handler 314 if the health and load stops responding, especially if the processor 314 health and load is not placed on the device that hosts the requesting component. To handle local failure 3102 (E) for health and load information using the redundancy data and the health and load internal processing failure, as indicated by reference numeral 3106 (E).

For example, each processor 314 health and load cache may comprise a combination of load and 1208, which duplicates information in tables 1204 and the load on multiple hosts 108. In addition, information consumers 1206, health and load handler 314 of the health and load may be placed on the the same device as the handler 314 health and load, so that this failure will be internally valid. Similarly, the official version of the information corresponding to 1206 is a health and load the appropriate host 108 due to a failure of the host 108 which makes the loss of the information relevant health and load rating.

To recover from the failure handler 314 health and load the network load balancing component that consumes the health and load information may request other health and load handler, because each such processor 314, the health and load information comprises a unified cache of health and load handler. Furthermore, when the processor 314 health and load again becomes available, it is possible to use the messaging protocol 1500 as indicated by 3108 (E) for re-constructing its unified cache of health and load information. Using these illustrative arrangements provide high reliability can detect, process and correct bad infrastructure components 106 for network load balancing to mask such faults 102 for clients.

Transferring compounds Optional Tunneling and / or load balancing application layer

This section describes how to manipulate compounds such as transfer compounds may be used for network load balancing. This section links are primarily at fig.32-39 transfer function and compounds described, for example, provided by connection migrator 310 (Figure 3). As described above with reference to FIG. 3 and 4, each incoming connection at the load balancing infrastructure 106 may be terminated thereon. Thereafter, the compound can be transferred to host 108, so that the compound then terminates at the host 108. The connection migrator 310 is capable of transport compounds and can be placed partly on the host 108 to implement the transfer. Such compounds can be transferred in conjunction with the load balancing application-level classifier 304 and / or using tunneling through the tunneling unit 312.

Figure 32 shows an approach for network load balancing application layer transfer compounds. Load Balancing at the application level or at the level of 7, due to the adoption of decisions concerning the application processing connection. To perform load balancing application-level load balancing infrastructure 106 typically takes account of the data connection. While not using the routing query categorizer 304 normally reads the initial portion of the compound, and the compound then migrates together with the connection migrator 310 to 108 selected host.

For load balancing application layer in TCP-based medium, in general, a classifier 304 reads the initial part of the TCP-client data when deciding where to send the TCP-client connection. Thus, the logic of application level check customer data and makes decisions on load balancing based on these data. For example, if the compound is (unencrypted) HTTP connection, the classifier 304 can read the HTTP-header of the first HTTP-request to the compound, and may make decisions based on the contents of a header portion (e.g., URL, cookie, etc.). Although load balancing application-level tunneling connections and transfer are applicable to other protocols, in the examples herein is mainly used, TCP / IP.

It is shown that the load balancing infrastructure 106 (not specifically shown) comprises a forwarder 302, a classifier 304, the tunneling unit 312 and connection migrator 310 (and may, for example, routers / switches 202 (LBA), load-balancing-aware). Forwarder 302 corresponds to a virtual IP-address, and forwards the packet to the host 108, the selected classifier 304. Although this is for clarity and are not specifically shown in Figure 32, host 108 also comprise a transfer function of compounds 310 and 312 function tunneling.

In a described implementation, forwarder 302, a classifier 304, and connection migrator 310 (at classifier 304 and host 108), together with the TCP software on the classifier 304 and hosts 108 operate together to provide a connection migrator. Transferring the compounds shown in Figure 32, refers to the connection from client 102 (1), which typically terminates at classifier 304. After connection migration connection from client 102 (1) is terminated at host 108 (1). When the connection is terminated at host 108 (1), packets for the connection may be tunneled using tunneler 312 (in block 302 and sending host 108 (1)).

Position (1) indicates that the client 102 (1) sends a SYN packet to forwarder 302 to signal the start of a new TCP-connection. At (2) means that the forwarder 302 forwards this packet to classifier 304. At (3), classifier 304 receives the TCP-connection from the host 108 (whose identity is not yet known, the actual host 108 () assignment yet to be selected ). Over TCP classifier 304 sends a SYN-ACK packet to the client 102 (1).

Position (4) indicates that the client 102 (1) begins to transmit data. (Initial SYN packet may also contain data). The data is processed by classifier 304, which may consult with a specialized logic. Specialized logic can operate depending on whether the host 108 is capable of processing or better handle all types of requests or any compounds. Therefore, classifier 304 uses the data information and application health and load handler 314 health and load to determine a host 108, which is better or best suited for the treatment of the compound from the client 102 (1). In this example, the selected host 108 (1).

Position (5), classifier 304 sends a "blob" ("binary blob"), representing the state of TCP-connection to the host 108 (1). This connection state is aggregated connection migrator 310 in cooperation with the TCP stack on classifier 304. The blob comprises binary data from client 102 (1) is acknowledged by classifier 304, and TCP options, such as ordered quadruple TCP / IP, the initial sequence number, etc. .

At (6) indicates that the component transfer unit 310 the compounds on host 108 (1) (not explicitly shown in Figure 32), "inserts" is a compound in the TCP stack on host 108 (1) using the state of TCP connections from the binary- blob obtained from the classifier 304. This insertion state of the connection is carried out in cooperation with the TCP stack on host 108 (1), whereby the application 316 on host 108 (1), it appears that this compound is initially taken by the host 108 (1). Client 102 (1) 316, and applications on the host 108 (1) is not aware of the transfer connection.

At (7), classifier 304, in cooperation with the TCP stack on classifier 304 clears internal state maintained for that compound. This cleaning of the internal state of the classifier 304 is carried out on the "silence", ie client 102 (1) is not notified of the status of the connection reset. Classifier 304 also adds a route in the local routing table of forwarder 302, which indicates that the host 108 (1) is the destination for the packets of this connection.

At (8) indicates that the subsequent packets for the connection are routed by forwarder 302 to host 108 (1) without removing on or through the classifier 304. These packets can be handled in the same forwarder 302 that packets for connections that are classified and routed without using transfer connections. These subsequent packets can optionally be tunneled from forwarder 302 to host 108 (1) using the 312 tunneling. Tunneling Unit 312 is also indicated (dashed lines) for the connection migrator 310 to classifier 304, as defined (e), the parameter (s) used by tunneler 312 may be defined for a compound of the transfer and / or associated with the migrated connection. Exemplary implementations tunneling unit 312 are described below in particular with reference to FIG. 38 and 39.

Figure 33 shows a flowchart of a method 3300 connection migration from the first device to the second device. Flowchart 3300 includes seven blocks 3302-3314. Although FIG. 32 and 34-37 are devoted mainly transport compound in the environment of network load balancing as described herein transfer connections can be established between two units of the general form, each of which has a transfer function of a compound, such as in block 310 transfer compounds.

At block 3302, the first device accepts the connection. For example, the first device may check the incoming connection in accordance with one or more protocols of a protocol stack portion of the network stack. At block 3304 is received for the data connection on the first device. For example, these data may be received in the initial packet, which requests a connection, or in one or more packets that are received after making the connection.

At block 3306 occurs aggregation connection status for the received compound of the protocol stack (in a more general case of a network stack) at the first device. For example, the protocol state for one or more protocols of protocol stack can be compiled and aggregated by any of the data that have been acknowledged. At block 3308 a connection state sent from the first device to the second device. For example, the first state aggregated information may be sent using a reliable protocol to the second device.

At block 3310 the state of connection of the migrated connection is supplied from the first device to the second device. At block 3312 is inserted into the connection state in the protocol stack (in a more general case, the network stack) of the second device. For example, the compound may be "rehydrated" using protocols of the protocol stack of the second device to the program that are above the level of the protocol stack, did not know what the connection is to move the connection. In particular, the status of the protocol can be implemented in the protocol stack. Aggregated data connection status 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 unit, as if the connection does not end earlier than elsewhere.

Figure 34 illustrates an approach to connection migration from the perspective of the sender unit 3400. The transfer connections on device 3400 is performed, at least the transfer unit 310 compounds. As described, the apparatus 3400 - a device that is part of the infrastructure 106 for network load balancing. For example, the device 3400 may include a classifier 304, possibly in conjunction with the forwarding unit 302, a router 306 requests, etc.

It is shown that the device 3400 includes as part of its network stack a physical network interface (SIF) 3410, 3408 miniport SIF, protocol-hardware interface 3406, protocol stack 3404 and 3402 the level of the socket. The apparatus 3400 also includes a load balancing function 106, e.g., a classifier 304 at the application layer and the transport block 310 compounds. In particular, the compounds of the transfer unit 310 comprises a migrator intermediate driver 3414 and "gasket" 3412 transfer. Connection migrator 310 is capable of upload connection from the device 3400.

In the described implementation, the physical network interface 3410 may be a network adapter (CA) (for example, CA Ethernet), a wireless interface, etc. Although only one physical network interface 3410, the device may have a plurality of physical network interfaces 3410 (i.e., device 3400 may be connected to multiple data lines). Each physical network interface 3410 typically corresponds to one or more physical network addresses.

Miniport 3408 SIF - a software module that understands and provides an interface with a particular hardware implementation of a physical network interface 3410. protocol-hardware interface 3406 - a level that contains one or more of the appropriate interfaces between two or more of the relevant protocols and miniport 3408 SIF.

Protocol stack 3404 includes one or more respective modules, each designed for one or more respective protocols. Examples of such protocols are described below with reference to FIG. 36 and 37. In the context of the transitional protocol stack 3404 includes protocol state 3420 for each connection to the existing device-level sender 3400. 3402 socket is between the program, such as load balancing function 106, and the protocol stack 3404. Level 3402 provides a socket API 106 between the function of load balancing and 3404 protocol stack and allows, among other things, programs register with the compounds.

Migrator intermediate driver 3414, or more generally, the driver 3414 is located at the level of the transport 3406 protocol-hardware interface. Migrator shim 3412 is located between the transparent protocol stack 3404 and 3402 level of sockets.

When the initial packet (not shown), requesting a new connection, an apparatus 3400, the packet is forwarded upward from the physical network interface 3410 to 3408 miniport SIF through 3406 level protocol-hardware interface and protocol stack 3404. When a packet traverses one or more protocol stack 3404 protocol, it creates a state 3420 Protocol. Furthermore, as a result of this initial packet or because the load balancing function 106 accepts the connection, to consider the request on the device 3400 receives 3416 data.

During the migrator intermediate driver 3414 assigns a copy of data 3416 to the logic block 310 transfer compounds. When the load balancing function 106 issues a function call to "transfer connection", function call transfer arrives at the highest level protocol stack 3404, could begin to aggregate 3418 connection status. Compiled protocol state 3420 of one or more protocol stack 3404 protocols. In the implementation of TCP / IP protocol state 3420 may include (i) TCP-port and IP-addresses of the source and destination (for example, ordered quadruple TCP / IP), (ii) the state of the window TCP, (iii) the initial sequence number ( iv) the suspension information, (v) fragment IDs IP, (vi) routing information, and (vii) etc.

Aggregating the connection state 3418 also aggregates data 3416 reserved for connection migrator 310 and already acknowledged from the device 3400 (e.g., a function of load balancing 106). This compound aggregated state 3418 includes protocol state 3420 and data 3416 (and, optionally, other information relevant to the connection). Then, the aggregated state of compound 3418 is transmitted as a binary blob 3422 from device 3400 to the destination device.

Binary blob 3422 may be sent from the device 3400 to the destination device using a reliable protocol. By "reliable" can be understood, for example, that the binary blob 3422 is received at the destination device without modification, even if the individual packets that make up a binary blob 3422, lost or damaged. This binary blob 3422 may also be packaged with the flow identifier, if the connection is subject to a further block 312 tunneling through tunneling. Stream ID described below, particularly with reference to FIG. 38 and 39.

Figure 35 illustrates an exemplary approach to connection migration from the perspective of the destination device 3500. The device 3500 similar to the destination device 3400 shown with respect to different levels / modules including connection migrator 310. However, it is shown that, at least one application at the application layer 316 interfaces with the 3402 level sockets. Therefore, target device 3500 may comprise the host 108. Also, connection migrator 310 is able to upload connection from the device 3400.

In a described implementation, application 316 is the destination of the packet initiating the connection, adopted at the originating device 3400. target device 3500 receives a binary blob 3422 by sending device 3400. The binary blob 3422 includes the status of the connection associated with the compound in the portable target device 3500, and, optionally, a flow identifier. This connection state includes protocol state 3420 and acknowledged data 3416 (and possibly other information relevant to the connection).

During operation, when a binary blob 3422 reaches 3406 protocol-hardware interface transfer intermediate driver 3411 detects a blob transfer compound and recovered. Connection status is inserted in the 3502, to create the appearance of an application 316 that a compound originally ended at the target device 3500.

In particular, protocol state 3420 is inserted state 3502 compound introduced into protocol stack 3404. In a described implementation protocol state 3420 is being implemented on the first upper-layer protocols, and then protocols lower level protocol stack 3404. After the implementation of the protocol in 3420 state protocol stack 3404, data 3416 can specify application 3416 316. These data can provide application 316, as if they were part of the new and locally the finished compound.

Upon completion of insert 3502 connection state, connection initiated by a packet received at originating device 3400 is successfully carried out on the target device 3500. The subsequent packets for the connection can be forwarded directly to the destination device 3500 without passing through the device 3400, or at least, with only a simple routing and without subjecting them to the analysis of the application layer. Optionally, these packages can tunnel so that the migrator intermediate driver 3414 effectively operates as a virtual CA on a program basis, which is linked to the virtual IP-address. In other words, migrator intermediate driver 3414 (Figure 35) may comprise a virtual network adapter, attached to the address assignment unencapsulated packets.

Figure 36 shows an approach to a procedure 3600 for a connection migration unloading. Procedure 3600 migrate offload shows additional details of exemplary connection migration from sending device 3400 is shown that the overall protocol stack 3404 contains a stack 3404 (T) TCP, stack 3404 (I) and IP stack 3404 (A), Address Resolution Protocol (ARP) . However, alternatively, it is possible to use other stacks 3404 () specific protocols.

For example, the level of 3406 protocol-hardware interface may be implemented as a standard based on a standard interface specification Network (NDIS) under an operating system (OS) Microsoft® Windows®. Furthermore, the level of a socket 3402 can be implemented as a standard Winsock ™ environment (OS) Microsoft® Windows®.

In the described implementation, migrator intermediate driver 3414 includes a protocol-hardware interface 3406 at the joints with the stack 3404 (A) and ARP miniport 3408 SIF. The driver 3414 serves as a transfer target discharge procedure 3600 discharge transfer. The purpose of the discharge - a miniport protocol-hardware interface 3406 shown in this example. The migration uploading procedure 3700 (Figure 37), migrator intermediate driver 3414 serves as the trap loading.

In particular, migrator intermediate driver 3414 attached to each physical network interface 3410, through which one can carry TCP-connection. Migrator intermediate driver 3414 generally acts as a transit driver packages flowing up or down the network stack and not interacting with the packets otherwise. However, migrator intermediate driver 3414 does not interact with the packages related to the transfer of the compound (optionally including a tunneled packets later).

Migrator intermediate driver 3414 is responsible for the following: (i) the adoption of transfer requests unloading; (ii) the state of aggregation of information protocol related to portability TCP-connection, compiled from stacks 3404 (), specific protocols, together with the acknowledged data for connection status information; and (iii) the transfer of the aggregate state of the connection to the destination device for the procedure 3700 3500 load transfer. Reliable wireline protocol for such a transfer can be shared so that the component 2002 and 2010, session tracking for sending and receiving session information 2008 (such as those described above with reference to Figure 20).

Another object of migrator intermediate driver 3414 (e.g., a migration uploading procedure 3700) is initiating a boot borne compounds, which it receives from other devices, and any buffering of incoming packets belonging to the transfer of the compound when it is loading. To load a compound intermediate driver 3414 sends a download request to migrator shim 3412. Migrator shim 3412 provides call insertion into protocol stack 3404 on the stack 3404 (A) TCP, to handle compound 3404 protocol stack portion of the network stack.

Migrator shim 3412 interface client opens the transport stack 3404 (T) and opens the TCP transport layer interface provider 3402 level sockets. Migrator shim 3412 plays two roles: (i) initiate a procedure 3600 migrate offload connections for device 3400, and then the process 3700 load transfer to the target device 3500, and (ii) mediates the classification process between the application program 316 of the host program classification 304 load balancing and the level of 3402 sockets. Gasket 3412 shipment and intermediate driver sending unit 3414 are described below with reference to FIG. 36 and 37.

For procedure 3600 illustrated migrate offload TCP-transfer compound is carried out after the classifier 304 classifies the incoming TCP-connection using one or two or more of its packets. 3600 discharge procedure is described by the transfer of positions <1> - <7>.

Position <1> is the initialization, which is done before surgery classification. Protocol stack 3404 makes queries at 3406 protocol-hardware interface, to determine what are the possible unloading, if present at all. Intermediate driver 3414 indicates that the unloading of the transport connection is available and extends down to the request miniport 3408 SIF. If the possibility of unloading "chimney» TCP provide physical network interface 3410, the miniport 3408 SIF as it indicates. Unloading "chimney» TCP allows you to unload some TCP / IP processing equipment physical network interface 3410, and provides a compilation of state 3420 Protocol. Therefore some logic compilation and aggregation can be shared by two mechanisms of discharge.

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

Position <3> means that the migrator shim 3412 initiates the transfer of TCP-connection to compile state protocol TCP. In particular, migrator shim 3412 causes the initiate migrate offload API TCP (or, more generally, a function call to "transfer connection" or the command transfer connection). This procedure compiles state for said corresponding TCP-connection is used for connection recovery on the target device 3500. The compiled protocol state 3420 includes a state of the intermediate stack layers, including the stack 3404 (T) TCP, stack 3404 (I) and IP stack 3404 (A) ARP.

Position <4> means that after the protocol stack 3404 compiled protocol state 3420 for portable TCP-connection, it calls the API to initiate migrate offload miniport to which it is attached; in this example, this is the intermediate miniport driver 3414. However, in practice, between protocol stack 3404 and the intermediate driver 3414 can be inserted into other intermediate drivers, such as IP QoS. In this case, the intermediate transfer unit drivers can participate in the transfer, if include compiling / aggregating their state information for the connection state of the migrated connection. Intermediate drivers continue to propagate the call "to begin unloading transferring" down to the network stack, which eventually leads to the execution handler discharge transfer on the intermediate driver 3414. In this intermediate driver 3414 also aggregates all unacknowledged data with the rest of the connection state for transferring TCP-connections on the target device 3500.

Position <5> denotes that after storing / copying state information for connections carried by TCP-compound intermediate driver 3414 notifies the network stack that the transfer is at its final stage, causing the API initiate migrate offload complete. This API initiate migrate offload complete reverse path goes up from the network stack through the same intermediate driver, if any, and finally to a 3404 protocol stack. As soon as each layer processes the call state information associated with the migrated connection can be released. While processing the call is completed, each level can send a notification about the update down to the network stack to update any portion of the state of the connection that changed since the transfer began.

Position <6> indicates that, when the procedure is complete the initial unloading of the transport reaches the stack 3404 (T) TCP, TCP silently (ie, sending the reboot command to the client 102) closes the connection by dropping all the state associated with the portable compound and It distributes the call "initial upload is complete transfer" for laying the 3412 transfer. This network stack is freed from any residual information carried by TCP-connection.

Position <7> means that when a call "initiate migrate offload complete" returns to the intermediate driver 3414 (through the packing portion 3412 transfer connection migrator 310), transferring TCP-connection from the device 3400 to a targeted device 3500 It may begin to transfer to a connection state. Connection status can be transmitted asynchronously and reliably.

After the start of the transfer device 3400 must also ensure that the following data from the client 102 is forwarded to the destination device 3500. Therefore, even after the successful transfer of the compound to the target sender retains a certain amount of state for the connection (for example, the routing table entry) in order to properly route subsequent packets to the destination. When the connection ends, the recipient shall inform the sender, to allow him to clear all the remaining state for the transferred connection.

Furthermore, due to the asynchronous nature of connection migration, the data packets for transfer compounds are forwarded device 3400 (or block transfer, seen as a separate device) may begin to arrive at the destination device 3500 before the target device 3500 receives state portable compound. Intermediate driver 3414 on the target device 3500 is responsible for the buffering of packets until the appropriate portable connection is established on the destination device 3500.

Figure 37 shows an approach to a procedure 3700 for load transfer connection. Migration uploading procedure 3700 illustrates exemplary details for a connection migration by the destination device 3500.

When a migrated connection arrives at the destination device 3500, it rests on the intermediate driver 3414 for processing. After the expansion and consolidation of the migrated connection state intermediate driver 3414 coupled to migrator shim 3412 inserts the migrated connection into the local network stack 316 transparently to the application procedure for transferring load 3700 discloses transfer TCP-connections in positions <1> - <8> .

Position <1>, as described above with reference to the 3600 discharge procedure of transfer represents initialization operations carried out to hostirovaniya applications. In particular, the protocol stack 3404 makes queries about which there are possibilities discharge, if any are available. Intermediate driver 3414 fills a support request transfer TCP-connection, to indicate that the loading of the transport connection is available, as well as distributes request down to the miniport 3408 SIF for possible discharge capacity "chimney» TCP.

Position <2> means that when data transfer connections arrive at the target device 3500, information transfer compound (e.g., packed binary blob 3422) is delivered to the intermediate driver 3414. Intermediate driver 3414 reassembles the connection status, agree it with any relevant data received during the transfer and prepared for loading on the network stack. Any data from the client 102 received in the boot process carried compounds buffered intermediate driver 3414. Upon successful completion of the transfer data will be delivered to the application 316.

According to the position <3> to initiate the upload of the migrated connection into the local network stack, intermediate driver 3414 notifies migrator shim 3412 of the migrated connection request arrives. Intermediate driver 3414 also delivers a connection state (or, at least, protocol state 3420) to migrator shim 3412.

Position <4> indicates that the migrator shim 3412 initiates the loading of the migrated connection, causing the initial insertion procedure of TCP (or, more generally, the procedure of implementing the protocol state) and the state issuing portable 3420 protocol stack 3404 (T) TCP. Position <5> indicates that TCP / IP connection via portable restores 3404 protocol stack using the 3420 protocol provided by the state. This protocol state 3420 may include one or more from a state of transport (TCP), track condition (IP), and the state of the next hop neighbor (ARP), etc.

Position <6> indicates that if the migrated connection is successfully re-established at the target device 3500 then initiates the TCP connect event the client-side migrator shim 3412 to indicate the establishment of a new connection. There are many possible reasons for failure, but the common causes may include a lack of an appropriate listener routing failure, etc. In these cases, when the network stack is not able to reinstall the migrated connection, does not specify any event the connection and call 'initial insertion completed "given the status of" failure. " Connection migrator 310 is responsible for cleaning transfer and sending a reset notification back to client 102 to terminate the connection.

Position <7> icon indicates that the migrator shim 3412 acts as a supplier, spreading connect event to the level of 3402 sockets to indicate the listener application 316 on the establishment of a new connection. If the application 316 accepts the connection, it processes the requests and responses through the normal read and write operations of the socket; application 316 may not know that the connection has been moved. If the application 316 does not accept the connection, TCP terminates the connection, but does not send a notice to reboot back to client 102. Again, in the call "initial insertion completed" status is set to "failure", and connection migrator 310 is responsible for cleaning the transport and shipment restart notification back to client 102 to terminate the connection.

A special situation arises when the application 316 and the classifier 304 are co-located on the same device: migrator shim 3412 can be the judge between them. When on the same host 108 has two classes of programs that they can both listen to one / one and one / the same IP-address (es) and the port (s). However, TCP is typically one listener at a unique IP-address and port. Therefore, migrator shim 3412 may obscure configuration when two programs listen on the same IP-address and port, multiplexing two single listener socket level TCP.

In this case, when the connection event arrive at the client portion of migrator shim 3412, migrator shim 3412, as a provider, determines on which listening socket deliver notification compound at 3402 sockets. If there is only one socket, listening to the corresponding IP-address and port of this socket receives the connect event. If more than one listening socket, the recipient depends on the context in which the specified event connection. If the compound event is brand new connection for the virtual-IP address, then the connect event is delivered to the classifier 304; if the event is the connection to the selected IP-address (IP-address without load balancing), or is the result of loading the migrated connection, the connect event is delivered to the target application 316.

Position <8> means that at the end of a TCP connection carried notifies migrator shim 3412, causing provided handler complete the initial insertion. The status code is provided to notify migrator shim 3412, whether the connection was successfully updated. If the load carried by the connection fails, the connection migrator 310 is responsible for cleaning of transport and for notifying the client 102 to terminate the connection by sending a restart command. If the migrated connection has been successfully inserted into the local network stack, the intermediate driver 3414 may begin delivering buffered data from the client 102, transmitting Preparation of (E) packet (s) through a packet reception path protocol-hardware interface 3406.

When a migrated connection ends (because of unsuccessful download of the fact that the compound transferred subsequently closed by normal means, etc.), target device 3500 notifies the originating device 3400. Device 3400 uses this notification to more efficiently and reliably purify inactive for portable connections, including routing table entries. Therefore, to account successfully migrated compounds which randomly terminate in the future, migrator shim 3412 may monitor their operations and notify intermediate driver 3414 when the sockets therefor are closed.

Figure 38 illustrates an exemplary approach to packet tunneling between forwarder 302 and host 108. The encapsulated packets 3808 may be tunneled from forwarder 302 to host 108 without involving overhead for each transmitted packet. As described below, tunneling is performed using a flow identifier 3814 and table 3806 and encapsulation mapping 3810 blocks 312 (F) and 312 (N) tunneling, respectively, forwarder 302 and host 108, respectively. Flow identifier 3814 is inserted into the encapsulated packets 3808.

As noted above with reference to Figure 32, packets for the connection, which come after the transfer of the compound may be routed by forwarder 302 to host 108 (1) using a tunneling unit 312 via tunneling. According to the position (8) (Figure 32), forwarder 302 forwards those packets with subsequent delivery unit 302 having a network address of "F", to the host 108 (1) having a network address of "H1". As described above with reference to Figure 4, the forwarder 302 may perform TCA [NAT] semi-TCA, tunneling, etc., to route incoming packets to host 108 (1).

These inbound packets contain IP-address-destination virtual IP address (VIP) and IP-source address is "C1" for the packets coming from the client 102 (1). Packets routed to host 108 (1) have the IP-destination address and source address of C1 (for semi-TCA) or «F» (for full TCA). This rewriting of the address may interfere with some protocols that expect the client 102 (1) and host 108 (1) have identical types of source and destination addresses.

Therefore, at least for the total TCA reverse path from host 108 (1) to client 102 (1), which does not pass through the forwarder 302 is prohibited because host 108 (1) does not know the address of the client 102 (1). The direct path from the host 108 (1) to client 102 (1) are desirable in situations where the traffic from the host 108 (1) to client 102 (1) is especially high and / or significantly greater than the traffic in the opposite direction (e.g., when the host 108 ( 1) provides streaming media data to the client 102 (1)).

Tunneling through the tunneling unit 312, as described herein can provide identical kinds regarding addresses (and ports) of the source and destination clients 102 and applications 316 on the host 108. For example and with reference to FIG. 34 and 35, the tunneling unit 312 at each of forwarder 302 and host 108 may act as part of the intermediate transfer unit 3414 driver 310 transfer or together with him.

In the embodiment described with reference to Figure 38, connection migrator 310 provides encapsulation mapping 3812 between flow identifier 3814 and 3804 ordered quadruple TCP / IP. Connection migrator 310 may be associated with a classifier 304, and connection migrator 310 (optionally in conjunction with the classifier 304) may be located on the same device as the forwarder 302. Alternatively, connection migrator 310 (as well as classifier 304) may be located on a device other than the delivery block 302. Encapsulation mapping 3812 may alternatively be provided by the function block 312 of tunneling or in conjunction with, i.e., for example, placed on the classifier 304 or be connected to it.

As displayed in the ordered quadruple 3804 TCP / IP encapsulation via display 3812, flow identifier 3814 is used to identify the stream of encapsulated packets 3808 for a particular connection. Ordered quadruple 3804 TCP / IP comprises a network address (and ports etc.) For the source and destination for a particular connection in accordance with the protocol TCP / IP or any similar or equivalent protocol. Flow identifier 3814 is 32-bits in the described implementation, as it allows the flow identifier encoded in fields of the source and destination port, TCP segment header tunneled packets that can transmit tunneled packet without any extra cost of space tunneling. At destination ordered quadruple TCP / IP can be determined by searching an ordered quartet, which is associated with the flow identifier extracted from the field source port and destination. However, alternatively, it is possible to use other identifiers 3814 flow length, particularly for other protocols such as RTP Internet, etc.

Each flow identifier 3814 may identify a unique combination of devices from which to start tunneling (which in this example is forwarder 302). Flow identifier 3814 may be generated using any suitable mechanism, such incremental counter compounds. Alternatively, the initial sequence number (NPN) recipient TCP / IP, the compounds of the generated block transfer, an identifier 3814 may serve as the stream. In addition, it ordered quadruple 3804 TCP / IP is a more general case, a pair of source / destination. Each source value and destination value pairs separate source / destination can include an identifier of a network node (e.g., network address, port, some combination thereof, etc.) for the source and destination, respectively, this packet propagating on particular connection.

Connection migrator 310 provides encapsulation mapping 3812 host 108. Block 312 (H) tunneling the host 108 stores the encapsulation mapping 3812 in encapsulation mapping table 3810 as part 3810 (1) encapsulation mapping. Block 312 (H) tunneling may then use the flow identifier 3814 to display and identify a particular compound according to the ordered quadruple 3804 TCP / IP. Encapsulation mapping 3812 may optionally be communicated to host 108 as part of the packaged binary blob 3422 in connection migration operation.

Forwarder 302 also includes a component 312 (F) tunneling encapsulation mapping table 3806. In 3806 encapsulation mapping table stored item 3806 (1) encapsulation mapping that associates / displays ordered four 3804 TCP / IP to a particular compound in the flow identifier 3814. 312 (F) also obtains tunnel information display element 3806 (1) encapsulation of the display unit 310 transport connections (e.g., encapsulation mapping 3812).

Although only one element 3806 (1) and 3810 (1) encapsulation mapping table 3806 and encapsulation mapping table 3810 encapsulation mapping may be many such elements. These tables 3806 and 3810 display the encapsulation can be combined with other information, such as tables for the information session tracker 308 sessions.

When a device (e.g., forwarder 302) and the transmitting device (e.g., host 108), receiving the encapsulated packets 3808 only provide a tunneling between their encapsulation mapping table will probably have the same display elements encapsulation. Otherwise, encapsulation mapping table 3806 and encapsulation mapping table 3810, may have a different full set of 3806 () elements and encapsulation mapping 3810 () encapsulation mapping, respectively.

In operation, an incoming packet 3802 for a particular connection enters the forwarder 302. Specific compounds associated with an ordered quartet 3804 TCP / IP. Incoming packet 3802 contains four 3804 ordered the TCP / IP IP-address of the source (client 102), IP-destination address (virtual IP), TCP-port source (client 102) and TCP-port of destination.

312 (F) tunneling receives an incoming packet 3802 for tunneling to the host 108. Using ordered quadruple 3804 TCP / IP, block 312 (F) refers to the tunneling encapsulation mapping table 3806 to retrieve an element 3806 (1) encapsulation mapping. ID 3814 is extracted from the flow element 3806 (1) as a linked display encapsulation / orderly displayed on four 3804 TCP / IP.

To create an encapsulated packet 3808 312 (F) inserts a tunneling identifier 3814 in the flow area of ​​the port of the source and destination of the ordered four TCP / IP. These two parts of TCP are 16 bits each, which allows the insertion of 32-bit flow identifier 3814. Furthermore, for the part-IP header source address ordered quadruple TCP / IP, block 312 (F) inserts a tunneling IP-address «F» forwarder 302. For the part of the destination IP-header ordered quadruple TCP / IP, block 312 (F) inserts a tunneling IP-address "N" of the host 108.

Forwarder 302 routes / 3808 transmits the encapsulated packet to the host 108 and host 108 receives the encapsulated packet 3808 from forwarder 302. Component 312 (H) transfer to the host 108 detects that the encapsulated packet 3808 is tunneled packets to be decapsulate.

ID 3814 stream is extracted from the encapsulated packet 3808 and is used to find the corresponding ordered four 3804 TCP / IP, which is tied to the element 3810 (1) encapsulation mapping table 3810 display encapsulation. Ordered four 3804 TCP / IP is used by 312 (H) tunneling header to restore orderly Quartet 3804 TCP / IP initially adopted in 3802 on the incoming packet forwarder 302.

In particular, IP address of the F-302 is replaced by IP-transfer source address, and IP-address of the host 108 is replaced by H IP-destination address. Furthermore, flow identifier 3814 is replaced by the TCP-source port and TCP-destination. Decapsulated packet indicated by the host network stack 108 target application 316.

In general, the header portion of the packet, including part of a pair source / destination for the packet, which is not necessarily used for transmission of the packet can be used to transfer the identifier 3814 of flow. The pre providing at least a portion of the pair of source / destination host 108 for flow identifier 3814 may be used for tunneling (e.g., encapsulate and / or decapsulate) packets without involving encapsulation overhead on each packet. In addition, packages which have a full picture with regard to the protocol, you can tunnel without fragmentation.

Figure 39 shows a flowchart of a method 3900 of tunneling packets between a first device and a second device. For example, the first device and the second device may correspond to device 3400 and target device 3500, respectively, load balancing infrastructure 106 and a group of hosts 108, respectively. However, tunneling may be used in implementations of non-alignment of the load.

Flowchart 3900 comprises twelve blocks 3902-3924. Although the actions of flow diagram 3900 may be performed in other environments and by different software schemes, FIGS. 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 target device in a flow identifier mapping ordered quadruple TCP / IP. For example, originating device 3400 may send an encapsulation mapping 3812 that binds flow identifier 3814 to 3804 four ordered TCP / IP. At block 3914 the destination device receives the ID display flow ordered four TCP / IP on the sending device. For example, target device 3500 receives from the device 3400 encapsulation mapping 3812 that binds flow identifier 3814 to 3804 four ordered TCP / IP.

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

At block 3904 the sending device receives an incoming packet from the client. For example, device 3400 can receive from the client 102 an incoming packet 3802 having a header with an ordered quadruple 3804 TCP / IP. At block 3906 searches for the connection stream ID corresponding to the client package using an ordered four TCP / IP incoming packet. For example, it is possible to seek flow identifier 3814 to connect to the client 102 using ordered quadruple 3804 TCP / IP, it is displayed in the item 3806 (1) encapsulation mapping table 3806 encapsulation mapping.

At block 3908 is a replacement source IP and destination IP incoming packet IP-address of the sender of the sending and destination IP-address of the destination device, respectively. For example, the device 3400 may replace part of the IP-addresses of the four ordered 3804 TCP / IP header of the incoming packet 3802 IP-address of the device 3400 and the target device 3500.

At block 3910 the source port and destination port of the incoming packet flow identifier replaced. For example, originating device 3400 may replace the TCP-source ports and destination parts ordered quadruple 3804 TCP / IP header of the incoming packet flow identifier 3814 3802. At block 3912 the device-sender transmits the encapsulated packet to the destination device. For example, originating device 3400 may send to the target device 3500 encapsulated packet 3808.

At block 3916 the destination device receives the encapsulated packet from the sending device. For example, target device 3500 may receive from device 3400 encapsulated packet 3808. At block 3918 searches for the ordered four TCP / IP for the connection, the corresponding packets received from the client, using the flow identifier. For example, target device 3500 may refer to encapsulation mapping table 3810 to element 3810 (1) encapsulation mapping that maps a flow identifier 3814 ordered quadruple 3804 TCP / IP.

At block 3920 IP-address of the sender and the IP-address of the recipient are replaced by IP-source address and destination IP-address, respectively, using an orderly found four TCP / IP. For example, target device 3500 may replace the IP-address of the sending device 3400 and the destination 3500 in encapsulated packet 3808 IP-source address and a destination IP-address of the ordered quadruple 3804 TCP / IP, resulting from encapsulation mapping table 3810.

At block 3922 is replaced by the stream ID and the source port a destination port of the incoming packet using the determined ordered quadruple TCP / IP. For example, target device 3500 may replace the flow identifier 3814 in encapsulated packet 3808, TCP source port and TCP destination port-ordered quadruple of 3804 TCP / IP. At block 3924 the client package specified application on the destination device. For example, the encapsulated packet decapsulated version 3808 or 3802 indicates an incoming packet annex 316 destination device 3500.

Actions, aspects, features, components, etc., indicated in fig.1-39 represented as a circuit consisting of a series of blocks. However, the order, interconnections, layout, etc., used to describe and represent fig.1-39 should not be construed in a limiting sense, and any number of units permitted any combination, location update, addition, deletion, etc. . to implement one or more systems, methods, apparatus, protocol, media, API, apparatus, configurations, etc. for network load balancing. Furthermore, although the description herein includes references to specific implementations (and the exemplary operating environment shown in Figure 40) as shown and / or described implementations can be implemented by any suitable hardware, software, firmware, or combinations thereof and using any suitable network organization, transport / communication protocols, application programming interfaces (API), a client-server architecture, etc.

Operating environment PC or other device

Figure 40 shows the operating environment of the computer 4000 (or general device) capable of (wholly or partially) implementing at least one system, device, apparatus, components, configuration, protocol, approach, method, procedure, media, API , some combination thereof, etc. described herein for network load balancing. 4000 operating environment can use the following computer and network architectures or in battery life.

The operating environment 4000 is only one example of an environment and is not intended to suggest any limitation as to the scope of use or functionality of the applicable device architectures (including computer, network node, entertainment device, mobile appliance, general electronic device, etc.). Moreover, the computing environment 4000 (or the apparatus) should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in Figure 40.

Furthermore, network load balancing may be implemented by numerous other environments or configurations of general purpose or special purpose device (including 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 laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, video game machines, game consoles, portable or handheld gaming units, network PCs, minicomputers, mainframe computers, network nodes, distributed or multiprocessing computing environments that include any of the above systems or devices, some combination thereof, etc.

Implementations of the network load balancing may be described in the general context of instructions executable by the processor. In general, the commands executed by the processor include routines, programs, protocols, objects, interfaces, components, data structures, etc. that perform particular tasks and / or implement particular abstract data types. Network load balancing as described herein, in some embodiments, may also be practiced in distributed computing environments where tasks are performed by remotely-linked processing devices that are linked through a line and / or a communication network. Especially in a distributed computing environment, commands to be executed by a processor, may be located in separate storage media, executed by different processors and / or distributed on a data transmission medium.

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

Processors 4004 are not limited to the materials from which they are formed or applied in the treatment of these mechanisms. For example, processors 4004 may be comprised of semiconductors and / or transistors (e.g., electronic integrated circuits (ICs)). In this context, the commands executed by a processor, may be electronically-executable instructions. Alternatively, the mechanisms of processors 4004, and thus the computer 4002 may include, but not limited to, quantum computing, optical computing, mechanical computing (e.g., using nanotechnology), and so on

System bus 4008 represents one or more of the numerous types of bus structures including a memory bus or memory controller, a point to point connection, a switching fabric, a peripheral bus, an accelerated graphics port, and a processor or local bus using any variety of bus architectures. For example, such architectures can include an Industry Standard Architecture (ISA), Micro-Channel Architecture (MCA), an expansion bus standard ISA (EISA), a local bus Association Video Electronics Standards (VESA) local bus, and Peripheral Component Interconnect (PCI) also known as Mezzanine bus, some combination thereof, etc.

Computer 4002 typically includes a variety of media available to the processor. Such media may be any available media that is accessible by computer 4002 or another (e.g., electronic) device can access and includes both volatile and nonvolatile media, removable and non-removable media, storage media and communication media.

The system memory 4006 includes storage media accessible to the processor in the form of volatile memory, such as random access memory (RAM) 4040, and / or nonvolatile memory such as read-only memory (ROM) 4012. A basic system 4014 input / output (BIOS), containing the basic routines that help to transfer information between elements within computer 4002, such as during startup, is stored in ROM 4012. RAM 4010 typically contains data and / or program modules / instructions that are immediately accessible to the processor 4004 and / or presently being operated on them.

Computer 4002 may also include other removable / non-removable and / or volatile / non-volatile storage media. By way of example, Figure 40 illustrates a hard disk drive or disk drive array 4016 for reading from (typically) non-volatile magnetic media (not separately shown), and writing to a magnetic disk drive 4018 for reading from (typically) removable, nonvolatile magnetic disk 4020 (e.g., "floppy disk") and recording it and the optical disk drive 4022 for reading from (typically) removable, nonvolatile optical disk 4024 such as CD, DVD, or other optical storage medium and recording it. Hard disk drive 4016, magnetic disk drive 4018 and optical disk drive 4022 is connected to the system bus 4008 by one or more data media interfaces 4026. Alternatively, the hard disk 4016, magnetic disk drive 4018 and optical disk drive 4022 can be connected to the system bus 4008 by one or more other separate or combined interfaces (not shown).

The drives and their associated media processor-accessible, provide nonvolatile storage of instructions executable by a processor, such as data structures, program modules and other data for computer 4002. Although in the illustrated computer 4002 illustrates a hard disk 4016, removable magnetic disk 4020 and removable optical disk 4024, it is obvious that the storage commands available device, you can also use other types of media available to the processor, such as magnetic cassettes or other magnetic storage devices, flash memory, compact discs (CD), digital versatile disks (DVD) or other optical storage media, RAM, ROM, electrically erasable programmable read-only memories (EEPROMs), etc. Such carriers may also include so-called specialty or "wired" IP. In other words, for the implementation of data carriers exemplary operating environment 4000 can use any of the carriers available to the processor.

The hard disk drive 4016, magnetic disk 4020, optical disk 4024, ROM 4012 and / or RAM 4010 can hold any number of program modules (or other units or sets of instructions / code), including, for example, operating system 4028, one or more application programs 4030, other program modules 4032 and program data 4034.

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

Monitor / screen 4044 visual observation or other type of display device can also be connected to the system bus 4008 via an interface, such as a video adapter 4046. 4046 video adapter (or other component) may be or include a graphics card for processing graphics, requires more computational resources and to meet the requirements of the display. Typically, a graphics card includes a graphics processor (GPU) video memory (the cart), etc. to facilitate the rapid display of graphics and performance of graphics operations. In addition to the monitor 4044, other output peripheral devices can include components such as speakers (not shown) and a printer 4048 which can be connected to computer 4002 through the interface 4042 I / O.

Computer 4002 can operate in a networked environment using logical connections to one or more remote computers, such as remote computing device 4050. For example, the remote computing device 4050 can be a personal computer, portable computer (e.g., laptop, tablet computer, PDA, mobile station et al.), handheld computer or PDA, a clock, a gaming device, a server, a router, a network computer, a peer device, another network node, or another device of the above type, etc. However, remote computing device 4050 is illustrated as a portable computer that can include many or all of the elements and features described herein relative to computer 4002.

Logical connections between computer 4002 and remote computer 4050 are shown in a local area network (LAN) 4052 and a general wide area network (WAN) 4054. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, the Internet, fixed and mobile telephone networks, ad hoc and infrastructure wireless networks, other wireless networks, gaming networks, some combination thereof, etc. Such networks and communications connections are examples of transmission media.

When implemented in a LAN networking environment, the computer 4002 is connected to the LAN 4052 through a network interface or adapter 4056. When implemented in a WAN networking environment, the computer 4002 typically includes a modem 4058 or other means for establishing communications over WAN 4054. Modem 4058, which may be internal or external relative to the computer 4002 may be connected to the system bus 4008 via interface 4042 input / output, or any other appropriate mechanisms. It is obvious that the illustrated network connections are exemplary and that to establish the line (s) between the computers 4002 and 4050 can be used other means.

In addition, you can use other equipment, specially designed for servers. For example, computations for discharging SSL acceleration cards can use SSL. Furthermore, especially in the operating environment for network load balancing, can be installed and used on the server hardware devices discharge TCP and / or packet classifiers on network interfaces or adapters 4056 (e.g., network interface cards).

In a network environment, illustrated by means of the operating environment 4000, program modules or other commands described relative to the computer 4002, or portions thereof, may be fully or partially stored in a remote memory storage device. For example, remote application programs 4060 are placed in a memory component of remote computer 4050 but may be used or may be otherwise accessible via computer 4002. Also, for purposes of illustration, application programs 4030 and other commands to be executed by a processor, such as the operating system 4028 are illustrated herein as discrete blocks, although it is recognized that such programs, components, and other instructions are placed at different times in different storage components of the computer 4002 (and / or remote computer 4050) and executed by a processor (s) 4004, the computer 4002 (and / or remote computer 4050).

Although the systems, carriers, devices, methods, procedures, apparatuses, techniques, schemes, approaches, procedures, configuration, and other implementations have been described in language specific to structural, logical, algorithmic, and functional features and / or diagrams, it should be understood that the invention disclosed in the appended claims is not necessarily limited to the specific features described above or diagrams. Rather, the specific features and diagrams are disclosed as exemplary forms of implementing the claimed invention.