Network load balancing with main machine status information

Technical field of network load balancing using host status information

[0001] The present invention generally relates to network load balancing, and more particularly to the use of host state information for network load balancing, which is given by way of example but not as a limitation.

Background technique

[0002] Communication and many aspects of life involving communication have been greatly affected by the Internet. The Internet enables information to be transferred quickly and relatively easily between two persons and/or entities. The Internet includes many network nodes connected together so that information can be transmitted between them. Some network nodes may be routers that propagate packets from one link to another, personal client computers, personal networks for different entities (for example, corporate intranets), and so on.

[0003] In terms of personal networks and other networks, packets arriving at one or more Internet nodes are distributed to other nodes in the personal network. For example, such a personal network can be constituted by a group of servers, each of which acts on packets arriving in the personal network. Enterprises, universities, government offices, etc. can receive many packets in a short time frame in their personal networks. In order to respond in a timely manner and reduce the possibility of arriving packets being rejected and lost, the personal network can rely on multiple servers, each of which can act on the arriving packets at the same time.

[0004] The arrival group is usually a query related to certain information, such as documents, catalog items, web pages, and so on. Arrival groups can also be related to electronic transactions between customers and merchants. For a packet in a packet-based communication, other purposes are also possible. Regardless, arriving packets are distributed to different servers in a group of servers in order to accommodate fast arriving packets and/or complex communication exchanges.

[0005] The distribution of arriving packets among different servers in a group of servers is often referred to as network load balancing. In other words, when one or more nodes constitute a personal network and/or when they connect the personal network to the Internet, load balancing operations can be performed when these packets arrive at the one or more nodes.

[0006] Such a load balancing operation is accomplished by using dedicated hardware facing the personal network in the one or more nodes, which connect the personal network to the Internet and/or make the personal network exist on the Internet on. The physical hardware that performs the load balancing operation is usually dual-configured as a whole to implement a redundant configuration and improve the reliability of the load balancing operation. In order to increase the ability to use load balancing operations, it is necessary to replace the current load balancing hardware with more powerful hardware that completely replicates the current load balancing hardware and its operational performance. Therefore, this way of scaling up the performance of load balancing operations is limited to the ability to increase the hardware through substitution.

[0007] In order to implement load balancing operations, hardware usually performs round-robin distribution of incoming connection requests. In other words, the incoming connection requests are linearly distributed to multiple servers in a group of servers, that is, repeated in a way that each server is assigned a single connection request. This type of round-robin load balancing distribution of connection requests is usually used, regardless of the status of the personal network or the characteristics of the incoming connection requests. If the load balancing operation does exceed a circular distribution, only these other factors that can be inferred from the network traffic and/or the congestion level of the personal network are considered.

[0008] Therefore, there is a need for solutions and/or technologies that improve network load balancing and/or options related thereto.

Summary of the invention

CN 1578320 Β

[0009] In the first exemplary medium implementation, one or more processors accessible and accessible media include instructions executable by the processor, and when executed, instruct the system to perform the following operations, including: Accumulate host status information; and send the accumulated host status information from multiple hosts. In the second exemplary medium implementation, the medium accessible by one or more processors includes instructions executable by the processor, and when executed, instructs the system to perform the following operations, including: receiving from multiple hosts Host status information; and in response to the received host status information to make a load balancing decision. In the third exemplary medium implementation, the medium accessible to one or more processors includes instructions executable by the processor, which when executed, instruct the system to perform the following operations, including: Determine the health status and load information on the basis; and select an application from a plurality of applications in response to the health status and load information.

[0010] In the fourth exemplary medium implementation, the medium accessible to one or more processors includes instructions executable by the processor, and when executed, instruct the system to perform the following operations, including: The application endpoint analyzes the health status and/or load information; and in response to the analysis, determines token allocation for the plurality of application endpoints.

Media [0011] In the fifth exemplary media implementation, one or more processor-accessible comprises at accessible instructions executable the processor, when executed, enable the system to at least one host and one or more A message protocol is completed between the load balancing units, and the message protocol is used to transfer health status and/or load information between the at least one host and the one or more load balancing units.

[0012] In an exemplary system implementation, the system includes: at least one device that hosts one or more application programs, and the at least one device includes a health status and load table containing multiple entries, and the multiple Each entry in the entries is associated with one application of the one or more applications; each entry in the multiple entries includes: an application identification of a certain application of the one or more applications Symbol; information describing the characteristics of at least one state of the application; and at least one load balancing indication about the application.

[0013] Other methods, systems, methods, devices, application programming interfaces (APIs), devices, media, processes, configurations, and other implementation methods will be described here.

Description of the drawings

[0014] The same numbers are used throughout the drawings to represent the same and/or corresponding aspects, features, and components.

[0015] FIG. 1 is an exemplary network load balancing example illustrating a load balancing infrastructure and multiple hosts.

[0016] FIG. 2 is an exemplary network load balancing example illustrating multiple load balancing units and multiple hosts.

[0017] FIG. 3 illustrates an exemplary load balancing unit with separate functions and an exemplary host.

[0018] FIG. 4 illustrates an exemplary network load balancing infrastructure with separate classification and delivery functions.

[0019] FIG. 5 is a flowchart illustrating an exemplary method for extending a network load balancing infrastructure to different configurations.

[0020] FIG. 6 illustrates a first exemplary network load balancing infrastructure configuration from a device perspective.

[0021] FIG. 7 illustrates a second exemplary network load balancing infrastructure configuration from a device perspective.

[0022] FIGS. 8A and 8B illustrate first and second exemplary network load balancing infrastructure configurations from component perspective views. [0023] FIGS. 9A and 9B illustrate first and second exemplary network load balancing infrastructure configurations from a resource perspective. [0024] FIG. 10 illustrates an exemplary network load balancing method involving host status information.

[0025] FIG. 11 is a flowchart illustrating an exemplary method for network load balancing involving host status information.

[0026] FIG. 12 illustrates an exemplary method for network load balancing involving health status and load information.

CN 1578320 Β

[0027] FIG. 13A is an exemplary health state and load table illustrated in FIG. 12.

[0028] FIG. 13B is an exemplary joint health state and load cache illustrated in FIG. 12.

[0029] FIG. 14 is a flowchart illustrating an exemplary method for network load balancing involving health status and load information.

[0030] FIG. 15 illustrates an exemplary message protocol used to communicate between the host and the load balancing unit illustrated in FIG. 12.

[0031] FIG. 16 illustrates an exemplary message transmission scheme used to communicate between the host and the load balancing unit illustrated in FIG. 12.

[0032] FIGS. 17A and 17B illustrate an exemplary health state and load information proxy storage situation for the health state and load table of FIG. 13A and the combined health state and load cache of FIG. 13B, respectively.

[0033] FIG. 18 illustrates an exemplary target host allocation process using health status and load information.

[0034] FIG. 19 illustrates an exemplary network load balancing method involving session information.

[0035] FIG. 20 illustrates an exemplary network load balancing method involving the use of notification and messaging to pass session information.

[0036] FIG. 21 illustrates a flowchart of an exemplary method involving the use of notification and messaging session information for network load balancing.

[0037] FIG. 22 illustrates an exemplary method of managing session information in a multiple load balancing unit.

[0038] FIG. 23A is an exemplary session table shown in FIG. 20.

[0039] FIG. 23B is an exemplary distributed atom manager (DAM) table (DAMT) shown in FIG. 22.

[0040] FIG. 24 illustrates a flowchart of an exemplary method for managing session information in a multiple load balancing unit.

[0041] FIG. 25 illustrates an exemplary network load balancing infrastructure with a request routing function.

[0042] FIG. 26 illustrates a flowchart of an exemplary method for routing incoming packets according to (i) session information and (ii) health status and load information.

[0043] FIG. 27 illustrates an exemplary service routing flow when there is no failure.

[0044] FIG. 28 illustrates an exemplary service routing process when a failure occurs.

[0045] FIG. 29 illustrates an additional exemplary troubleshooting process to ensure high reliability of the network load balancing infrastructure.

[0046] FIG. 30 illustrates an exemplary operational implementation of the interaction of service routing and health status and load information.

[0047] FIG. 31 illustrates an exemplary high reliability mechanism of a network load balancing infrastructure.

[0048] FIG. 32 illustrates an exemplary method for application-level network load balancing in a connection transfer manner.

[0049] FIG. 33 illustrates a flowchart of an exemplary method of transferring a connection from a first device to a second device.

[0050] FIG. 34 illustrates an exemplary connection transfer method from a perspective view of the initiating device.

[0051] FIG. 35 illustrates an exemplary connection transfer method from a perspective view of the target device.

[0052] FIG. 36 illustrates an exemplary method of an uninstall process for connection transfer.

[0053] FIG. 37 illustrates an exemplary method of a loading process for connection transfer.

[0054] FIG. 38 illustrates an exemplary method of constructing a packet tunnel between a transmission device and a host.

[0055] FIG. 39 illustrates a flowchart of an exemplary method of constructing a packet tunnel between a first device and a second device.

[0056] FIG. 40 illustrates an exemplary computing (or general-purpose device) operating environment capable of (in whole or in part) implementing at least one aspect of network load balancing described herein.

CN 1578320 Β

Detailed ways

[0057] Typical Network Load Balancing Example

[0058] This part describes an exemplary example of network load balancing, and provides the basis, environment, context, and so on for the description of the following parts. This section mainly refers to Figure 1 to Figure 3.

[0059] FIG. 1 is an exemplary network load balancing example 100, which illustrates a load balancing infrastructure 106 and multiple hosts 108. In addition to the network 104 and the load balancing infrastructure 106, the exemplary network load balancing example 100 also includes multiple clients 102 (1), 102...102 (m) and multiple hosts 108 (1), 108...108 ( η).

[0060] Each client 102 may be any device capable of network communication, such as a computer, a mobile station, an entertainment device, another network, and so on. The client 102 may also be a person and/or entity that operates the client device. In other words, the client 102 may include logical clients that are users and/or machines. The network 104 may be composed of one or more networks, such as the Internet, an intranet, a wired or wireless telephone network, and so on. Other examples of the device used for the client 102 and the network type/topology used for the network 104 will be described in the section entitled "Exemplary Operating Environment of Computer or Other Device" with reference to FIG. 40.

[0061] An independent client 102 can communicate with one or more hosts 108 across the network 104 through the network load balancing infrastructure 106, and vice versa. The host 108 has one or more application programs for interaction/communication with the client 102 for use by the client 102 and the like. Each host 108 may correspond to one server and/or one device, multiple servers and/or multiple devices, a part of servers and/or devices, some combinations thereof, and so on. Some implementations of the host 108 will be further described below according to different network load balancing conditions. (However, for reasons of clarity, the back-end support of the host 108 is generally not shown.) Also, other examples of devices used for the host 108 will also refer to FIG. 40 under the title "Exemplary Computers or Other Devices" Described in the section "Operating Environment".

[0062] The load balancing infrastructure 106 may be obtained or located at one or more virtual Internet Protocol (IP) addresses through the network 104. The communication information from the client 102 (or other node) pointing to the virtual IP address of the load balancing infrastructure 106 is received and transmitted to the host 108. The load balancing infrastructure 106 is composed of hardware and/or software components (not shown clearly in FIG. 1).

[0063] Although the load balancing infrastructure 106 is represented as an ellipse as a whole, the structure that completes the load balancing operation can also be distributed to other parts of the exemplary network load balancing paradigm 100. For example, as described further below, the software components of the load balancing infrastructure 106 may be located on one or more hosts 108. An example of the architecture of the load balancing infrastructure 106 will be described in the section titled "Exemplary Operating Environment of Computers or Other Devices" with reference to FIG. 40.

[0064] As indicated by (1), one or more hosts 108 may provide host status information from the host 108 to the load balancing infrastructure 106. The host state information can be application specific. Examples of such host status information will be further described below, including health status and/or load information for the host 108, session information, and so on. A specific implementation that includes providing health status and/or load information from the host 108 to the load balancing infrastructure 106 will be described in the section titled "Exemplary Health Status and Load Processing" below.

[0065] At (2), a request is sent from the client 102 (1) across the network 104 to the virtual IP address in the load balancing infrastructure 106. The content, format, etc. of the request from the client 102 may depend on the application to which the request is directed, and the term "request" implies one or more responses from the host 108, depending on the context. The types of client requests include, but not limited to:

[0066] 1. A Hypertext Transfer Protocol (HTTP) GET request from a client using a browser program. Depending on the application (more specifically, depending on the uniform resource locator (URL) of the request), it may be better to serve the request through a different set of hosts, and the presence of the client "session" state on the host can affect the The request of a specific client is routed to a specific host. These requests can be placed on a secure socket layer (SSL) (or other encrypted) connection.

[0067] 2. Virtual Private Network (VPN) connection (for example, the host is a group of VPN servers). In this case, the "request" can be considered as a Layer 2 Tunneling Protocol (L2TP) or Point-to-Point Tunneling Protocol (PPTP) "connection" (the latter is the Transmission Control Protocol (TCP) control connection and related general routing encapsulation ( GRE) combination of data services).

[0068] 3. Terminal server connection (for example, the host is a group of terminal servers).

[0069] 4. A dedicated request for an independent TCP connection (one request for one connection) using a dedicated specific application protocol.

[0070] 5. Simple Object Access Protocol (SOAP) request.

[0071] 6. Involve the control information on the TCP connection and the real-time communication request of the delay-sensitive media stream on the real-time protocol (RTP).

[0072] Therefore, the request can take a variety of different, application-specific forms. In some of the described implementations, the load balancing infrastructure 106 can make application-specific delivery decisions.

[0073] At , the load balancing infrastructure 106 transmits the request from 102(1) to the host 108(2) (in this example). When selecting the host 108 on which the request is to be transmitted, the load balancing infrastructure 106 may consider one or more of a variety of factors, depending on which of the implementations described herein is used. For example, the load balancing infrastructure 106 may consider: the health status and/or load information of the application of each host 108, the session information about the client 102(1) stored in the host 108, and so on.

[0074] FIG. 2 is an exemplary network load balancing example 200, which illustrates a plurality of load balancing units 106 and a plurality of hosts 108. Specifically, the load balancing infrastructure 106 is shown in the exemplary network load balancing example 200 as a plurality of load balancing units 106, 106(2)...106(u). In addition, two routers and/or switches 202(1) and 202(2) are also illustrated.

[0075] The router/switch 202, if present, can be considered as a component or a separate part of the load balancing infrastructure 106 (FIG. 1). The router/switch 202 is responsible for sending all requests and independent packets received from the network 104 to the shared virtual IP (VIP) address of the load balancing unit 106. If the first router/switch 202 fails, the second router/switch 202 can take over the first router/switch. Although only two routers/switches 202 are illustrated, one or more than two routers/switches 202 may be selectively used.

[0076] The router/switch 202 may be unaware of the load balancing infrastructure or know about load balancing. If the router/switch 202 is not aware of load balancing, one of two exemplary options will be used: For the first option, a load balancing unit 106 is "assigned" to share the VIP address, and all network traffic is Is transferred to this address. The load balancing unit 106 then evenly redistributes these services on other load balancing units 106. However, for this first option, there are bottlenecks and failures (if multiple VIP addresses are shared and separated among multiple load balancing units 106, this can be reduced). For the second option, the router/switch 202 is "spoofed" to send network traffic to all load balancing units 106, and each load balancing unit independently determines what kind of services should be accepted for load balancing. However, for this second option, there are low-efficiency repetitions and switch performance/compatibility issues.

[0077] On the other hand, if the router/switch 202 is aware of load balancing, the router/switch 202 can distribute the incoming network traffic among the plurality of load balancing units 106 (for example, in a round-robin manner). It should be understood that this

The router/switch 202 that has load balancing awareness can perform primary (for example, in hardware) load balancing functions. For example, a router/switch 202 with load balancing awareness can perform simple IP address-based session affinity, so that all packets from a specific source IP address are sent to the same load balancing unit 106.

[0078] Each individually illustrated load balancing unit 106 of the load balancing unit 106 may represent one physical device, multiple physical devices, or a part of a single physical device. For example, the load balancing unit 106(1) may correspond to one server, two servers, or more. Optionally, the load balancing unit 106(1) and the load balancing unit 106(2) together may be equivalent to a single server. An exemplary load balancing unit 106 is further described below from a functional perspective with reference to FIG. 3.

[0079] Two exemplary request paths [1] and [2] are illustrated in FIG. 2. For the request path [1], the client 102 (2) sends a request through the network 104 to the router/switch 202 (1). The router/switch 202(1) sends the requested packet from the client 102(2) to the load balancing unit 106(1). Then, the load balancing unit 106(1) transmits the requested packet to the host 108(1) according to some load balancing function (for example, a policy). For the request path [2], the client 102 (m) sends a request through the network 104 to the router/switch 202 (2). The router/switch 202(2) sends the requested packet from the client 102(m) to the load balancing unit 106(u). Then, the load balancing unit 106 (u) transmits the requested packet to the host 108 (n) according to some load balancing function. An exemplary load balancing function will be further described with reference to FIG. 3 below.

[0080] FIG. 3 shows an exemplary load balancing unit 106 and an exemplary host 108 with separate functions. The load balancing unit 106 includes seven functional blocks 302-314. These functional blocks of the load balancing unit 106 can be implemented at least partially by software. The host 108 includes one or more application programs 316. In one described implementation, the load balancing unit 106 includes a transmission device 302, a classifier 304, a request router 306, a session tracker 308, a connection transfer 310, a tunnel 312, and a health status and load processor 314.

[0081] The health state and load processor 314 is partly placed in the host 108 and partly placed on the device of the load balancing unit 106. The health status and load processor 314 monitors the health status and/or load (or more generally, the status) of the host 108 so that its health status and load information are used for load balancing functions (for example, when making a load balancing decision). An exemplary implementation of the state of health and load processor 314 will be described further below, especially in the section entitled "Exemplary state of health and load handling."

[0082] The session tracker 308 may also be partly placed in the host 108 and partly on the device of the load balancing unit 106. The session tracker 308 monitors the sessions created by the client 102 so that the load balancing function can facilitate the reconnection/continuation of previously created sessions. For example, some applications maintain application-specific client session data (which is also a kind of host state information) on the host. These applications usually expect the client to use the same host during any given session. Exemplary types of sessions include: (i) a TCP connection (strictly speaking, a session); (ii) an SSL session; (iii) a secure IP (IPsec) session; (iv) an HTTP cookie-based session; and so on.

[0083] Although the session tracker 308 is exemplified as a discrete block in the load balancing unit 106, the session tracking function of the session tracker 308 can actually be implemented at a global level. In other words, session combination is supported by multiple load balancing units 106. The session tracker 308 includes a centralized database and/or a distributed database about the session information in order to maintain session cohesion. The exemplary implementation of the session tracker 308 will focus on the method of using a distributed database to be further described below, especially in the section titled "Exemplary Session Tracking".

CN 1578320 Β

[0084] The classifier 304 uses the data acquired and maintained by the health status and load processor 314 and/or the session tracker 308, possibly in combination with other factors, to classify the incoming requests. In other words, the classifier 304 selects a target host 108 for each request coming in from the client 102. The transmitting device 302 transmits the client request (and/or its packet) according to the target host 108 selected by the classifier 304. The transmission device 302 and the classifier 304 can operate in units of each packet. Exemplary implementations of the transmission device 302 and the classifier 304 will be further described below, especially in the sections titled "Exemplary Method for Flexible Network Load Balancing" and "Exemplary Classification, Delivery, and Request Routing".

[0085] The request router 306, which is different from the implementation of each packet of the transmission device 302 and the classifier 304, can act as a proxy for an application program running on the host 108. For example, the request router 306 may terminate the TCP connection, (perhaps partially) parse each logical request from the client 102, and resubmit each logical request to the target host 108. Therefore, according to the decision made by the requesting router 306, each logical request from the client 102 can be sent to a different host 108±o. Further, the requesting router 306 can perform preprocessing (for example, SSL decryption) on a connection, and can choose To absorb certain requests (for example, because the request router 306 maintains a cache of responses), they can be modified arbitrarily before the requests are transmitted to the host 108, and so on. An exemplary implementation of the request router 306 will also be described further below, especially in the sections titled "Exemplary Method for Flexible Network Load Balancing" and "Exemplary Classification, Delivery, and Request Routing".

[0086] The connection transfer 310 can cause the connection to be initially terminated at the load balancing unit 106 and then transferred, so that the connection is subsequently terminated at the host 108. This connection transfer is conducive to application-level load balancing. The connection transfer 310 can transfer the connection from the load balancing unit 106 to the host 108. The transfer method is that the original termination at the load balancing unit 106 is transparent to the application 316 requesting the client 102 and the newly terminated host 108 of. The tunneler 312 may use an encapsulation scheme to form a packet tunnel, and this method does not need to introduce overhead in each tunneled packet.

[0087] The function of the tunneler 312 can also be used without involving connection transfer. Moreover, the connection transfer 310 and/or the tunnel 312 can also be used in non-load balancing implementations. Exemplary implementations of the tunneler 312 and the connection transfer 310 will be described further below, especially in the section titled "Exemplary Connection Transfer Using Optional Tunneling and/or Application Level Load Balancing".

[0088] Any given implementation of the load balancing unit 106 may include one or more of the exemplified functions. Although illustrated separately, the function of each of the blocks 302-314 may actually be related to, overlap with, and/or contain other functions. For example, the state of health and the state of health and/or load information of the load processor 314 may be used by the classifier 304. Moreover, the connection transfer 310 and the tunnel 312 may work together with the transmission device 302 and the classifier 304. Some other exemplary cases of mutual overlap and interaction are described below.

[0089] In one described implementation, the host 108 runs and provides access to one or more application programs 316. Generally, the application program 316 includes a file delivery program, a website management/server program, a remote access program, an email program, a database access program, and so on. Specifically, but not limited to this, the application program 316 may include a web server such as Internet Information Server ® (IIS) from Microsoft Corporation, such as a Microsoft Terminal Server TM (Terminal ServerTM). ), and firewall and proxy products such as Internet Security and Acceleration ServerTM (ISA). Although the specific application program 316 is given as an example in the foregoing description as a product of Microsoft Corporation, the network load balancing described herein is not limited to any specific merchant, application program, or operating system.

CN 1578320 Β

[0090] Example method for flexible network load balancing

[0091] This section clarifies how the network load balancing implementations described in this and other sections provide a flexible method for network load balancing. This section mainly refers to Figure 4 to Figure 9B.

[0092] As noted above, the network load balancing function can be improved by replacing the first network load balancer with a second larger and stronger network load balancer. In addition to providing a larger capacity, the hardware capability of the second network load balancer replicates all the hardware capabilities of the first network load balancer. This is a very inefficient and inflexible method, especially when the only feature of network load balancing is to limit performance and prompt the upgrade of the network load balancer.

[0093] FIG. 4 illustrates an exemplary network load balancing infrastructure with separate classification and delivery functions. The separate classification function and transmission function are implemented by the classifier 304 and the transmission device 302, respectively. Although the classification and delivery functions will be described further below, especially in the section titled "Exemplary Classification, Delivery, and Request Routing", the interaction between the network load balancing infrastructure function and the host 108 is used here as The example gives a preliminary description.

[0094] In a described implementation, the transmission device 302 corresponds to a virtual IP (VIP) address and serves as a network endpoint of the virtual IP address. The transmission device 302 is a relatively low-level component that makes simple and/or preliminary policy decisions (if any) when routing packets to the next or final destination. The transmission device 302 determines the destination by querying the routing table. The classifier 304 populates the routing table based on one or more factors (for example, host status information), which will be further described in other parts here.

[0095] The client 102 and the host 108 also correspond to the specified network addresses. Specifically, the client 102(1) corresponds to the address C1, and the client 102(2) corresponds to the address C2...The client 102(m) corresponds to the address Cm. Similarly, the host 108(1) corresponds to the address H1, and the host 108(2) corresponds to the address H2... The host 108(n) corresponds to the address Hn.

[0096] Five communication paths (1)-(5) are shown in FIG. 4. The communication path (1) is between the client 102 (1) and the transmission device 302, and the communication path (5) is between the transmission device 302 and the host 108 (1) Between. The communication path (2)-(4) is between the transmission device 302 and the classifier 304. In this example, for simplicity, the connections associated with communication paths (1)-(5) are HTTP TCP connections. In addition, load balancing in this example involves routing incoming connections to the least loaded host 108, at least without directly considering application-level load balancing.

[0097] The communication paths (1)-(5) instruct the transmission device 302 and the classifier 304 how to load balance an HTTP TCP connection from the client 102(1). At (1), the client 102(1) initiates a TCP connection by sending a TCP SYN packet addressed to the VIP address. The routing infrastructure of the network 104 routes the packet to the delivery device 302 through the router/switch 202(1), which is the router/switch that is closest to the delivery device 302.

[0098] At (2), the transmission device 302 queries the routing table to find the connection. The routing table may be internal to the transmission device 302 or accessible from the transmission device. The connection can be identified in the routing table by the TCP/IP 4-tuple (ie, source IP address, source TCP port, destination IP address, destination TCP port). Because this is the first packet of the connection, there is no entry in the routing table. Therefore, the transmission device 302 applies the "default route" action, that is, sends the packet to the classifier 304.

[0099] At , the classifier 304 queries the host 108(1), 108(2)...108(n) for its (for example, combined) cache of host status information. The classifier 304 concludes that the host 108(1) is available, which in this example is the host 108 with the least load at this moment. The classifier 304 also "explores" from the routing table queried by the transmitting device 302 for the TCP connection

CN 1578320 Β

Plumb is a route. For example, the classifier 304 adds a route entry or instructs the transmission device 302 to add a route entry to the routing table, which connects the TCP connection (for example, by the The TCP 4-tuple identified) is mapped to a specific destination host 108, which is host 108(1) in this example. More specifically, the routing entry specifies the network address H1 of host 108(1) .

[0100] At (4), the classifier 304 sends the TCP SYN packet back to the transmission device 302. Alternatively, the classifier 304 may transmit the initial TCP SYN packet to the host 108(1) without using the transmitting device 302. Other available options of the classifier 304 are described further below.

[0101] At (5), the transfer device 302 can access a routing entry for the connection represented by the SYN packet, and thereby transfer the packet to the host 108(1) at the address H1. For this connection, the transmitting device 302 also directly transmits all subsequent packets from the client 102(1) to the host 108(1). In other words, for this connection, the transmission device 302 can avoid further interaction with the classifier 304. When the connection is stopped, one mechanism or a combination of multiple mechanisms can be used to delete the routing entry, which will be described further below.

[0102] For the communication path (5) in a multi-protocol environment, the transmission device 302 cannot simply send the packet from the client 102 (1) to the host 108 at the network address H1 as it is. (1), because these packets are addressed to the VIP address, and the VIP address is controlled by the transmission device 302 itself. On the contrary, the transmission device 302 may adopt one or more of the following exemplary options:

1. The transmission device 302 rewrites the source (client 102(1)) IP address (C1) and port number by (i) using the IP address of the transmission device 302 and the port number generated by NAT; and ( ii) Use the IP address (H1) of the host (108(1)) to rewrite the destination IP address (VIP) to perform network address translation (NAT) ο

[0104] 2. The transfer device 302 performs "Half-NAT" by rewriting the destination IP address (VIP) with the IP address (H1) of the host (108(1)) so that the source (client 102(1)) IP The address (C1) and port number can be reserved.

3. The transmission device 302 tunnels the packet received from the client 102(1) from the transmission device 302 to the host 108(1). Specifically, in this example, tunneling is accomplished by encapsulating each packet into a new IP packet addressed to the host 108(1). The network load balancing aware software on the host 108(1) reassembles the original packet received from the client 102(1) at the transmission device 302. The original packet is then directed to the virtual interface at the host 108(1) (for example, the VIP address corresponding to the transfer device 302 is tied to the virtual interface at the host 108(1)). An exemplary implementation of this tunneling will be further explained below with reference to the tunneler 312, especially for the case of connection transfer and especially in the example titled "Using Optional Tunneling and/or Application Level Load Balancing" Partial description of connection transfer.

[0106] Although FIGS. 4 to 9B illustrate two specific independent functions, namely, classification and transmission, other functions should be understood, such as request router 306, session tracker 308, connection transfer 310, The functions of the health status and load processor 314 can also be separately expanded (for example, individually converted into factors), as described below. Furthermore, it should be noted that one or more than two functions can be separated and expanded separately at different times and/or at the same time. Moreover, although TCP/IP is used in many examples in this section and other sections for clarity reasons, the principles of network load balancing described here are also applicable to other transmission and/or communication protocols.

[0107] In the exemplary manner of FIG. 4, network load balancing functions (such as those shown in FIG. 3) may be separated from each other for expansion purposes. They can also be separated to enhance usability and adopt a variety of dual configurations. Exemplary configurations for scalability and usability will be described with reference to FIGS. 6 to 9B after describing the method shown in FIG. 5.

CN 1578320 Β

[0108] FIG. 5 illustrates a flowchart 500 of an exemplary method for extending a network load balancing infrastructure to different configurations. The flowchart 500 includes three blocks 502-506. Although the operations of the flowchart 500 can be implemented in other environments with a variety of software solutions, Figures 1-4 and 6-9B are especially used to illustrate some of the methods. Aspects and examples.

[0109] At block 502, the network load balancing infrastructure operates in a first configuration. For example, each configuration can be related to the selection, coordination, and/or relationship between different load balancing functions; multiple and/or multiple or different devices of the same type; organization and/or layout of different components; Distribution and/or distribution; one or more of the like is related. At block 504, the network load balancing infrastructure is expanded. For example, separate load balancing functions can be expanded and/or concomitantly centralized in a separate and/or independent manner. At block 506, the extended network load balancing architecture operates in the second configuration.

[0110] As described above, by replacing the current network load balancing hardware with more powerful network load balancing hardware, the network load balancing function can be increased as a whole, thereby expanding the single-chip network load balancer. In contrast, expanding the network load balancing infrastructure can enable network structure balance (sub) functions to be individually and/or independently expanded. It also enables network load balancing functions to be extended together or individually among and among different numbers of devices. Examples of equipment, components, and resource-oriented extensions are given below.

[0111] FIG. 6 illustrates a first exemplary network load balancing infrastructure configuration from a device perspective. In this first device-oriented network load balancing infrastructure configuration, three devices 602 (1), 602 (2), and 602 (3) are illustrated. However, alternatively, one, two, or more than three devices 602 may be used.

[0112] As illustrated, the transfer device 302(1), the classifier 304(1), and the host 108(1) reside and execute on the device 602(1). The transfer device 302(2), the classifier 304(2), and the host 108(2) reside and execute on the device 602(2). Likewise, the transfer device 302(3), the classifier 304(3), and the host 108(3) reside and execute on the device 602(3). In this way, in the first device-oriented network load balancing infrastructure configuration, each transmission device 302, classifier 304, and host 108 share the resources of their respective devices 602.

[0113] In operation, the transmission device 302 is the network endpoint of the VIP address. Any classifier 304 can detect the route of any host 108 for a connection, depending on the status information of the host. For example, the classifier 304(2) can detect a route to the host 108(3) for a new incoming connection. According to a new routing entry for this connection, the transfer device 302(2) transfers subsequent packets to the host 108(3).

[0114] In an alternative device-oriented network load balancing infrastructure configuration, the illustrated first device-oriented network load balancing infrastructure can be extended by adding a fourth device 602(4) (not shown in FIG. 6). Clearly shown), it includes a transfer device 302(4), a classifier 304(4), and a host 108(4). On the other hand, if the classifier 304 (1-3) has given enough classification function, but the additional transmission function may be beneficial to the request processing of the host 108, then a fourth device 602(4) can be added, which includes Transmission device 302(4) and optional host 108(4). For this extended configuration, another classifier 304 (1.2. or 3) can detect the routing of the host 108 (1.2. or 3) and the host 108(4) (if any) for the transfer device 302(4) .

[0115] The first device-oriented exemplary network load balancing infrastructure configuration of FIG. 6 is particularly suitable for smaller master control situations, where separate devices for such network load balancing infrastructure are technically and/or economically It is not worth or feasible. However, when the master control responsibility is extended to a larger number (and/or greater demand for the same number) of hosts 108, or if the network load on the hosts 108 is significant, then the first exemplary network for devices The load balancing infrastructure configuration can be extended to accommodate this expansion, as represented by the second device-oriented network load balancing infrastructure configuration shown in Figure 7.

CN 1578320 Β

[0116] FIG. 7 illustrates a second exemplary network load balancing infrastructure configuration from a device perspective. In this second device-oriented network load balancing infrastructure configuration, three devices 602 (1), 602 (2), and 602 (3) are illustrated. Also, one, two, or more than three devices 602 may optionally be used.

[0117] As illustrated, the delivery device 302(1) and the classifier 304(1) reside and execute on the device 602(1). The transfer device 302(2) and the classifier 304(2) reside and execute in the device 602(2)±. Likewise, the delivery device 302(3) and the classifier 304(3) reside and execute on the device 602(3). In this way, in the second device-oriented network load balancing infrastructure configuration, each transmission device 302 and classifier 304 does not share the resources of their respective devices 602 with the host 108. Moreover, the network load balancing infrastructure can serve any number of hosts 108.

[0118] In operation, the transmission device 302 also serves as a network endpoint of a VIP address. Similarly, any classifier 304 can detect the route of any host 108 for a connection, depending on the status information of the host. For example, the classifier 304(3) can detect a route to the host 108(2) for a new incoming connection. According to the new routing entry for this new incoming connection, the transfer device 302(3) transfers the subsequent packet to the host 108(2).

[0119] Thus, for example, a network load balancing infrastructure implemented in software can be extended by moving the network load balancing infrastructure (or part thereof) from a device shared with the host 108 to a device not shared with the host 108. Moreover, as implied in Figure 6 above, another device 602(4) can be added to the network load balancing infrastructure to provide additional transport functions, additional classification functions, and these two types of additional functions ,and many more.

[0120] FIGS. 8A and 8B illustrate first and second exemplary network load balancing infrastructure configurations from component perspective views. As illustrated, the first component-oriented exemplary network load balancing infrastructure configuration 800 includes four components. The second component-oriented exemplary network load balancing infrastructure configuration 850 includes six components. An optional second configuration 850 includes a seventh component illustrated by a dashed block, which will be described further below.

[0121] Specifically, the first component-oriented exemplary network load balancing infrastructure configuration 800 (or the first configuration 800) includes (i) two transmission devices 302(1) and 302(2), and (ii) Two classifiers 304(1) and 304(2). The second exemplary component-oriented network load balancing infrastructure configuration 850 (or second configuration 850) includes (i) four transmission devices 302(1), 302(2), 302(3), and 302(4) and (ii) Two classifiers 304(1) and 304(2). In this way, the first configuration 800 is expanded to the second configuration 850 by adding two components, which in this example are transport components.

[0122] In a described implementation, each functional component related to network load balancing corresponds to a respective device (not shown in FIGS. 8A and 8B); however, each component may optionally correspond to Part of a device or more than one device. For example, the transmission devices 302(1) and 302(2) can be distributed to three devices. Alternatively, the transfer device 302(1) and the classifier 304(1) may correspond to one first device, and the transfer device 302(2) and the classifier 304(2) may correspond to a second device.

[0123] Two functional components related to network load balancing are added to extend the first configuration 800 to the second configuration 850. However, one component (or more than two components) can optionally be added to extend the network load balancing infrastructure. In addition, two or more different types of functional components can be expanded "simultaneously". For example, as illustrated by the dashed block, when extending the first configuration 800 to the second configuration 850, another classification component (for example, the classifier 304(3)) can be added.

[0124] Moreover, it may be expanded by two or more different types of functional components in a similar (for example, equivalent) or dissimilar ratio to each other. As illustrated, adding conveyor components 302(3) and 302(4) without adding any sorting component 304 or adding a single classifier component 304(3), which means expanding at dissimilar scales.

CN 1578320 Β

exhibition. However, when two conveyor components 302(3) and 302(4) are added to expand in similar proportions, two classifier components 304(3) and 304(4) can be added (the latter is not shown in Figure 8B). show). In any case, as described with reference to FIGS. 9A and 9B, each individual functional component related to network load balancing may consume a different amount of resources of the effective network load balancing infrastructure.

[0125] FIGS. 9A and 9B illustrate first and second exemplary network load balancing infrastructure configurations from a resource perspective. The first resource-oriented exemplary network load balancing infrastructure configuration 900 (or the first configuration 900) includes a first resource distribution or allocation for the load balancing unit 106. The second resource-oriented exemplary network load balancing infrastructure configuration 950 (or the second configuration 950) includes a second resource distribution for the load balancing unit 106.

[0126] As illustrated, the first configuration 900 includes a 70%-30% resource distribution, and the second configuration 950 includes a 40%-60% resource distribution. Such resources may include all device resources (for example, the number of devices), processing resources (for example, the number of cycles of the processor), memory resources (for example, cache memory, main memory, etc.), network bandwidth and/or interface resources (For example, the number of bits per second and/or physical network interface card (NIC)), etc.

[0127] Specifically for the first configuration 900, the transmission device 302 consumes 70% of the resources of the load balancing unit 106, and the classifier 304 consumes 30% of the resources. After the reallocation during the expansion process of generating the second configuration 950, the transmission device 302 consumes 40% of the resources of the load balancing unit 106, and the classifier 304 consumes 60% of the resources.

[0128] In an exemplary case, when fewer, longer things are being processed by related hosts (not shown in FIGS. 9A and 9B), the first configuration 900 may contribute to a better network Load balancing performance, because the classification function is used in the initial communication of a connection and the transmission function is used after that. On the other hand, when more and shorter transactions are processed by related hosts, the second configuration 950 may contribute to better network load balancing performance because the classification function is used to balance the total number of packets through the network load balancing infrastructure A greater percentage of. In this case, if the request routing function is also used, the request router 306 is also allocated a certain percentage of the total computing resources. The distribution of resources among the three functions can be adjusted according to the current resource consumption and/or shortage during connection processing (for example, adjustment when "not working").

[0129] As indicated above with reference to FIGS. 2 and 3, each load balancing unit 106 may correspond to all or part of the entire network load balancing infrastructure 106. For any given physically, logically, arbitrarily, etc. defined or prescribed load balancing unit 106, its resources can be reallocated during the expansion process. More specifically, during the expansion process, the resource distribution among/among different separate functions related to network load balancing of the load balancing unit 106 may be changed. In addition, in addition to other functions related to network load balancing that are not specifically illustrated in FIGS. 9A and 9B, different resource percentages may be allocated to two or more different functions.

[0130] The percentage of the entire system resources allocated to all load balancing functions can be changed during the expansion process. As an example of general processing power, the percentage of all processing power dedicated to load balancing can gradually increase as the amount of traffic that needs to be load balanced increases.

[0131] The network load balancing software can optionally perform monitoring to analyze and determine whether resources should be reallocated. For example, network load balancing software can monitor the processor utilization of different functions related to network load balancing. The actual reallocation can also optionally be performed automatically by the network load balancing software in offline or online mode.

[0132] It should be understood that the scalability of the network load balancing infrastructure described herein (for example, realized at least in part by software) may involve different installation settings, and it is not necessary to change to a single installation setting. In a resource-oriented example, the network load balancing infrastructure described here can be configured according to one resource distribution in one installation environment, and can be configured according to another resource distribution in another installation environment with different operating parameters. Configuration.

In addition, the capabilities, features, options, etc. described above regarding expansion can also be applied to "scale in". In other words, the resources dedicated to the network load balancing infrastructure (or its sub-functions) can also be reduced.

[0133] Sample health status and load handling

[0134] This section describes how host status information, such as health status and/or load information, is collected and used in network load balancing. This section mainly refers to FIGS. 10-18 and clarifies the health status and load functions such as the functions provided by the health status and load processor 314 (in FIG. 3). As described above with reference to FIG. 3, each host 108 hosts one or more application programs 316. The health status and load processor 314 utilizes the health status and/or load information related to the application program 316 and/or the host 108 to perform certain described implementations of network load balancing.

[0135] FIG. 10 illustrates an exemplary network load balancing method involving host status information (HSI) 1006. Each host 108(1), 108...108(η) respectively includes one or more application programs 316(1), 316...316(η). Usually these hosts 108 and these applications 316 clearly change state over time.

[0136] For example, the host 108 and the application 316 may accept new connections or not accept new connections. Moreover, they can also process customer requests quickly or slowly. In addition, they can reserve many resources or few unused resources. All or any part of these data or other data may include host status information 1006. Generally, the host status information 1006 gives an indication of the status of a certain aspect of the host 108 and/or the application program 316 running on it.

[0137] In a described implementation, each host 108(1), 108····108(n) includes a host status information (HSI) determiner 1002(1), 1002(2)... and 1002(n), respectively. Each host 108(1), 108(2)...108(n) also includes a host status information (HSI) propagator 1004(1), 1004(2)... and 1004(n), respectively. Each host status information determiner 1002 and/or host status information disseminator 1004 may be an integral part of a load balancing infrastructure (LBI) 106.

[0138] Each host status information determiner 1002 determines the host status information 1006 for its respective host 108 and/or application program 316 running on the host. The following will refer to FIGS. 12-14, especially FIG. 13A, for description. Exemplary techniques to determine these host status information 1006. Each host status information propagator 1004 propagates host status information 1006 to the load balancing infrastructure 106 for its respective host 108 and/or application 316 (e.g., those parts of the load balancing infrastructure 106 that are not placed on the host 108 ). An exemplary technique for propagating these host status information 1006 will be described below with reference to FIGS. 12-17, particularly FIGS. 13B and 15-17.

[0139] Specifically, each host status information propagator 1004 propagates (directly or indirectly) the host status information 1006 to each load balancing unit (LUB) 106 of the load balancing infrastructure 106, and the infrastructure includes at least A state of health and load processor 314 and/or classifier 304. When performing network load balancing, the load balancing infrastructure 106 refers to the host state information 1006. For example, as indicated by the logic part 1008, the load balancing infrastructure 106 can make a load balancing decision based on the host state information 1006.

[0140] In the operation of (1), the host status information determiner 1002 determines the host status information 1006 for the respective host 108 and/or application 316. At (1) and (2), the host status information propagator 1004 will Host state information 1006 is propagated from the host 108 to the load balancing infrastructure 106. For example, the host state information 1006 can be propagated to a separate load balancing unit 106. At (3), the logic part 1008 makes a network load balancing decision based on the host state information 1006. At , according to these network load balancing decisions, the connection is transferred to the target host 108.

[0141] FIG. 11 illustrates a flowchart of an exemplary method for network load balancing involving host status information

CN 1578320 Β

1100ο The flowchart 1100 includes three blocks 1102-1106. Although the operations of the flowchart 1100 can be implemented in other environments with a variety of software solutions, some aspects and examples of the method are illustrated in particular with FIGS. 1-3 and 10.

[0142] At block 1102, host status information is sent from the host to the load balancing unit. For example, the host state information 1006 may be sent from the host 108 to the load balancing unit 106. At block 1104, the load balancing unit receives host status information from the host. For example, the load balancing unit 106 may receive host status information 1006 from the host 108. At block 1106, a load balancing decision is made based on the received host status information. For example, the logic part 1008 may make a decision to perform load balancing in the load balancing unit 106 according to the host state information 1006.

[0143] In this way, in FIG. 10, the load balancing infrastructure 106 collects host state information 1006 from the host 108 (and/or its application 316), and loads incoming requests directed to the host 108 according to the host state information 1006. balance. As further described below with reference to FIGS. 12-18, the host state information 1006 may be application specific. And as further described below, examples of the host status information 1006 include health status and/or load information.

[0144] FIG. 12 illustrates an exemplary network load balancing method involving health status and/or load information (HLI) 1206. The hosts 108(1), 108...108(η) are coupled to the load balancing units 106(1), 106...106(η) through a communication connection 1210 such as a network.

[0145] As illustrated, the host 108 uses the communication connection 1210 to transmit the health status and load information 1206 to the load balancing unit 106. As indicated by the double arrow shown, the two-way communication between the health status and load information 1206 refers to the two-way communication from the load balancing unit 106 to the host, which provides a certain degree of integrity, consistency, correctness, etc., to This allows the host 108 and/or the load balancing unit 106 to be independent of each other when a failure occurs. This two-way communication from the load balancing unit 106 to the host 108 will be further described below in particular with reference to FIG. 15.

[0146] The health status information reflects whether a given host and/or application can handle client requests. The load information reflects the number, amount, and/or level of client requests that a given host and/or application can handle at a certain time. In other words, the load can directly and/or conversely reflect the available number, amount, and/or level of the total capacity of a given host and/or application. As described above, the implementation described with reference to Figures 12-18 is for health status and/or load information. However, those implementations can also be applied to general host (including its application) status information.

[0147] In a described implementation, each host 108(1), 108(2)...108(n) includes its own state of health and load infrastructure (H&LI) components 1202(1), 1202(2)... 1202 (η). Each state of health and load infrastructure component 1202 may optionally be part of a load balancing infrastructure 106 that resides and runs on each host 108. The health status and load information 1206 can be implemented by software. When working, each health state and load infrastructure 1202(1), 1202(2)...1202(η) creates and maintains a respective health state and load (H&L) table 1204(1), 1204 (2)··· 1204 (η).

[0148] These health status and load tables 1204 may include entries for specific applications. The health state and load information 1206 stored in the health state and load table 1204 may be independent of the load balancing infrastructure 106. For example, administrators, designers, etc., can specify standards for health status and load information 1206 during configuration. In addition, the host 108 or an external entity of the device that owns the host 108 can be used to determine the health status and load information 1206 for the application 316 on the device. The following will further describe an exemplary health status and load table 1204 with reference to FIG. 13A.

[0149] Each load balancing unit 106(1), 106(2)...106(u) includes a respective consolidated health state and load (H&L) cache 1208(1), 1208(2)... · 1208(u). The health status and negative of each joint

CN 1578320 Β

The load cache 1208 includes information from each health state and load table 1204(1), 1204(2)...1204(n). Therefore, each load balancing unit 106 is equipped with fast (eg, cached) access to the health status and load information 1206 of each host 108, and the load balancing unit 106 performs load balancing of network traffic for each host 108.

[0150] In operation, the state of health and load infrastructure 1202 pushes the state of health and load information 1206 from the state of health and load table 1204 into the combined state of health and load cache 1208. This mechanism for providing health status and load information 1206 is an event-driven mechanism, which enables changes in the health status and load table 1204 to be provided to the joint health status and load cache 1208 in a timely and scalable manner.

[0151] FIG. 13A is an exemplary state of health and load table 1204 shown in FIG. 12. In one described implementation, the health status and load table 1204 includes multiple entries 1302, each entry being associated with a different application 316. Each entry 1302 may correspond to a row in the health status and load table 1204 with three columns. These columns correspond to application identifier (ID) 1302 (A), application status characteristics 1302 (B), and load balancer indication 1302 (C).

[0152] Because each entry 1302 is associated with a certain application 316, a row is added every time an application is spin up (for example, by an administrator). Similarly, every time an application is closed, delete/remove a line. Similarly, when the value of each field in column 1302(A), 1302(B), and/or 1302(C) changes, they are modified/updated. For example, when the status feature value of a given application 316 changes, the value in the field of the application status feature 1302(B) of the entry 1302 of the given application 316 is updated.

[0153] Adding and deleting entries 1302 to the application program 316 can be implemented through input from the control manager of the host 108. For example, the control manager part of the operating system knows when the application program 316 is started and stopped because it dynamically participates in the start and stop of the application program 316. Therefore, the control manager can at least partially recognize that it has started an application 316, and the control manager can establish that it has at least partially stopped the application 316. The health status and load infrastructure 1202 can therefore be notified of the start and stop of the application program 316 by the control manager. Therefore, there is no need to provide this clear communication from the application 316 to the health state and load infrastructure 1202. An example of a control manager is the Service Control Manager (SCM) from Microsoft's Windows® operating system.

[0154] The application identifier 1302(A) includes information used to uniquely identify the application 316 related to the entry 1302. For the associated application program 316, the application program identifier 1302(A) may be one or more of the following: virtual IP address and port, actual IP address and port, protocol used, and information about any specific protocol. The protocol can be HTTP, IPsec, SOAP, etc. The information of a specific protocol can be a URL pattern or a string to further describe the application associated with the entry 1302. In this way, the application identifier 1302(A) particularly refers to a specific application endpoint on a certain host 108.

[0155] Other application identifiers can be selectively used. For example, in order to reduce the communication bandwidth, the application identifier 1302 (A) may be a 32-bit number that maps to the exemplary information described above in the load balancing unit 106 and the state of health and load infrastructure 1202. Moreover, any field in entry 1302 may actually contain a globally unique identifier (GUID), which is used as a key to find the real information of the field.

[0156] The application status feature 1302(B) includes information reflecting the status of the application 316 associated with the entry 1302. For the associated application 316, the application status feature 1302(B) includes the following: application health status, application load, and application capacity. The application health status is a quasi-Boolean value that indicates whether an application is working. The application health status can be good, failed, or unknown. The health status of the application program is a relatively instantaneous value, and when the health status value of the application program changes, it is transmitted to the load balancing unit 106 with a relatively low delay (for example, about one or several seconds).

[0157] The application load is a value that indicates the degree to which a given application is occupied or busy, and thereby directly or conversely indicates how much additional load the application can handle. The application load is a relatively slow or average value. If necessary, it can be smoothed by introducing a hysteresis mechanism to eliminate instantaneous glitches of increasing or decreasing load. It is relatively infrequently transmitted to the load balancing unit 106 (for example, approximately one to four times per minute). The value of application load is assigned a meaning related to application capacity.

[0158] The application capacity is a value indicating the maximum capacity of the application. For a given context, it is generally meaningful to choose it, but it is still flexible enough for other contexts. The application capacity is a unitless, limited number (for example, 0-99), which can be set during configuration. It can be based on processing power, memory size/speed, network access, some combination of them, and so on. The application capacity expresses the relative capacity among and among other applications of the same type in a group of hosts 108 (1, 2, ···n).

[0159] Therefore, relative to application capacity, application load is more meaningful. For a given application, the application load is a percentage of the application capacity of the given application. Optionally, the application load can be expressed as a unitless number, by which the percentage can be determined together with the value of the application capacity.

[0160] The load balancer indication 1302(C) includes information that reflects the indications established by the state of health and load infrastructure 1202 to the load balancing unit 106 with respect to the application 316 associated with the entry 1302. The desired and/or desired state. For the associated application program 316, the load balancer indication 1302(C) includes the following content: target load balancing state and current load balancing state.

[0161] The target load balancing state reflects the health state and the state of the instruction to the load balancing unit 106 required by the load infrastructure 1202. The current load balancing state reflects the health state and the current state of the instruction to the load balancing unit 106 known to the load infrastructure 1202 to be recorded in the load balancing unit 106. Therefore, the current load balancing state reflects the load balancing instruction, that is, the health state and load infrastructure 1202 expects the load balancing unit 106 to use a communication protocol to perform the current operation as instructed. Such an exemplary communication protocol will be further described with reference to FIG. 15 below. The interaction and relationship between the target load balance state and the current load balance state will also be further clarified based on the description of FIG. 15.

[0162] Each of the target load balancing state and the current load balancing state may take a valid value, an invalid value, or a draining value. A valid value indicates that the new request/connection is welcome and can target the application associated with entry 1302. The invalid value indicates that no additional packets should be delivered to the associated application. The exhaustion value indicates that for new requests/connections, no packets should be sent to the associated application, but for requests/connections that still exist, the packets should continue to be delivered to the associated application.

[0163] In a described implementation, the defined version of the respective health status and load information 1206 is stored in the health status and load table 1204 located in each respective host 108 of the plurality of hosts 108. With this implementation, if a host 108 crashes, the lost health and load information 1206 is related to those crashed applications 316. Therefore, there is a need for a highly reliable method that automatically does not need to copy data. However, the determined version of the health status and load information 1206 can be selectively stored elsewhere. Other such storage options include the load balancing unit 106 itself, a host 108 that stores and maintains health and load information 1206 for multiple other (including all other) hosts 108 (as a separate task or in conjunction with hosting Responsibility together), another separate and/or external device, etc.

[0164] If the determined version of the health status and load information 1206 is distributed to the host 108 (1, 2,...n),

CN 1578320 Β

If it is also stored and maintained in other places, the health status and load information 1206 can be redundantly stored for the purpose of high reliability (for example, also stored in a replicated device, backup device, etc.). An exemplary agent scenario for storing health status and load information 1206 will be described below with reference to FIGS. 17A and 17B. FIG. 17A is for an agent situation using the health state and load table 1204, and FIG. 17B is for an agent situation using a joint health state and load cache 1208.

[0165] FIG. 13B is an exemplary joint state of health and load cache 1208 illustrated in FIG. 12. In one described implementation, the combined health state and load cache 1208 in each load balancing unit 106 includes storage for the health state and load infrastructure 1202 in each host 108 in each health state and load table. At least part of the information in 1204. The cached health status and load information can be organized in any way in the joint health status and load table cache 1208.

[0166] As illustrated, the combined health and load cache 1208 contains a cache for each host 108(1), 108(2), -108(n), which replicates the respective host 108( 1, 2···η) and part or all of the information in the load table 1204. Specifically, the combined health status and load cache 1208 includes a cache for host #1 1304(1), a cache for host #2 1304(2)... a cache for host #η 1304(η) cache. In this way, the illustrated combined health state and load cache 1208 is organized on a wide level by hosts 108 (1, 2, ···n), where each individual cache 1304 includes a corresponding host 108 (1, 2···η) application-specific entries. Optionally, the combined health status and load cache 1208 can be organized on a wide level according to the type of application 316, where a separate block is specific to a particular host 108 (1, 2, ···n) further divided Application type. Other data structure formats can also be used.

[0167] FIG. 14 illustrates a flowchart of an exemplary method for network load balancing involving health status and load information. The flowchart 1400 includes eight blocks 1402-1416. Although the operations in the flowchart 1400 can be performed in other environments and with a variety of software solutions, in particular, Figures 1-3 and 12-13B are used to illustrate certain aspects of the method. And examples. For example, the operations of two blocks 1402-1404 can be performed by the host 108, and the operations of six blocks 1406-1416 can be performed by the load balancing unit 106.

[0168] At block 1402, the health status and load information at the host are determined. For example, the health status and load information 1206 for the application 316(2) may be determined by the health status and load infrastructure 1202(2) and stored in the health status and load table 1204(2) of the host 108(2). At block 1404, the determined state of health and load information is propagated to the load balancing unit. For example, the state of health and load infrastructure 1202(2) may send the state of health and load information 1206 for the application 316(2) to the load balancing unit. 106(1,2, -u)_oAs indicated by arrow 1418, the operations of blocks 1402 and 1404 are repeated, so that the (application) health status and load can be continuously monitored and updated as changes occur.

[0169] At block 1406, receive health status and load information from the host. For example, the load balancing unit 106(1) can receive health status and load information 1206 from multiple hosts 108(1, 2,...n), which contains information about the application 316(2) of the host 108(2) Health status and load information 1206. At block 1408, the received health status and load information is cached. For example, the load balancing unit 106(1) may store the health status and load information from the host 108(1, 2, ···n) into the joint health status and load cache 1208(1). Referring to the implementation of the combined health status and load cache 1208(1) of FIG. 13B, the health status and load information 1206 of the application program 316(2) from the host 108(2) can be stored for host# 2 1304(2) in the cache. As indicated by arrow 1420, the operations of blocks 1406 and 1408 are repeated so that the (application) health can be received continuously.

CN 1578320 Β

Status and load information are updated as changes occur.

[0170] As indicated by the dashed arrow 1422, the load balancing unit 106 handles the communication from the client 102 while processing the (application) health status and load issues. At block 1410, a packet requesting a new connection is received. For example, the load balancing unit 106(1) may receive a TCP SYN packet from the client 102(2) through the network 104. At block 1412, query the cached health status and load information. For example, the load balancing unit 106(1) may query the joint health status and load cache 1208(1). In particular, the load balancing unit 106(1) can query the caches for the host #1, #2...#η 1304 (1, 2...η) and the address pointed to by the TCP SYN packet. Entries associated with the application. [0171] At block 1414, a host is selected based on the cached health status and load information. For example, the load balancing unit 106(1) may select the host 108(2) with the application 316(2) based on the health status and load information 1206 cached in the combined health status and load cache 1208(1). The selected application 316 (and the host 108) should be healthy and able to accept additional load (for example, it may be the application with the least load among those applications of the type of application pointed to by the TCP SYN packet).

[0172] The query of the cached health status and load information (at block 1412) and the host selection based on the cached health status and load information (at block 1414) can be performed after receiving a specific new connection The request is grouped before and/or using a batch solution to execute. Moreover, the selection can be based on any of a variety of schemes. For example, a token-based or round-robin scheme can be used. With either approach, the choice may involve the relative load weighting between application options. This query and selection using token-based or loop-based schemes will be further described below with reference to Figure 18 and in the section titled "Exemplary Classification, Delivery, and Request Routing", especially in the section on classification functions. description.

[0173] After the target host is selected at block 1414, a new connection request packet may be sent to the host. At block 1416, the received packet from the client is transferred to the selected host. For example, the TCP SYN packet is transmitted from the load balancing unit 106(1) to the selected host 108(2). The transmission of this initial packet can be performed directly by the classifier 304 or the transmission device 302, as described further in the section entitled "Exemplary Classification, Transmission, and Request Routing."

[0174] For a described implementation, the state of health and load infrastructure 1202 can be located in the load balancing unit 106 (as represented by the state of health and load processor 314), and can also reside and The health status and load infrastructure 1202 distributed to multiple hosts 108 ±o has three responsibilities. First, it reveals monitoring points to obtain application status updates for the application status feature 1302(B) of the health status and load table 1204. Second, it synthesizes application status information to determine what the load balancing unit 106 should do, which is embedded in the load balancer indication 1302(C). Third, the health status and load infrastructure 1202 transmits the indication from the host 108 to the load balancing unit 106.

[0175] The instruction content of the load balancer instruction 1302(C) is a valid summary version of the information about the application status feature 1302(B). However, in addition to receiving the processed instruction, the load balancing unit 106 may also receive the original information of the application status feature 1302(B). The communication of the contents of these and other fields of the health status and load table 1204 is accomplished by using a message protocol, which will be further described with reference to FIG. 15 below.

[0176] FIG. 15 illustrates an exemplary message protocol 1500 for communication of health status and load information between the host 108 and the load balancing unit 106 illustrated in FIG. 12. Generally, an event-driven mechanism is used to push the health status of the host 108 and the changes in the load table 1204 into the load balancing unit 106. In other words, for a description

CN 1578320 Β

In terms of implementation, when the health status and load table 1204 is updated, the information is transmitted from the host 108 to the load balancing unit 106. This avoids periodically sending all the snapshots of each health state and load table 1204, which reduces the network bandwidth consumed by the health state and load infrastructure 1202.

[0177] The messaging protocol 1500 can be implemented using any available messaging mechanism. Such mechanisms include reliable multicast transmission, point-to-point transmission (for example, User Datagram Protocol (UDP)), and so on. As illustrated, the message protocol 1500 includes seven message types 1502-1514: heartbeat message 1502, goodbye message 1504, row change message 1506, table snapshot message 1508, table snapshot message 1510, hypothetical Table status message 1512, and hypothetical error message 1514.

[0178] It should be understood that, with the exception of arrows 1516 and 1518, no temporal relationship is implied between or among different message types 1502-1514. For example, the line change message 1506 does not necessarily follow the goodbye message 1504.

[0179] The heartbeat message 1502 indicates that a certain host 108 is functioning, and relative to a corresponding cache for the host 1304 in the combined health status and load cache 1208, the corresponding health status and load table 1204 is The content provides some error checking. The health status and load infrastructure 1202 in each host 108 directly or indirectly sends heartbeat messages to the combined health status and load cache 1208 in each load balancing unit 106.

[0180] The heartbeat message 1502 addresses the issue of data staleness in the combined state of health and load cache 1208, partly because the overall snapshot of each state of health and load table 1204 is not periodically transmitted to each Caused by the load balancing unit. The transmission scheme for the heartbeat message 1502 will be further described below with reference to FIG. 16.

[0181] The heartbeat message 1502 includes a host identifier, error checking data, and optionally a DNS name. The host identifier can be a unique (for example, 32-bit) number, which is selected during configuration. The error check data can be, checksum, status change sequence number, generation number> CRC value, etc., which enables the receiving load balancing unit 106 to verify its combined health status and the contents of the load cache 1208 Whether it is consistent with the health status of the sending host 108 and the content of the load table 1204. If the generation number scheme is used, then multiple generation IDs can be used, and each generation ID is assigned to a "bulk" application. Depending on the context, the message can then refer to the block number or block number/generation ID pair.

[0182] The error check data may be a single value for all of the health status and load table 1204, or it may be multiple values determined on the basis of each entry 1302. The DNS name can optionally be sent (e.g., every "X" heartbeats) to verify or update the current correct network address for the host.

[0183] A goodbye message 1504 is sent from a certain host 108 to the load balancing unit 106 to indicate that the host 108 is planning to shut down. The goodbye message 1504 includes a host identifier, which can be indexed/mapped to a network address for the host 108. The goodbye message 1504 is used by the host 108 to clear, deliberately shut down, to facilitate "quick clear". However, if the goodbye message is lost, since the heartbeat message 1502 is no longer being sent, the cache will eventually make the host's 108 entry obsolete.

[0184] A row change message 1506 is sent from a certain host 108 to the load balancing unit 106 to indicate that the health status and/or load of a given application 316 of the host 108 has changed. The line change message 1506 includes a host identifier, an application program identifier, an operation, and data used for the operation. Exemplary host identifiers are described above with respect to the heartbeat message 1502 and the goodbye message 1504. An exemplary application identifier is described above with respect to the application identifier 1302(A) of the entry associated with the application of the health status and load table 1204.

[0185] Row change operations can be added, deleted or updated. In other words, the data used for the operation can be added (for

CN 1578320 Β

Add operation) or replace the information existing in the joint health state and load cache 1208 in the load balancing unit 106 (for update operation). For delete operations, no data is required. The message protocol 1500 is defined such that for a single row change message 1506, multiple operations can be specified. Therefore, for a certain host identifier, for the multiple application programs 316 of the host 108 identified by the host identifier, multiple sets of application program identifiers, operations, and operation data can be repeated.

[0186] The Obtain Table Snapshot message 1508 is sent from a certain combined state of health and a certain load balancing unit 106 of the load cache 1208 to a single host 108 or multiple hosts 108. The get table snapshot message 1508 requests the health status and load infrastructure 1202 of the host 108 to provide the respective host 108 with a snapshot of the respective health status and load table 1204. The message includes the identification of the request load balancing unit 106, and after (i) it has failed and then recovered; (ii) the host 108 failed, recovered, and started to send the heartbeat message 1502 again; (iii) if a row change message 1506 is sent to the load balancing unit 106, but the message is discarded, so that the joint health state and load cache 1208 and the respective health state and load table 1204 of the respective host 108 are out of synchronization; and (iv), etc. , Can be used by a load balancing unit 106.

[0187] For the third case (iii), the lack of synchronization between the combined state of health and load cache 1208 and the respective state of health and load table 1204 of the respective host 108 can be caused by subsequent follow-ups from the respective host 108 The heartbeat message 1502 is found because the "error check" will indicate that the combined health status and load cache 1208 is out of date. The load balancing unit 106 can then send a get table snapshot message 1508 so that it can update its joint health status and load cache 1208. In this way, for any of the three exemplary cases (i, ii, iii), the load balancing unit 106 then uses the obtained table snapshot 1508 to reconstruct its joint health state and load cache 1208. The obtained table snapshot 1508 may be repeatedly sent to each host 108 in a point-to-point manner, or sent to multiple hosts 108 at once in a multicast manner.

[0188] As indicated by arrow 1516, after a single host 108 has received a table snapshot message 1508 from a certain load balancing unit 106, a table snapshot message 1510 is sent from the host 108 to the load balancing unit 106 . The content of the sending table snapshot message 1510 may be prepared by the health state and load infrastructure 1202, and include all or at least multiple rows of the health state and load table 1204 of the single host 108, so that the load balancing unit 106 can be reconstructed Its combined health status and load cache 1208. The sending table snapshot message 1510 may be a separately designed message, or it may be equivalent to a series of adding operations in the row change message 1506.

[0189] The assumed table status message 1512 and the assumed error message 1514 are related to the load balancer indication 1302 of an entry 1302 in the health status and load table 1204 and the current load balance status. The target load balancing state is an indication that the state of health and load infrastructure 1202 expects the load balancing unit 106 to operate under this instruction. The current load balancing state is an indication that the state of health and load infrastructure 1202 expects or believes that the load balancing unit 106 is currently operating under this instruction. Generally, these two load balancing states are the same. [0190] However, during the transition period of the state indication change, the target load balancing state is different from the current load balancing state. For example, both the target load balance state and the current load balance state are initially set to be valid. When a problem with the host 108 and/or its application 316 is detected, the target load balance status indication is switched to an exhaustion indication. The row change message 1506 is used to send the exhaustion indication to the load balancing unit 106.

[0191] There is a delay before the indication change is marked in all the joint health states and load caches 1208 of all load balancing units 106. During this transition period, the target load balancing state is exhausted, and the current load balancing state is still valid in the health state of the host 108 and the load table 1204. Changing the current load balance status

Before changing to exhaustion, the health state and load infrastructure 1202 wants to ensure that the combined health state and load cache 1208 has actually been updated to the new exhaustion indication state.

[0192] In order to verify that the combined health status and load cache 1208 of the load balancing unit 106 has been updated to a new status indication, the health status and load infrastructure 1202 sends a hypothetical table status message 1512 to the load balancing unit 106. At a certain time (for example, a predetermined delay period) after the transmission of the row change message 1506 indicating that the status indication is to be changed, it is assumed that the table status message 1512 is sent. In this example, assume that the table status message 1512 indicates that the table status should be exhausted. As indicated by the dashed arrow 1518, if the combined health status and load cache 1208 of the load balancing unit 106 are different from the assumed status indication, then the load balancing unit 106 responds to the assumed table status message 1512.

[0193] If the combined health status and the indication in the load cache 1208 are different from the assumed status indication, the load balancing unit 106 sends a hypothetical error message 1514 to the health status and load basis of the host 108 that issued the hypothetical table status message 1512 Structure 1202. The state of health and load infrastructure 1202 then periodically retransmits the hypothetical table state message 1512 until no more hypothetical error messages 1514 from the combined state of health and load cache 1208 are received. At that point, the health state and load infrastructure 1202 sends a row change message 1506 with the new current load balance state. In this sense, the combined state of health and load cache 1208 is the final determiner of the current load balance state, and the state of health and load infrastructure 1202 is the final determiner of the target load balance state.

[0194] FIG. 16 illustrates an exemplary message transmission scheme for communication between the host 108 and the load balancing unit 106 illustrated in FIG. 12. This exemplary message transmission scheme can reduce the bandwidth consumed by the heartbeat message 1502 on the communication link 1210. The message transmission scheme in FIG. 16 is particularly suitable for the heartbeat message 1502, but it can also be used by other messages of the message protocol 1500.

[0195] A set of hosts 108 (1), 108 (2), 108 (3)...108 (11), and 108 (12) are carried out together with load balancing units 106 (1), 106 (2)...106 (u)Upillustration. Each line represents the member link or inclusion between the group of hosts 108 (1,2-12). The group of hosts 108 (1.2-12) constitute member nodes, and they work together to transmit heartbeat information to the load balancing unit 106. Although twelve hosts are exemplified, more or fewer hosts can be part of any given host group. Moreover, the entire group of all hosts 108 served by one load balancing infrastructure 106 can be divided into one, two, three, or more host groups.

[0196] In a described implementation, the member nodes of the host group 108 (1,2-12) select a leader to be responsible for sending the heartbeat message 1502 to the load balancing unit 106. Each (non-leader) host 108 in the host group 108 (1, 2···) sends its heartbeat message to the selected leader. In this example, the host 108(4) is the selected leader By.

[0197] Using member nodes, the heartbeat information of each host 108 in the host group 108(1, 2... is transmitted to the group leader host 108(4). The host 108(4) collects these heartbeat information and combines them into Combined heartbeat messages 1602ο Combined heartbeat messages 1602 (1), 1602...1602 (u) are then sent to the respective load balancing units 106 (1), 106(2)... 106 (u) ο These combined heartbeats Message 1602 can optionally be compressed to further reduce bandwidth consumption.

[0198] As another option, the leader host 108(4) may only transmit changes in group members to the joint health status and load cache 1208. In other words, in this mode, the joint health state and load cache 1208 mainly (if not individually) handles the state changes of the members. The responsibility of the leader host 108(4) is to ensure that the first hello (hello) is transmitted when a host 108 is online, and to ensure that the goodbye message 1504 is sent when the host 108 is offline. In addition, the host 108 can periodically specify that the heartbeat signal 1502 will be "transmitted". This instructs the leader host 108(4) to send it to the joint health and load cache 1208, even if it does not represent a member change

CN 1578320 Β

The same is true of chemistry.

[0199] When the combined health state and load cache 1208 of the load balancing unit 106 is not synchronized with the health state and load table 1204, the heartbeat signal 1502 (including the combined heartbeat message 1602) is used by the load balancing unit 106. For example, a crash or other failure of the combined state of health and load cache 1208 and/or load balancing unit 106 may cause loss of synchronization. As described above, each heartbeat message 1502 includes error checking data, which can be used to verify the equivalence between the combined health state and load cache 1208 and the health state and load table 1204. If an unequal price is found for a particular host 108 and/or its application 316, the DNS name of the host 108 is obtained from the heartbeat message 1502.

[0200] In order to obtain the updated health status and load information 1206 in the form of sending a table snapshot message 1510, the DNS name is used by the joint health status and load cache 1208 to send a table snapshot obtaining message 1508 to the host 108 . A different or the same Get Table Snapshot message 1508 is sent to each host 108 that is found to be unequal. Finally, the health state and load information 1206 in the combined health state and load cache 1208 are equivalent to the health state and load information 1206 in the health state and load table 1204, which can be verified by the new heartbeat message 1502. In this way, the failed joint state of health and load cache 1208 can be bootstrapped back into operation without the manual error of using the message protocol 1500 and the equivalence check scheme.

[0201] FIGS. 17A and 17B illustrate an exemplary state of health and load information proxy storage situation for the state of health and load table 1204 and for the combined state of health and load cache 1208, respectively. In the above implementation with reference to FIGS. 12-16, the host 108 includes a health state and load infrastructure 1202. However, other implementations can be implemented by hosts that do not include the health status and load infrastructure 1202.

[0202] For example, the host may run a version of an application program and/or an operating system, in which the health status and load infrastructure are either not implemented or not installed on the host due to policy reasons. As a result, this type of host does not have a health state and load infrastructure 1202 on it. The host 1702 is a host that does not execute a health state and load infrastructure 1202. However, the host 1702 can be used in one or more The state of health and load infrastructure 1202 executed on the agent (eg, agent 1704).

[0203] The agent 1704 has a health status and load infrastructure 1202 that resides and executes on it, the latter includes a health status and load table 1204. The host 1702 can provide health status for applications running on the host 1702 And load information 1206 to the state of health and load table 1204, and the function of the state of health and load infrastructure 1202 is used. Optionally, the agent 1704 can deduce the health status and load on the host 1702 by performing external monitoring operations. The agent 1704 is exemplified as the agents 1704(1) and 1704(2) to generate high reliability through redundant configuration.

[0204] In the implementation described with reference to FIGS. 12-16 and the following with reference to FIG. 18, load balancing is performed by the load balancing unit 106 including the joint state of health and the load cache 1208. However, other implementations may be implemented by load balancing that does not include the combined state of health and load cache 1208.

[0205] For example, it can be done by monolithic load balancing hardware or other load balancing infrastructures that do not and/or cannot store or contain a joint state of health and load cache 1208. The load balancer 1706 reflects such a load balancing device (one or more) that does not have a joint health state and load cache 1208. However, the load balancer 1706 may take advantage of the combined health status and load cache 1208 that exist on one or more agents (eg, agents 1708).

[0206] The agent 1708 includes a combined health state and load cache 1208, the latter paired by the load balancer 1706

CN 1578320 Β

The hosted application of the service stores health status and load information 1206. When accessing this information by using an application programming interface (API) that is inherent to the load balancer 1706 and can be supported by the load balancer 1706, the load balancer 1706 can use the combined health state and load cache 1208's health state and load Information 1206. Optionally, the combined health state and load cache 1208 can call an API to push the health state and load information 1206 containing the indication into the stack and push it to the load balancer 1706. The agent 1708 is exemplified as the agents 1708(1) and 1708(2), which are used to generate high reliability through redundant configuration.

[0207] FIG. 18 illustrates an exemplary target application endpoint allocation process involving the classifier 304 and the health state and load processor 314 of the load balancing unit 106. After the health state and load processor 314 obtains the combined health state and load cache 1208, it uses its health state and load information 1206 to select the application endpoint for the new request/connection.

[0208] As described above with reference to FIG. 13B, the combined state of health and load cache 1208 includes cached state of health and load information 1206 for the plurality of hosts 108. In order to facilitate the creation and update of a joint health state and load cache 1208 from the health state and load information 1206 from multiple hosts 108, the health state and load information 1206 therein is organized so that it can be used by each host 108 To get access. Of course, the health status and load information 1206 therein can also be organized so that it can be accessed through the type of application 316 in order to facilitate application endpoint selection.

[0209] In other words, the health status and load processor 314 can access the health status and load information 1206 on the health status and load information 1206 of the multiple hosts 108 in units of each application 316. Once the health status and load information 1206 for a given application 316 has been accessed by each host 108, the allocation of incoming connection requests can be performed based on the health status and load information 1206. For example, for the possible endpoints of the given application 316, the endpoints of the given application 316 can be selected, while considering the relative load capacity available among the good endpoints of the given application 316, to be allocated to Incoming connection request.

[0210] In one described implementation, the classifier 304 makes a target application endpoint allocation request 1802 to the health state and load processor 314. As illustrated, the target application endpoint request 1802 includes (i) a virtual IP address and port, (ii) a protocol, and (iii) protocol specification information. Therefore, the target application endpoint assignment request 1802 identifies the type of application 316 to which the incoming connection request is directed.

[0211] The health status and load processor 314 receives the target application endpoint allocation request 1802, and selects at least one actual endpoint corresponding to the type of the identified application 316 by using any one or more of a variety of selection mechanisms . To reduce latency, the state of health and load processor 314 selects an allocation scheme to be applied to application endpoints on multiple incoming connection requests. The target application endpoint assignment response 1804 is used to provide this assignment from the health and load processor 314 to the classifier 304. As illustrated, the target application endpoint allocation response includes the allocation of actual IP addresses and ports (eg, endpoints IP1, IP2, and IP3) for the identified type of application 316.

[0212] The distribution of the response 1804 to the target application endpoint distribution can be accomplished by using one or more distribution schemes. For example, a token allocation plan 1806 and a percentage allocation plan 1808 are exemplified. The token allocation plan 1806 is a unit-based allocation plan, and the percentage allocation plan 1808 is a time-based allocation plan.

[0213] The token allocation scheme 1806 allocates tokens to each good endpoint IP1, IP2, and IP3 according to their respective load and capacity ratios. For the illustrated example, for all available capacity, IP1 has 40% available capacity, IP2 has 35% available capacity, and IP3 has 25% available capacity. In this way, the total number of tokens is based on these percentages

Divide. The total number of tokens may be provided as part of the target application endpoint allocation request 1802, or determined by the state of health and load processor 314.

[0214] Any total number of tokens can be used, such as 10, 45, 100, 250, 637, 1000, etc. This value is set based on the number of connection requests per second and the speed/frequency of application health and/or load changes. When using application endpoint allocation to respond to each connection request, the classifier 304 "spent"/consumes a token until all tokens are exhausted; then, the classifier 304 uses the target application endpoint to allocate the request 1802 to request another token allocation.

[0215] The percentage allocation scheme 1808 uses a similar manner to determine the relative capacity available. However, instead of using a token, a duration timer 1810 is used to provide the classifier 304 with the relative capacity available for each of these determined application endpoints. The classifier 304 assigns target application endpoints to incoming connection requests based on these relative percentages of available capacity until the duration timer 1810 expires.

[0216] For the percentage allocation scheme 1808, the classifier 304 maintains a running record of the application endpoint allocation to comply with the allocated percentage and track the duration of the timer 1810. When the timer expires, the classifier 304 uses the target application endpoint allocation request 1802 to request another percentage allocation.

[0217] It should be noted that the token allocation scheme 1806 can also use a time limit. If the allocated tokens are too old, they should be discarded and new ones obtained. Otherwise, the classifier 304 may consume obsolete tokens previously allocated based on the current state of health and load information that is too obsolete. The method of using application endpoint allocation by the classifier 304 will be further described in the section titled "Exemplary Classification, Delivery, and Request Routing" below.

[0218] Exemplary Session Tracking

[0219] This section describes how host state information, such as session information, is collected and utilized during network load balancing. This section mainly refers to Figures 19-24, and clarifies the session affinity (sessionaffinity) preservation function, such as that provided by the session tracker 308 (in Figure 3). As described above with reference to FIGS. 1-3, each host 108 hosts one or more applications 316 capable of providing one or more services to the client 102. For some of the described implementations of network load balancing, the session tracker 308 utilizes session information related to the context for the connection established between the application 316 and the client 102.

[0220] FIG. 19 illustrates an exemplary network load balancing method involving session information 1902. In connection [1], it is shown that the client 102(1) is establishing a new connection with the host 108(2) through the load balancing infrastructure 106. The load balancing infrastructure 106 may include one or more load balancing units 106. When the connection request reaches the load balancing infrastructure 106, the request is generally routed to the host 108. The routing process is based on the health and/and load of the host 108 and/or its application 316 (not shown in FIG. 19). Information, using the network load balancing function to complete.

[0221] When the connection [1] is made, a session is established between the client 102(1) and the serving application 316, which in this example is on the host 108(2) s application. This session provides a context for the communication exchange between the client 102(1) and the host 108(2). The information for the context of this conversation is stored in the host 108(2). When the connection [1] is completed, the context of the conversation can no longer be used. On the other hand, if the client 102(1) attempts to initiate another connection with the host 108 for the service provided by the application 316, then the conversation context may be useful. If the additional connection is not routed to the same host 108(2) where the session context is stored, then the client 102(1) has to create a new session context, which may be time-consuming, data/processing Intensive and/or disappointing to users of client 102(1). Using network load balancing based on health status and/or load information, there is no more randomness than the second connection being routed to 108(2)

CN 1578320 Β

Greater possibility.

[0222] However, if the load balancing infrastructure 106 can access the mapping between the session information and the host 108, the load balancing infrastructure 106 can route connection requests related to the previously created session to the appropriate host 108. Some session information can be inferred from the content of the packets flowing through the load balancing infrastructure 106. However, this method is inaccurate and accidental for various reasons. First, the creation and termination of sessions are only inferred. Second, some sessions are not "formally" terminated with a suitable indication contained in the packet. For example, some sessions simply time out. Third, the packets transmitted from the host 108(2) to the client 102(1) may take a path that does not include the load balancing infrastructure 106, which eliminates the need for the load balancing infrastructure 106 to monitor these packets to obtain session information. Possible.

[0223] As shown in FIG. 19, the host 108 provides session information (SI) 1902 to the load balancing infrastructure 106. Using the session information 1902 from the host 108, the session associativity saver 1904 can save the established session and the session information. The associativity between the hosts 108 established on it. The session information 1902 includes the link or mapping between the session created between the client 102 and a certain host 108 to the host 108. The mapping can be used as the host session information mapping 1906 Part of the session associativity saver 1904 to access. More specific examples of session information will be given below, especially with reference to FIGS. 20, 22, 23A, and 23B.

[0224] In some of the described implementations of session tracking, the logical characteristics of the client 102 are relevant. As described above with reference to FIG. 1, the client 102 may be a specific device and/or a specific user of a device. Therefore, for the user client 102 that is accessing the host 108 from a different device, the session associativity can still be preserved. The continuation of the session using the session information 1902 can therefore still be completed in a proxy situation (for example, those proxies of some Internet Service Providers (ISP)).

[0225] Continuing to connect to the example of [1], the session created on the host 108(2) can be provided to the load balancing infrastructure 106 as the session information 1902. Specifically, the link/mapping between (i) the session context of the client 102(1) and the host 108(2) and (ii) the identifier for the host 108(2) is in the host session information mapping 1906 Created on. When the connection request for connection (2) subsequently arrives for the same session context, the session associativity saver 1904 locates the session context in the host session information map 1906, and determines that the host 108(2) is connected to the link/ The mapped session context is associated.

[0226] According to the mapping of the host 108(2) to the requested session context determined by the session associativity holder 1904 from the host session information mapping 1906, the connection [2] is routed to the host 108(2). In this case, for the load balancing infrastructure 106, preserving session cohesion has a higher priority than preserving the decision of network load balancing based on the health status of the application and the load. However, when, for example, the load is extremely heavy or when the application and/or host associated with the session are in a faulty state, the state of health and/or load may be a more important network load balancing factor than session tracking.

[0227] Many types of connections can be session-related. Examples include: TCP connections, Transport Layer (TLS)/SSL sessions, PPTP sessions, IPSec/L2TP sessions, ISA sessions, HTTP cookie-based sessions, terminal server sessions, administrator-defined sessions, etc. To clarify, a TCP connection is considered a session of TCP packets. Moreover, it is possible to enumerate and give the session model defined by the administrator. In addition, it can also support sessions based on the client's IP address that are portrayed by timeout settings. This is relatively unintelligent session support, but it is what some users expect.

[0228] The connection request from the client 102 varies with the type of session desired. For example, for a "TCP connection" type session, the connection request includes a TCP packet. For a "SSL session" type of session, the connection please

Request to include TCP connection. These other connection requests correspond to other session types. These examples also show how the session layer exists. In lower-level sessions, the session context used for TCP connections includes TCP quads, session number, number of bytes sent/received, and so on. In a higher-level session, the session context of the SSL session includes a 32-byte session ID, a public key provided to the client 102 of the host 108, and so on.

[0229] FIG. 20 illustrates an exemplary network load balancing method involving the use of notification 2006 and message 2008 to deliver session information. A plurality of load balancing units 106(1), 106...106(ιι) and a plurality of hosts 108(1), 108...108(η) are shown. Each host 108(1), 108(2)...108(n) respectively includes one or more respective application programs 316(1).316(2)...316(n) residing and running on them. The notification 2006 is used to provide session information from the application 316, and the message 2008 is used to provide the session information from the host 108 to the load balancing unit 106.

[0230] As illustrated, each host 108(1), 108(2)...108(n) respectively includes its own session tracking infrastructure (STI) 2002(1)>2002(2)-2002(n). Each session tracking infrastructure 2002 (1)> 2002 (2)-2002 (η) includes their own session table 2014 (1)> 2014 (2)...2014 (η) (although only the session table is shown in Figure 19) 2014 (1)).

[0231] Each load balancing unit 106(1), 106····106(ιι) respectively includes its own service routing function (TRF) 2012 (1), 2012 (2)...2012 (u). The service routing function 2012 may include, for example, classification and/or request routing functions provided by the classifier 304 and the request router 306, respectively. Distributed on the load balancing unit 106 (1), 106... 106 (u) is a distributed session tracking manager 2010ο

[0232] In one described implementation, the service routing function 2012 and the distributed session tracking manager 2010 form part of the load balancing infrastructure 106. The session tracking infrastructure 2002 may also be a (e.g., a remote) portion of the load balancing infrastructure 106.

[0233] The API 2004 is used to provide session information from the application 316 to the session tracking infrastructure 2002. Using the API 2004, the application 316 can notify the session tracking infrastructure 2002 of session information, including various changes in the information. More specifically, each application 316 can provide notification 2006, and the session tracking infrastructure 2002 can accept notification 2006.

[0234] When a session is newly created or opened, a notification of session establishment (or session establishment notification 2006 (E)) is given from the application 316. The session establishment notification 2006(E) includes the session identifier and optionally the identifier of the application 316. When the session is terminated or closed, a notification that the session is terminated (or session termination notification 2006 (T)) is given from the application 316. The session termination notification 2006 (T) also includes the identifier of the session and optionally the identifier of the application 316.

[0235] When the session tracking infrastructure 2002 accepts the session establishment notification 2006 (E), it inserts an entry in the session table 2014 for the new session. An exemplary session table 2014 will be further described below with reference to FIG. 23A. When the session tracking infrastructure 2002 accepts the session termination notification 2006 (T), it deletes the entry from the session table 2014 for the old session.

[0236] The session table 2014(1) is an authoritative source of session information about the application 316(1) on the host 108(1). However, upon receiving each incoming connection request with a session reference, the service routing function 2012 is required to contact the host 108 to access the session table 2014, which usually has too much delay. The session information 1902 is therefore cached in the load balancing unit 106.

[0237] In the load balancing unit 106, the distributed session tracking manager 2010 caches session information 1902 as part of its session tracking management responsibilities. Generally, the distributed session tracking manager 2010 is a distributed application program and/or virtual service partially residing on each load balancing unit 106. For each logical session, the distributed session tracking manager

2010 uses a reliable and extensible way to store at least one cached copy of session information for it. When an incoming connection request with a session reference is received by the load balancing infrastructure 106, it can be used to perform fast routing services .

[0238] The communication between the host 108 and the load balancing unit 106 is through a reliable protocol that ensures that the message 2008 sent from the host 108 reaches the load balancing unit 106 to which it is going. Each host 108 is combined with at least one specific load balancing unit 106, which is the destination load balancing unit 106 of the message 2008. This combination is created by assigning an IP address of a specific load balancing unit 106 to each host 108 to send the session tracking message 2008 between the session tracking infrastructure 2002 and the distributed session tracking manager 2010. To help improve the reliability of the load balancing infrastructure 106, if one load balancing unit 106 fails, the other load balancing unit 106 assumes the IP address of the failed load balancing unit 106. Heartbeat or another active monitoring scheme can be used for failure detection for IP address assumptions.

[0239] In this way, the message 2008 transfers the session information 1902 from the session tracking infrastructure 2002 to the distributed session tracking manager 2010. For example, when the session tracking infrastructure 2002 accepts the session establishment notification 2006 (E), it also sends a session initiation (up) message 2008 (U) to the distributed session tracking manager 2010. The session initiation message 2008 (U) includes the session identifier , Host identifier, and optionally other information. The content of the session initiation message 2008 (U) will be further described below with reference to FIG. 23B relative to an implementation manner of the distributed session tracking manager 2010 for the information stored in each session. When the session tracking infrastructure 2002 receives the session termination notification 2006 (Τ), it also sends a session down (down) message 2008 (D) to the distributed session tracking manager 2010. The message 2008 may be sent before, during, or after the session tracking infrastructure 2002 appropriately modifies the session table 2014 according to the notification 2006.

[0240] FIG. 21 illustrates a flowchart 2100 of an exemplary network load balancing method involving notifications and messages to deliver session information. The flowchart 2100 includes fifteen blocks 2102-2130. Although the operation of the flowchart 2100 may be in other environments And it is executed in a variety of software methods, but in particular, Figures 1-3 and 19-20 are used to illustrate certain aspects and examples of the method.

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

[0242] At block 2101, a session is opened. For example, the application 316 can open a session with the client 102. At block 2104, a session establishment notification is provided. For example, as a result of and/or in conjunction with opening the session, the application 316 may use the API 2004 to provide the session establishment notification 2006 (E) to the session tracking infrastructure 2002.

[0243] At block 2106, the session establishment notification is accepted. For example, the session tracking infrastructure 2001 may receive the session establishment notification 2006 (E) from the application 316 according to the API 2004. At block 2108, an entry is inserted in the session table. For example, the session tracking infrastructure 2002 may insert an entry in the session table 2014 for the opened session. An example of such insertion will be further described below in particular with reference to FIG. 23A. At block 2110, a session start message is sent. For example, the session tracking infrastructure 2002 can use a reliable communication protocol to send the session start message 2008 (U) to the distributed session tracking manager 2010.

[0244] At block 2112, a session start message is received. For example, the distributed session tracking manager 2010 may accept the session start message 2008 (U) from the session tracking infrastructure 2002 according to the reliable communication protocol. At block 2114, a session information entry is created. For example, the Distributed Session Tracking Manager 2010 can be used in one or more load balancing units

CN 1578320 Β

The session information 1902 cached in 106 creates a session information entry. Examples of such creation and subsequent adding operations will be further described below in particular with reference to FIGS. 22 and 23B.

[0245] At block 2116, the session information is used to route and transmit network services. For example, in conjunction with the distributed session tracking manager 2010, the service routing function 2012 may use the cached session information 1902, including the created session information entry, to route incoming connection requests with session references. An example of this kind of service routing will be further described in particular with reference to FIG. 24 below. Other examples will be described in the section titled "Exemplary Classification, Delivery, and Request Routing" below.

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

[0247] At block 2122, the session termination notification is accepted. For example, the session tracking infrastructure 2002 can accept a session termination notification 2006 (T) from the application 316 according to the API 2004. At block 2124, the entry in the session table is deleted. For example, the session tracking infrastructure 2002 may delete entries in the session table 2014 for closed sessions. At block 2126, a session close message is sent. For example, the session tracking infrastructure 2002 can use a reliable communication protocol to send the session close message 2008(D) to the distributed session tracking manager 2010.

[0248] At block 2128, the session close message is received. For example, the distributed session tracking manager 2010 may receive the session close message 2008(D) from the session tracking infrastructure 2002 according to the reliable communication protocol. At block 2130, the session information entry is destroyed. For example, the distributed session tracking manager 2010 may destroy the session information entry of the session information 1902 cached in any load balancing unit 106 that has the session information entry. Examples of such destruction and subsequent deletion operations will be further described below in particular with reference to FIGS. 22 and 23B.

[0249] FIG. 22 illustrates an exemplary method of managing session information in a plurality of load balancing units 106. The load balancing units 106(1), 106(2)...106(u) respectively include respective parts 2202(1), 2202(2)...2202(u) of the distributed atomic manager (DAM) 2202. DAM 2202 is an exemplary implementation of a distributed session tracking manager 2010. Each DAM part 2202(1), 2202(2)...2202(ιι) includes respective parts 2206(1), 2206(2)...2206(ιι) of the DAM table (DAMT) 2206, respectively.

[0250] DAM 2202 is a distributed application or virtual service, which manages the session information 1902 in a reliable and scalable manner, so that the service routing function 2012 can use it to save session cohesion. For example, the service routing function 2012 may use an API (not specifically shown) to search for or finish searching for DAMT 2206 to access DAM 2202. The operation of function call 2204, DAM 2202, and other aspects of FIG. 22 will be further described after the description of FIGS. 23A and 23B.

[0251] FIG. 23A is an exemplary session table 2014 illustrated in FIG. 20. The session table 2014 includes "v" entries 2302(1), 2302(2)···2302(v). Each entry 2302 is inserted by the session tracking infrastructure 2002 according to the session establishment notification 2006(E) received from the application 316. Each entry 2302 is deleted by the session tracking infrastructure 2002 based on the session termination notification 2006 (T) received from the application 316.

[0252] As described above, each session establishment notification 2006(E) includes a session identifier and optionally an identifier of the application 316. Each entry 2302 (1), 2302 (2)...2302 (v) in the session table 2014 includes respective fields (i) session identifier 2302 (II), 2302(21)... 2302 (νΐ) and (ii) Session type and/or application 2302 (1T)>2302(2T)...2302 (vT).

[0253] The session type and/or application 2302 (T) can be "TCP", "IPSEC", "terminal server",

CN 1578320 Β

"HTTP-cookie", an application type as described above, etc. The session identifier 2302(1) can be "<source IP address, source TCP port, destination IP address, destination TCP port>", "client IP = 172. 30. 189. 122", "user='joe_user', Cookie ='{b7595cc9-e68b-4eb0-9bfl-bb717b31d447}' Another example is the identification of a specific application for a session, etc. For TCP connection/session type, the session identifier 2302(1) can optionally be one The specification version of the TCP quartet (for IPv4 or IPv6). For the fields of session identifier 2302(1) and application/session type 2302 (T), other values can be selectively used.

[0254] FIG. 23B is an exemplary distributed atom manager (DAM) table (DAMT) 2206 illustrated in FIG. 22. The DAM table 2206 includes "w" entries 2304 (1), 2304 (2)... 2304 (w). Each session information entry 2304 is created by DAM 2202 based on the session start message 2008 (U) received from the session tracking infrastructure 2002. Each session information entry 2304 is destroyed according to the session close message 2008 (D) received from the session tracking infrastructure 2002. As described further below, the session information entry 2304 of the DAM table 2206 can actually be operated by the DAM 2202 using the function call 2204.

[0255] As described above, the session initiation message 2008 (U) includes a session identifier, a host identifier, and optionally other information. Each session information entry 2304(1), 2304(2)...2304 (w) in the DAM table 2206 includes its own field key 2304 (1K)> 2304 (2K) 2304 (wK), (ii) Data 2304 (ID), 2304 (2D)...2304 (wD), and (iii) metadata 2304 (1M), 2304 (2M)... 2304 (wM). For example, the value of the key 2304(K) may be a string of characters and numbers, and the value of the data 2304(D) may be binary digits. The value of the key 2304(K) can also be binary bits. [0256] The key 2304 (K) may correspond to the session identifier 2302 (1). The data 2304 (D) may correspond to the host identifier, for example, the network address of the host 108 in the context of the session. The metadata 2304(M) may correspond to other optional information. Examples of such metadata 2304 (M) include data used internally by DAM 2202 to resolve atomic conflicts and track atomic activity (for example, through a timeout mechanism). (This feature of the atomic entry 2304 will be described more fully in the following paragraphs). More specifically, among other things, the metadata 2304(M) also includes the identification of the entity that added the session information entry 2304 to the DAM table 2206 (for example, an instance of the service routing function 2012).

[0257] In a described implementation, each session information entry 2304 is atomized. In this case, DAM 2202 can add, delete, copy, etc. to these entries 2304 as a whole, but DAM 2202 - Generally do not modify any part of the entire entry 2304. In this way, the atomized entry 2304 is added, deleted, copied, operated, etc., on the DAM table 2206 by the DAM 2202, so as to realize the validity and scalability of the implementation of the preservation of session associativity.

[0258] The function call 2204 (FIG. 22) can be used by the DAM 2202 to operate the atomization entry 2304 of the DAM table 2206. The function call 2204 may be transmitted from one load balancing unit 106 to one or more other load balancing units 106 in a point-to-point or multicast manner. These function calls include add atom 2204 (A), delete atom 2204 (D), query atom 2204 (Q), and return atom 2204 (R).

[0259] Add atom 2204 (A) adopts the form of "Add atom (key, data)" ("AddAtom (key, data)") to add an atomized entry 2304 to one or more DAM tables 2206. Therefore, the add atom 2204 (A) function call can be expressed as "Add atom (<session identifier>, host IP address)" (AddAtom«session identifier>, host IP address)). Delete atom 2204 (D) adopts The form of "Delete Atom (key)" ("DeleteAtom (key)") is used to delete an atom entry 2304 in one or more DAM tables 2206. The delete atom 2204(D) function call may be for those DAM tables 2206 that are known to have copies of sessions identified by the key 2304(K) or that can be multicast to all DAM tables 2206 to ensure that any copies are deleted.

CN 1578320 Β

[0260] The query atom 2204 (Q) takes the form of a "query atom (key)" ("QueryAtom(key)"), and when the session identifier referenced by an incoming connection request is not located in a certain DAM part 2202 The local DAM table 2206 is used by the DAM part 2202. The query atom 2204 (Q) function call is sent to one or more (including all possible) other DAM parts 2202. In response, each other DAM part 2202 checks its local DAM table 2206 against the key/session identifier. If the key is located in another DAM part 2202, then the DAM part 2202 replies with a return atom 2204(R).

[0261] The return atom 2204 (R) adopts the form of "Return Atom (key, data) (Return Atom (key, data)), which is used to reply to the query atom 2204 (Q) function call. When a DAM part 2202 has the requested atomization entry 2304 identified by the key 2034 (K) specified by the query atom 2204 (Q) function call in its local DAM table 2206, use the return atom 2204(R) function transfer. The return atom 2204(R) function call can be pointed back to the part of the DAM 2202 that issued the query atom 2204(Q) function call.

[0262] The add atom 2204(A) function call is used to respond to the session open message 2008 (U) and/or to copy an atom entry to one or more other DAM tables 2206. This duplication is for redundancy and/or scalability.

[0263] The delete atom 2204 (D) function call is used to respond to the session close message 2008 (U), and may also be sent to one or more other DAM tables 2206. After deleting an atomic entry 2304, the atomic entry 2304 can enter a "zombie" state, so that it remains in the DAM 2202, and optionally so that it actually remains in the basic entry 2304 A rigid indication in the metadata 2304 (M) is stored in the DAM table 2206.

[0264] In this way, once an atomic entry 2304 is deleted, it can still stay in the DAM 2202 and DAM table 2206 in a rigid state, so that the packet of the session (now in a dead state and closed) is pointed to The host 108 in the context of the conversation can perform appropriate and protocol-specific processing. For example, a TCP packet received after the TCP connection has been torn down is directed to the host 108 that terminated the connection. The host 108 can make an appropriate response-possibly by sending a RST or resending a FIN-ACK. The time spent by the atomic entry 2304 in this rigid state matches (as reasonably close as possible to) the dead time of the specific protocol of the reliable communication protocol used.

[0265] When the first load balancing unit 106 receives an incoming connection request referring to a session in the local DAM table 2206 of the DAM 2202 of the first load balancing unit 106, it uses the query atom 2204 (Q) function call to Obtain the atom entry 2304. It should be noted that other DAM parts 2202 can be queried simultaneously in a broadcast query atom 2204 (Q) function call, or sequentially query until a positive return atom 2204 (R) function call is received.

[0266] The return atom 2204 (R) function call is used by the DAM part 2202 of the second load balancing unit 106 to provide an atomic entry 2304 to the DAM part of the first load balancing unit 106, wherein the atomic entry 2304 has the first The DAM part 2202 of the load balancing unit 106 previously issued the query atom 2204 (Q) The key 2304 (Κ) specified by the key/session identifier in the function call. It should be noted that other components, such as the service routing function 2012 It is also possible to call the function 2204 according to an API or a similar way, especially the query atom 2204 (Q) function call. [0267] The DAM section 2202 and the DAM table 2206 can be organized and managed in countless ways. Exemplary ways include duplication/redundancy, local caching on an acquisition basis, using hashing for location selection, and so on. You can use zero, one, two, or more levels of replication until all are replicated. Using zero-level replication, each atomic entry 2304 is stored in the DAM 2202 that does not need to be replicated to other DAM parts 2202 to receive the session open message 2008 (U).

[0268] Using the first level of replication, each atom entry 2304 is stored in the DAM 2202 receiving the session open message 2008 (U), and it is also added (copied) to one other using the add atom 2204(A) function call DAM

CN 1578320 Β

Part 2202. This pair of load balancing unit 106 handles a level of failure. Similarly, using the second level of replication, each atomic entry 2304 is stored in the DAM 2202 receiving the session open message 2208 (U), and it is also added to the two other DAM parts 2202. Generally, it is predetermined or randomly selected for a given DAM part 2202 to copy the atomic entry 2304 to one, two, etc. other DAM parts. You can also use the third and fourth levels of replication.

[0269] In addition, copy all can be used to add each atomic entry stored in the DAM 2202 of the received session open message 2008 (U) to every other DAM part 2202 as well. Several factors are affected by the selected replication level: as the replication level increases, reliability increases and latency decreases. On the other hand, both the network traffic and the memory usage rate increase as the replication level increases.

[0270] When full copying is not used, local caching may be performed on the basis of acquisition. For example, when the DAM part 2202 does not locate the reference session identifier in the 2206 part of its DAM table, the DAM part 2202 issues a query atom 2204 (Q) function call to obtain and The atom entry 2304 associated with the referenced session identifier. After the obtained atomic entry 2304 is used, it is not discarded, but the DAM section 2202 caches the obtained atomic entry 2304 in its DAM table 2206 section. This choice gives a compromise between the factors listed above.

[0271] As another option when not using all copy, a hashing method of location selection can be used. The first atomic entry 2304 of the session is stored in the DAM part 2202 of the received session open message 2008 (U). Using the hash function, the copied one or more copies are sent to the specific DAM part 2202 through the add atom 2204 (A) function call. In the full range of possible hash values, each DAM part 2202 is assigned a subset from it. A hash function is used to hash each session identifier to obtain a hash value. The hash value is mapped to the assigned DAM part 2202. The DAM part 2202 of the atom entry 2304 is first added and then the atom entry 2304 is copied to the assigned DAM part 2202.

[0272] By using a location-selected hashing method, at least one DAM part 2202 with a required atomic entry 2304 cached locally in its DAM table 2206 is known from the session identifier. The query atom 2204 (Q) function call can therefore be directed to the known DAM part 2202. This generally reduces network traffic and/or latency.

[0273] This kind of hashing method using location selection can be used for one, two, three, or higher-level replication, and each range of the hash value is mapped to one, two, three, etc. different DAMs. Part 2202 to use. In addition, the location-selected hashing method can be used together with the local cache on an acquisition basis.

[0274] FIG. 24 illustrates a flowchart 2400 of an exemplary method for managing session information in a plurality of load balancing units. The flowchart 2400 includes eight blocks 2402-2416. Although the operations of the flowchart 2400 can be executed in other environments and using multiple software solutions, it will be particularly illustrated with FIGS. 1-3, 19, 20, 22, and 23B. Some aspects and examples of the method.

[0275] At block 2402, the incoming connection request with a session reference is analyzed. For example, the service routing function 2012 may receive an incoming connection request referring to a certain type of previously opened/created session. At block 2404, the local DAM table is searched using the session reference. For example, for a given load balancing unit 106 and service routing function 2012, its DAM part 2202 can search its corresponding DAM table 2206 to find the session reference.

[0276] At block 2406, it is determined whether the session reference matches a key of the local DAM table. For example, the DAM part 2202 can search the key field 2304 (K) of multiple entries 2304 of the DAM table 2206 to determine whether the session reference is

CN 1578320 Β

No match any value of the key field 2304 (K). If so, the flowchart 2400 continues to block 2412.

[0277] On the other hand, if the session reference does not match any keys, the flowchart 2400 proceeds to block 2408. At block 2408, a query atomic function call is made. For example, the DAM part 2202 may make a function call including the query atom 2204(Q) with the session reference/identifier as the key. The query atom 2204 (Q) function call may be sent to at least one other DAM part 2202. For the query atom 2204 (Q), the number, selection, order, etc. of the possible destination DAM parts 2202 depend on the options adopted by the DAM 2202 (for example, the level of replication, the hashing method selected by the location of use, the basis of the acquisition Perform local fast caching, peer-to-peer multicast, etc.).

[0278] At block 2410, the returned atom is received. For example, it is possible to receive information from a function call of the return atom 2204 (R) issued by another DAM part 2202. The other DAM part 2202 successfully locates the atom entry 2304 in its corresponding DAM table 2206, where the located atom entry 2304 has a key matching the session reference. The information from the return atom 2204(R) function call includes the values from the key field 2304 (K) and data field 2304 (D) of the located atom entry 2304. These values correspond to the session identifier of the session and the network address of the host 108 associated with the session.

[0279] At block 2412, an atomic entry is extracted. If a match is found locally (in blocks 2404 and 2406), the atomic entry is extracted from the local DAM table, or if a match is found elsewhere, the atomic entry is extracted from the returned atom. For example, the atom entry 2304 can be extracted from the DAM table 2206 of the DAM section 2202, or from the information received from the return atom 2204(R) function call. If the extracted atomic entry 2304 is received as a result of the return atom 2204(R) function call, the extracted atomic entry 2304 can be cached to the local DAM table 2206.

[0280] In block 2414, determine from the atomic entry a host that has session associativity with the referenced session. For example, the value of the data field 2304(D) of the extracted atomic entry 2304 can be determined, thereby determining the network address of the combined host 108. At block 2416, the incoming connection request is routed to the determined host. For example, the service routing function 2012 and/or the transfer function may route the incoming connection request with the session reference to the determined and combined host 108. Exemplary classification, request routing and delivery functions will be described in the following sections.

[0281] Exemplary Classification, Delivery, and Request Routing

[0282] This section describes how service routing is implemented for network load balancing, including the high reliability of this service routing function. Service routing functions may include classification and/or request routing functions, especially in combination with transport functions. This section mainly refers to Figures 25-31. It clarifies the function of the request router 306 (in Figure 3), the internal relationship between the tracking session and the use of health status and load information when routing services, and is used to communicate with session information and/ Or the operational implementation of the business routing interactive operation of the health status and load information, the high-reliability troubleshooting process for the network load balancing infrastructure (including processing the failure of the classification component, the failure of the transmission component, and/or the request routing component Failure), additional network load balancing infrastructure configuration, and so on.

[0283] FIG. 25 illustrates an exemplary network load balancing infrastructure with a request routing function implemented by the request router 306 (H/S). As described above with reference to the service routing function 2012, service routing may involve classification (eg, with delivery) and/or request routing. In particular, referring to Figure 4 above, the packet-level classification is described in conjunction with transmission. Request routing will be described here with particular reference to FIG. 25.

[0284] Request-level routing occurs at a higher level than packet-level routing. Generally, the request router 306 acts as a proxy for the application program 316 running on the host 108. The request router 306 terminates the TCP connection, parses (perhaps partially) each request from the client 102, and resubmits each request to the host 108. Request router 306 can

CN 1578320 Β

Perform preprocessing on the connection, such as SSL decryption. The requesting router 306 may choose to absorb certain requests (for example, the requesting router may maintain a cache of responses), and it may modify the request "arbitrarily" before transmitting the request to the host 108.

[0285] The requesting routers 306 are generally application-specific, and they are extensible in terms of doing what they can do. Just as an example, a single category of request router 306-HTTP/SSL request router 306 (Η/S) is proposed in the following description. As illustrated, the client 102 with the network address CI is passing through the network 104 and has The hosts 108(1) and 108(2) with network addresses H1 and H2 communicate. The communication described is accomplished via a load balancing infrastructure including HTTP/SSL request router 306 (H/S).

[0286] The HTTP/SSL request router 306 (H/S) terminates HTTP and SSL services, decrypts the SSL services, checks each HTTP request from the client 102, and applies specific application rules to classify each request in order to consider the application The health status and load information of the program endpoints determine the "best" endpoint for the request at the same time, and submit the request to the endpoint. The request submission to the endpoint uses a single TCP connection instead of the one initiated by the client 102 (the latter connection is terminated at the HTTP/SSL request router 306 (H/S)). These actions can be considered logically the same as the actions performed by the classifier 304, but the difference is that these actions in the HTTP/SSL request router 306 (Η/S) are each request that occurs in the TCP connection. The logical request level. The HTTP/SSL request router 306 (H/S), as well as the general request router 306, can use the same (i) application health and load, and (ii) session tracking infrastructure used by the classifier 304.

[0287] The HTTP/SSL request router 306 (H/S) acts as an arbitration between the client 102 and the two hosts 108(1) and 108(2). Two requests from the client 102 are processed through a single TCP connection. In one described implementation, the generated request routing involves several operations. First, the client 102 creates one or more http connections to the HTTP/SSL request router 306 (Η/S) [1], and sends a request #1 2502(1).

[0288] Second, the HTTP/SSL request router 306 (H/S) terminates the SSL session (if the service is SSL encrypted), parses request #1 2502(1), and checks the content of request #1 2502(1) . Considering the health status and load of the application and the session information, in this example, HTTP/SSL request router 306 (Η/S) judges that the "best" host is host 108 ( 1) ο

[0289] Third, the HTTP/SSL request router 306 (H/S) creates a secondary TCP connection to the host 108(1) [2]. Optionally it can use the existing connection to host 108(1) [2]. The HTTP/SSL request router 306 (H/S) then sends, for example, the unencrypted version of request #1 2502(1) to the host 108(1). Fourth, host 108(1) replies with response #1 2504(1). Fifth, the HTTP/SSL request router 306 (H/S) encrypts the response #1 2504(1) and sends it back to the client 102 on the TCP connection [1].

[0290] Sixth, the client 102 sends another request, request #2 2502 (2). Request #2 2502(2) is processed in a similar manner to that of Request #1 2502(1), except that the HTTP/SSL request router 306 (H/S) selects the host 108(2). The different choices may be made because the host 108(1) is malfunctioning or under a heavier load, because the request #2 2502(2) points to a different URL than the request #1 2502(1), and so on. In any case, HTTP/SSL requests router 306 (H/S) to create another secondary TCP connection, but this secondary connection [3] connects to host 108(2). Unencrypted request #2 2502(2) is routed to host 108(2), and response #2 2502(2) is received from host 108(2) as a result. The encrypted version of response #2 2502(2) is then sent from the HTTP/SSL request router 306 (Η/S) to the client 102.

[0291] Seventh, the client 102 closes the TCP connection with the HTTP/SSL request router 306 (H/S) [1]. HTTP/SSL

Request router 306 (H/S) (at some time in the future) on behalf of client 102 to close connections to hosts 108(1) and 108(2) and [3] o TCP connection can also be used in HTTP/ The SSL request router 306 (Η/S) decides to open/use the TCP connection [3] for the request #2 2502(2) and then it is closed.

[0292] Since the HTTP/SSL request router 306 (H/S) terminates the http connection, the HTTP/SSL request router 306 (H/S) may not only perform routing requests. For example, the HTTP/SSL request router 306 (H/S) may maintain its own response cache (e.g., use an out-of-band mechanism to invalidate the cache). As described in the above example, the HTTP/SSL request router 306 (H/S) can also potentially route different kinds of requests to different groups of hosts 108 based on, for example, the requested URL. In turn, the HTTP/SSL request router 306 (H/S) can potentially aggregate requests from many short-term client connections, and send them to the host 108 on a long-maintained TCP connection. This kind of connection aggregation can reduce the TCP connection processing overhead on the host 108.

[0293] Other types of request routers may correspond to other exemplary protocols other than HTTP. For example, the request router may be a SOAP request router. The SOAP request router works similarly to the HTTP/SSL request router 306 (H/S). However, the SOAP request router is dedicated to routing SOAP services. The SOAP request router understands the SOAP header and makes routing decisions based on the health and load of the application and the SOAP header.

[0294] Both packet-level classification and delivery (or packet-level routing) and request-level routing can provide some form of layer-7 load balancing. Layer-7 load balancing will be further described in the section titled "Exemplary Connection Transfer Using Optional Tunneling and/or Application Level Load Balancing" below. Packet-level routing provides read-only access to the initial part of the client's TCP connection data, while request-level routing provides read and modify access to the entire data stream.

[0295] Packet-level routing generally has several advantages over request-level routing. These advantages include transparency (client packets are sent to the host as they are, that is, the source and destination IP addresses and port numbers are retained), low processing overhead (generally, the transfer service involves routing lookups), low latency (transmitting individual packets, and Once the purpose of the TCP connection is determined, packets do not need to be queued), and high reliability (usually, a failure in the transmission device does not terminate the TCP connection). On the other hand, request-level routing generally has the following advantages over packet-level routing: the ability to check the flow direction and the entire data flow from the client; and the ability to transform the data flow, and even separate data between multiple hosts The ability to stream and aggregate data streams from multiple clients.

[0296] FIG. 26 illustrates a flowchart 2600 of an exemplary method for routing incoming packets according to (1) session information and (ii) health status and load information. The flowchart 2600 includes eight blocks 2602-2616. Although the actions of the flowchart 2600 can be executed in other environments and with multiple software, in particular, Figures 1-3.12.18-20.22 and 23B will be used to illustrate the method. Certain aspects and examples.

[0297] At block 2602, an incoming packet is received. For example, the packet from the client 102 may be received in the transmission device 302 of the load balancing unit 106. In block 2604, it is determined whether the received packet is for a previously existing session. For example, the transmitting device 302 can query the local DAM table 2206 0 to determine that the received packet is already a part of a TCP/IP session.

[0298] In addition, the transmission device 302 can query the local DAM table 2206() and determine that the received packet is not yet a component of a TCP/IP session. In this case, the transmission device 302 provides the received packet to the classifier 304, which uses a higher level of session associativity to check whether the received packet has a session reference. Examples of these actions are described above with particular reference to FIG. 24 and will be further described below with particular reference to FIGS. 27 and 28.

[0299] If the received packet is for a previously existing session (as determined in block 2604), then the flow

The process continues to block 2606. At block 2606, the host to be combined with the previously existing session is determined. For example, the transmission device 302 or the classifier 304 can determine the combined host 108 from the local DAM 2206 () and/or the entire distributed DAM 2206.

[0300] In block 2608, it is determined whether the combined host is good. For example, the classifier 304 may query the combined health status and load cache 1208 to determine whether the combined host 108 is good, especially for those packets that form part of a session with a higher logical level than a TCP/IP session. The actions of this block can be completed together with the health status and load processor 314.

[0301] If the combined host is good (as determined in block 2608), then the flow continues to block 2610. At block 2610, the received packet is routed to the combined host. For example, the transfer device 302 (for TCP/IP sessions) and the classifier 304 (for higher-level sessions) can route the packet to the combined host 108. In an alternative implementation, the classifier 304 may return the received packet to transfer to the host device 302 to route the combination of 108, even if a packet as part of a higher-level session also received is .

[0302] On the other hand, if the combined host is not good (as determined in block 2608), then the flow continues to block 2612. Likewise, if the received packet is not for a previously existing session (as determined in block 2604), then the flow continues to block 2612. At block 2612, a host is selected based on the health status and load information. For example, the classifier 304 may select a host 108 from and/or using the health state and load-related application allocation obtained from the health state and load processor 314 (eg, a response 1804 from the target application endpoint allocation). Examples of these actions are described above with particular reference to FIGS. 19 and 18 and will be described further below with particular reference to FIG. 30.

[0303] At block 2614, the received packet is routed to the selected host. For example, the classifier 304 may route the packet (optionally via the transmission device 302) to the selected host 108. In block 2616, the routing line of the connection path of the selected host is detected. For example, the classifier 304 may add a session information entry to the DAM table 2206, especially in the DAM table 2206 that is local to the transmission device 302 that provides the packet to the classifier 304. The session information entry may be replicated according to a redundancy strategy constructed for DAM 2202 (for example, session tracker 308).

[0304] The actions of block 2614 and block 2616 can be executed in the order specifically illustrated, wherein the action of block 2616 is executed before the action of block 2614, and the actions that overlap partially or completely can be executed in any order, etc. . It should be noted that the operations performed by the classifier 304 described above can be selectively performed by a request router 306 (or more general service routing function 2012).

[0305] FIG. 27 illustrates an exemplary service routing process in a no-fault condition. As illustrated, one or more load balancing aware switches 202 (LBA) face the remaining load balancing infrastructure 106 (not shown separately). The transmission and classification functions are distributed to three devices or nodes. The first device includes a conveying device 302(1) and a classifier 304(1). The second device includes a classifier 304 (2). A third device includes conveying means 302(2).

[0306] As the classifier 304(2) runs on the second device and the transfer device 302(2) runs on the third device, each device can specifically adjust its respective functions. For example, the hardware, software, firmware, and combinations of the second device and the third device, etc., can be adapted to support the desired functions without exceeding the regulations. In this way, the third device including the transmission device 302(2) is similar to a switch and/or router in terms of hardware capability, while the second device including the classifier 304(2) is similar to a server and/or in terms of hardware capability. Or personal computer.

[0307] Although three devices capable of providing functions on four components are shown, the optional logic-level and/or device-level configurations with transmission and classification functions are also applicable to the configuration shown in FIG. 27 here. Exemplary business route described

CN 1578320 Β

Process. Moreover, although the routing purpose is shown as the host 108, the description of the routing implementation method here can be selectively and generally applied to the next node destination of the packet, not necessarily the final node of the packet.

[0308] The DAM 2202 implementation of the session tracker 308 is used to implement the DAM table 2206. However, the session associativity saver 1904 is also generally applicable to the exemplary service routing of FIG. 27. The transmission device 302(1) includes a DAM table portion 2206(1), and the transmission device 302(2) includes a DAM table portion 2206(2). Incoming packets are routed to host 108(1) or host 108(2).

[0309] In a described implementation, DAM 2202 is a distributed memory table with session information "atoms" (for example, key-value pairs, with optional metadata). DAM 2202 and DAM table 2206 has been further described above, especially with reference to Figures 22-24. Any node in the classifier 304 group can add, query, and delete atoms 2304. DAM 2202 maintains a highly reliable DAM table 2206, which includes valid ( Such as TCP/IP level) routing and higher level session information.

[0310] In (1), the switch 202 (LBA) with load balancing awareness sends the incoming packet to the transmission device 302(1). In (2), the transmission device 302(1) queries its internal routing table, the DAM table 2206(1). When the transmitting device 302(1) does not find an atomic entry 2304 for the packet, it transmits the packet to its assigned and/or associated classifier, the classifier 304(1).

[0311] In (3), in this example, the classifier 304(1) recognizes that the packet is a TCP SYN packet. The classifier 304(1) therefore treats the packet as the beginning of a new TCP connection from the client 108. Using the health state and load information from the health state and load processor 314 (not shown), the classifier 304(1) determines that the host 108(1) should receive the TCP connection. The classifier 304(1) is updated to the DAM table 2206(1) of the transmission device 302(1) acting as a local routing table, and it also inserts an atomic entry representing the route into the entire DAM 2206. These may be separate operations, single operations, etc., in which the TCP/IP level session of the DAM table 2206 is located in the transmission device 302. The DAM 2202 internally replicates the route to one or more other members of the classifier 304 group according to its specified redundancy strategy.

[0312] In (4), the transfer device 302(1) directly transfers the subsequent packet to the host 108(1) for the connection without interacting with the classifier 304(1). The DAM 2202 can be used, at least in part, to conceal the failure of the conveyor 302, the sorter 304, or the conveyor/sorter pair 302/304. If the load balancing aware switch 202 (LBA) accidentally starts to send packets for the established connection to a different transmission device 302, the DAM 2202 can also be used, at least in part, to preserve client connectivity.

[0313] FIG. 28 illustrates an exemplary service routing flow when a failure occurs. Compared with the "failure-free" exemplary service routing process in FIG. 27, a part of the network load balancing infrastructure 106 (not specifically shown) in FIG. 28 has a failure. Specifically, the first device on which the transfer device 302(1) and the classifier 304(1) reside and operates, after creating the connection illustrated in FIG. 27, malfunctions. This failure was at least partially covered by DAM 2202.

[0314] In (1), the switch 202 (LBA) with load balancing awareness detects the failure of the transmission device 302(1) and starts to transmit the connected packet to the other transmission devices 302 in the group. In this example, the other transfer device 302 is the transfer device 302(2). Although FIG. 28 illustrates a failure situation, even if the transmission device 302(1) is still active, the load balancing aware switch 202 (LBA) can send the service to the transmission device 302(2). For example, because the switch 202 (LBA) with load balancing awareness "forgot" the combination of the service with the transmission device 302(1), such a non-fault-caused change of the transmission device 302 may occur. The actions marked (2)-(5) are not only applicable to failure situations, but also applicable to "forgetting

CN 1578320 Β

"Fitness" situation.

[0315] In (2), the transmission device 302(2) queries its routing table, the DAM table 2206(2). When it does not find a route for the packet, it passes the packet to its classifier 304(2). At (3), the classifier 304(2) recognizes that the packet is a "halfway connection" TCP packet, and the classifier 304(2) queries the DAM 2202 for the packet to find a route. DAM 2202 responds with a route from the connection of an atomic entry 2304 associated with it.

[0316] In (4), the classifier 304(2) detects the route in the transfer device 302(2). The following will further describe exemplary protocols used to detect routes. In (5), subsequent packets of this connection directed to the transmission device 302(2) are routed directly to the correct host without querying the classifier 304(2), which in this example is the host 108(1).

[0317] Generally, the route detection protocol used for communication between the classifier 304 and the transfer device 302 includes instructions for adding and deleting routes. More specifically, in order to detect a route from the transfer device 302 to the destination host 1098 for a given connection, the classifier 304 sends an add route instruction to the transfer device 302. As an example, as illustrated in (4) in FIG. 28, an add routing instruction may be provided from the classifier 304(2) to the transmission device 302(2). The route (e.g., a key and corresponding value) is added to the local DAM table 2206(2) for quick access by the transmission device 302(2) in the future. In this example, the classifier 304(2) is a separate device from the transmission device 302(2), so the routing detection protocol is an inter-device protocol. However, the routing detection protocol can also be used as a protocol for intra-device communication.

[0318] In one described implementation, the classifier 304(2) includes a connection list 2802. Using this connection list 2802, the classifier 304(2) tracks the connection of any transfer device 302 (for example, the transfer device 302(2)), which is the transfer device for which the classifier detects routes. In order to enable the classifier 304(2) to track the connection and its termination, the transmitting device 302(2) transmits the last packet of the connection (for example, a TCP FIN packet) to the classifier 304(2). Next, the classifier 304(2) deletes the entry corresponding to the connection in the connection list 2802, and sends a delete routing instruction to the delivery device 302(2). Once the delete routing instruction is received, the delivery device 302(2) Remove the corresponding route from the DAM table 2206. In this way, the classification function combined with the session tracking function can control the routing table and its routing, which are used by the transfer function. Thus, the transfer function separated into different devices can be completed with high-speed but relatively simple hardware.

[0319] FIG. 29 illustrates an additional exemplary troubleshooting process to ensure high reliability of the network load balancing infrastructure 106. Describes the troubleshooting process used to troubleshoot two different faults, fault 2902 and fault 2906. As illustrated, the network load balancing infrastructure 106 (not separately shown) includes five components: delivery device 302 (1), delivery device 302 (2), delivery device 302 (3), classifier 304 (1), and Classifier 304 (2).

[0320] In a described implementation, each of the five components 302(1), 302(2), 302(3), 304(1), and 304(2) corresponds to a separate device . However, similar troubleshooting procedures can be applied to environments where different load balancing components share equipment.

[0321] Initially, in [1], the router/switch 202 sends the incoming packet generated for a new connection to the transmission device 302(1). Since the transmission device 302(1) has no route for the connection in its local routing table, it sends the packet to the classifier 304(1), as indicated by the dashed double-headed arrow in (1). The classifier 304(1) first checks the session information about the session tracking 308 for possibly higher-level session associativity. In this example, the grouping is not combined with an existing session. Therefore, the classifier 304(1) selects a host 108 based on the health state and load information related to the health state and load processing 314.

[0322] Specifically, in this example, the classifier 304(1) selects the host 108(1). Assuming that the packet is used for a TCP/IP connection, then the TCP/IP session connected to the host 108(1) is used by the classifier 304(1) to add the atom 2204(A) function

CN 1578320 Β

The call was added to DAM 2202. The initial packet is transmitted to the host 108(1) by the classifier 304(1) or the transmission device 302(1). The classifier 304(1) also detects a route in the local routing table of the transfer device 302(1). Subsequent packets will be transmitted by the transmission device 302(1) to the host 108(1) without further interaction with the classifier 304(1).

[0323] At some point during connection [1], a failure 2902 occurred in the transmission device 302(1). Using the router/switch 202 (LBA) with load balancing awareness, the failure 2902 is detected. As a result, at point 2904, the router/switch 202 sends the subsequent packet that should have been sent to the transmission device 302(1) through the connection [1] to another transmission device 302, which is the transmission device 302(2) in this example. .

[0324] The transmission device 302(2) then receives subsequent packets through the connection [2]. Since the transmission device 302(2) does not have an entry in its local routing table for the packet previously directed to the transmission device 302(1), the transmission device 302(2) sends the first received packet received by the connection [2] To the classifier specified/associated with it. In this example, the transfer device 302(2) is assigned a classifier 304(2), as indicated by the dashed double-headed arrow at (2).

[0325] The classifier 304(2) uses the query atom 2204(Q) function call to obtain the atom entry 2304 (not shown) from the DAM 2202 associated with the existing TCP/IP connection. The atom entry 2304 uses the return atom 2204 (R) function to call the DAM 2202 provided to the session tracking 308. The classifier 304(2) extracts the host 108(1) combined with the TCP/IP connection from the returned atomic entry 2304. The classifier 304(2) transmits the first received packet of the connection [2] to the host 108(1), and detects a route in the local routing table of the transmission device 302(2). Subsequent packets are transmitted to the host 108(1) by the transmission device 302(2) without further interaction with the classifier 304(2).

[0326] The above description mainly focused on the failure of a single transmission device 302 component. However, the classifier 304 component may also malfunction. For example, at some point, a fault 2906 occurred on the classifier 304(2). The transmission device 302(2) detects a failure 2906 when trying to use the classification service or finding that a certain activity indication (such as a heartbeat type indication) is missing. In order to handle the fault 2906, the transfer device 302(2) is re-assigned or re-associated to a different classifier 304, in this case the classifier 304(1). The subsequent classification function is provided by the classifier 304(1) to the transmission device 302(2), as indicated by the dashed double-headed arrow in (3).

[0327] FIG. 30 illustrates an exemplary operational implementation of service routing interacting with health status and load information. The transmission device 302 and the classifier 304 interact with the health status and load processor 314 in order to route packets to the hosts 108 (1), 108 (2)...108 (n). Although the transmission device 302 and the classifier 304 are illustrated, this exemplary operation implementation is also applicable to the request router 306 (or the general service routing function 2012).

[0328] As illustrated, the host 108(1) includes respective application program #1, application program #1, application program #2s respective application endpoints IP1, IP3, and IP4. Host 108(2) includes application program #1 and applications The respective application endpoints IP2 and IP6 of program #2. The host 108(n) includes the application endpoint IP5 of application #2. These hosts 108(1), 108(2)-108(n) and application endpoints IP1, IP2, IP3, IP4, IP5, and IP6 are monitored by the health status and load processor 314 (for example, using the health status and load infrastructure 1202, joint health status and load cache 1208, etc.).

[0329] In a described implementation, in (1), the classifier 304 requests the allocation of one or more application endpoints in an environment using the token allocation scheme 1806 (for example, through at least one target application endpoint allocation Request 1802). In this example, the state of health and load processor 314 responds by providing a token allocation 3002 (e.g., a response 1804 is allocated via at least one target application endpoint).

[0330] Specifically, the token allocation to the application #1 3002(1) and the token allocation to the application #2 3002(2) can be used for the classifier 304. The token allocation for application #1 3002(1) initially provided 40 tokens for IP1, which was

CN 1578320 Β

IP2 provides 35 tokens, and IP3 provides 25 tokens. The token allocation for application #2 3002 (2) provides 10 tokens for IP4, 72 tokens for IP5, and 18 tokens for IP6. For each new connection assigned by the classifier 304 to a route of an application endpoint, a token is consumed by the classifier 304.

[0331] In (2), the transmission device 302 receives an initial incoming packet for a new connection. Since there is no route for the new connection in the local DAM table portion 2206 of the transmission device 302, the transmission device 302 transmits the initial packet to the classifier 304 at (3).

[0332] In (4), the classifier 304 (for example, after judging that the initial packet does not include a session reference for a higher-level session) selects an application endpoint (and thus selects an application endpoint based on the health status and load information). Host 108). Specifically, for a new connection to be served by the application #1, if the token of the respective endpoint still exists, the classifier 304 can select any one of IP1, IP2, and IP3.

[0333] The classifier 304 can use the token in any possible way. For example, the classifier 304 can use a round-robin method without worrying about the number of tokens per endpoint. Optionally, before moving to the next endpoint in a linear manner, the classifier 304 may use all tokens for each endpoint to simply start from IP1 and progress to IP3. Moreover, the classifier 304 can use one token from the endpoint definition group of the token currently having the largest number of tokens at any one time. Using the latter method, the classifier 304 selects IP1. Of course, other methods can also be used.

[0334] As illustrated, the classifier 304 uses a token for the application endpoint IP2. Therefore, since one token is used up, the number of tokens in the IP2 token group is reduced from 35 to 34. Moreover, the initial packet of this new connection is routed to the application endpoint IP2_O

[0335] At (5A), the initial packet is transferred from the classifier 304 to the application endpoint IP2 of the host 108(2). Before, during, or after the transfer operation, the classifier 304 detects a route in the local DAM table part 2206 for the connection in (5B). For the purpose of distribution and replication, the classifier 304 may also add an atomic entry 304 to the DAM table 2206 for the session. In (6), the local routing table of the transfer device implemented by the local DAM table part 2206 in FIG. 30 is used to transfer the subsequent packets of the connection/session from the transfer device 302 to the application endpoint IP2 of the host 108(2). [0336] FIG. 31 illustrates an exemplary high reliability mechanism of the network load balancing infrastructure 106. Specifically, an exemplary failure detection 3104, an exemplary failure handling 3106, and an exemplary failure recovery 3108 are shown. These exemplary high reliability mechanisms will be described in conjunction with different network load balancing infrastructure 106 components. The network load balancing infrastructure 106 components include a transmission device 302, a classifier 304, a request router 306, a session tracker 308, and a health status and load processor 314.

[0337] At 3102(A), the transmission device 302 suffers from a local failure. At 3104(A), at least one switch with load balancing awareness detected the failure. In order to deal with this local failure 3102 (A), at 3106 (A), the packet is redirected to other transmission devices by the load balancing aware switch. In order to recover from the failure of the transmission device 302, in 3108(A), the route stored locally in the transmission device 302 is reconstructed in the transmission device to which the packet is redirected. This is done by using a distributed session tracking manager and Its tables, such as DAM and its DAM tables, are performed. Therefore, the distributed session tracking manager can include one or more levels of data redundancy.

[0338] At 3102(B), the classifier 304 suffers from a local failure. At 3104 (B), at least one transmission device detects the failure. In order to deal with the local failure 3102(B), in 3106(B), the packet is redirected to other classifiers by the transmission device that detected the failure. In order to recover from the failure of the classifier 304, in 3108(B), the session information stored locally in the classifier 304 is reconstructed in the classifier that redirects the packet by using DAM. The session information may be, for example, session information of a higher level than the baseline TCP/IP connection. Moreover, these session information can be considered

CN 1578320 Β

Part of the session tracking infrastructure that stays on the same device as the classifier 304.

[0339] At 3102(C), request routing 306 suffers from a local failure. At 3104(C), at least one transmission device and/or load balancing aware switch detects the failure. In order to deal with the local failure 3102 (C), at 3106 (C), the packet is redirected to other request routers by the transmission device and/or the switch with load balancing awareness. In the event of a local failure 3102 (C), the individual current logic request that the request router 306 is working on may be lost, unless each such individual logic request is replicated while the request is being serviced. In order to recover from the failure in the requesting router 306, at 3108(C), the session information and/or routing locally stored in the requesting router 306 is re-directed in the requesting router to which the packet (and the new logical request) is redirected. Construct. Likewise, such session information can be considered as part of the session tracking infrastructure residing on the same device as the requesting router 306.

[0340] At 3102(D), the session tracker 308 suffers a local failure. At 3104 (D), at least one conveyor and/or classifier detects the fault. For example, if the session tracker 308 resides on the same device as the classifier, the transmission device or another classifier can detect the failure. If the session tracker 308 resides on a separate device, then a classifier can detect the failure. In order to deal with local failure 3102 (D), in 3106 (D), one or more levels of data redundancy and distribution on multiple devices are constructed for the tracked session information. It should be understood that the described redundancy and distribution were established before failure 3102(D) occurred. In order to recover from the failure of the session tracker 308, in 3108(D), in order to deal with the second level of failure, (if it has not been so distributed and sufficiently replicated), the session information from the DAM table is at least two Redistribute and re-replicate across devices.

[0341] At 3102(E), the state of health and load processor 314 suffers from a local fault. At 3104(E), at least one classifier and/or request router detects the failure. For example, if the state of health and load processor 314 becomes unresponsive, especially if the state of health and load processor resides on a different device from the query component, then the state of health and load processor 314 receives the state of health and load. The information component can detect a fault. In order to deal with local faults 3102 (E), in 3106 (E), for the health status and load information, the cached health status and load data redundancy and inherent fault handling are used.

[0342] For example, each health state and load processor 314 can include a combined health state and load information cache 1208, which replicates information in the health state and load tables 1204 on multiple hosts 108. Moreover, the user of a given health status and the health status of the load processor 314 and the load information 1206 can be located on the same device as the health status and the load processor 314, so that the health status and the failure of the load processor 314 are inherent The ground is acceptable. Similarly, the authoritative versions of the respective parts of the health status and load information 1206 are located on the respective hosts 108 so that the host 108 causes the loss of the respective parts of the health status and load information to be acceptable.

[0343] In order to recover from the failure of the state of health and load processor 314, a given network load balancing component using the state of health and load information can query a different state of health and load processor, because each state of health and load processor The load processor includes a joint cache of health status and load processor information. Moreover, when the health status and load processor 314 is accessible again, the message protocol 1500 can be used at 3108(E) to reconstruct its joint cache of health status and load information. Using these exemplary high-reliability mechanisms, in order to conceal these failures from the client 102, failures of the network load balancing infrastructure 106 components can be detected, processed, and recovered.

[0344] Exemplary connection transfer using optional tunneling and/or application-level load balancing

[0345] This section describes how connection operations, such as connection transfer, are used in network load balancing. This section mainly refers to FIGS. 32-39 and clarifies the connection transfer function, such as that provided by the connection transfer device 310 (in FIG. 3). As described above with reference to Figures 3 and 4, each incoming connection at the load balancing infrastructure 106 can be

CN 1578320 Β

Was terminated here. Thereafter, the connection can be transferred to a host 108 so that the connection is subsequently terminated at the host 108. The connection transfer 310 can perform this connection transfer, and may be partially placed on the host 108 to complete the transfer. This connection transfer may be performed by the classifier 304 and/or the tunneling operation through the tunneler 312 in combination with application-level load balancing.

[0346] FIG. 32 illustrates an exemplary method for implementing application-level network load balancing using connection transfer. Application-level, or layer-7 load balancing is related to making load-balancing decisions for applications that need to handle connections. In order to perform application-level load balancing, the load balancing infrastructure 106 generally considers the data portion of the connection. Unless request routing is used, the classifier 304 generally looks at the beginning of the connection, and then works with the connection transfer 310 to transfer the connection to the selected host 108.

[0347] For application-level load balancing in a generally TCP-based environment, when deciding where to transfer the client's TCP connection, the classifier 304 snoops the beginning part of the client's TCP data. In this way, the application-level logic part checks the customer's data and makes a load balancing decision based on the data. For example, if the connection is an (unencrypted) HTTP connection, then the classifier 304 can peek into the HTTP header of the first HTTP request in the connection, and can be based on the content of the header (e.g., URL, cookie, etc.) Some parts of the system are used to make routing decisions. Although application-level load balancing, connection transfer, and tunneling are applicable to other protocols, TCP/IPo is mainly used in the examples here.

[0348] As exemplified, the load balancing infrastructure 106 (not specifically shown) includes a transmission device 302, a classifier 304, a tunnel 312, and a connection transfer 310 (and may include, for example, load balancing aware routers/ Switch 202 (LBA)) o The transfer device 302 corresponds to the virtual IP address, and transfers the packet to the host 108 according to the host selection made by the classifier 304. Although not specifically illustrated in FIG. 32 for the sake of clarity, the host 108 also includes the function of the connection transfer 310 and the function of the tunnel 312.

[0349] In a described implementation, the transmission device 302, the classifier 304, and the connection transfer 310 (on the classifier 304 and the host 108 ±), and the TCP protocol software on the classifier 304 and the host 108 work together To provide connection transfer. The connection transfer illustrated in FIG. 32 is for the connection from the client 102(1) that initially terminates at the classifier 304. After the connection is transferred, the connection from the client 102(1) is terminated at the host 108(1). Once the connection host 108(1) is terminated, the tunnel 312 (at the transmission device 302 and the host 108(1)) is used to tunnel the connected packet.

[0350] In (1), the client 102 (1) sends a SYN packet to the transmission device 302 to indicate the start of a new TCP connection. At (2), the transmitting device 302 transmits the packet to the classifier 304. In (3), the classifier 304 represents a host 108 (because the actual target host 108() has not been selected, so its identity is not yet known) accepting the TCP connection. During the TCP protocol, the classifier 304 sends a SYN-ACK packet to the client 102 (1).

[0351] At (4), the client 102(1) starts sending data. (The initial SYN packet may also include data). The data is processed by the classifier 304, which can query the logic part of a specific application. The logic part of the specific application can involve which host 108 can handle or best handle what type of request or connection. Therefore, the classifier 304 uses the data, as well as the application health and load information from the health status and load processor 314, and optionally the application session information from the session tracker 308, to determine a comparison or maximum A host suitable for handling connections from client 102(1). In this example, host 108(1) is selected.

[0352] At (5), the classifier 304 sends a "binary block" (blob) representing the state of the TCP connection to the host 108(1). The connection transferer 310 integrates the connection state and the cooperation from the TCP protocol stack on the classifier 304 together. The binary block contains data from the client 102(1) that has been confirmed by the classifier 304 and

CN 1578320 Β

TCP parameters, such as TCP/IP quartet, initial sequence number, etc.

[0353] At (6), the connection transfer 310 component (not shown in FIG. 32) on the host 108(1) "injects" the connection into the TCP protocol stack on the host 108(1). The connection state injection is performed in cooperation with the TCP protocol stack on the host 108(1), so that for the application 316 on the host 108(1), the connection appears to be from the host 108(1). ) What I initially accepted. The client 102(1) is not aware of the connection transfer.

[0354] In (7), the classifier 304, together with the TCP protocol stack on the classifier 304, quietly clears the internal state maintained for the connection. The classifier 304 also adds a route to the local routing table of the transmission device 302, instructing the host 108(1) as the destination of the connected packet.

[0355] At (8), subsequent packets of the connection are routed by the transfer device 302 to the host 108 (1). These packets are the same as those connected packets that are classified and routed without using connection transfer, and are processed by the transmission device 302 in the same way. The tunneler 312 may be used to optionally tunnel these subsequent packets from the transmission device 302 to the host 108 (1). The tunneler 312 is exemplified in the connection transfer 310 of the classifier 304 (in dashed lines) because certain parameters used by the tunneler 312 can be determined during a connection transfer and/or associated with the connection being transferred. An exemplary implementation of the tunneler 312 will be further described below with particular reference to FIGS. 38 and 39.

[0356] FIG. 33 is a flowchart 3300 illustrating an exemplary method of transferring a connection from a first device to a second device. The flowchart 3300 includes seven blocks 3302-3314. Although Figures 32 and 34-37 mainly focus on connection transfer in a network load balancing environment, the connection transfer described here can include a connection transfer function in each of them (such as connection transfer The function of the device 310) is implemented in two general devices.

[0357] At block 3302, a connection is accepted at the first device. For example, the first device may terminate an incoming connection according to one or more protocols in the protocol stack portion of the network stack. At block 3304, the first device receives data for the connection. For example, the data may be received in the initial packet requesting the connection or in one or more packets received subsequently after the connection is accepted.

[0358] At block 3306, the connection state for the accepted connection is assembled from the protocol stack (or more generally from the network stack) in the first device. For example, the protocol status of one or more protocols of the protocol stack can be assembled and assembled together with any received data that has been confirmed. At block 3308, the connection status is sent from the first device to the second device. For example, the information of the set of connection states can be sent to the second device by using a reliable protocol.

[0359] At block 3310, the connection status of the connection being transferred from the first device is received at the second device. At block 3312, the connection state is injected into the protocol stack of the second device (or more generally into the network stack). For example, the protocol in the protocol stack of the second device can be used to rehydrated, so that the program at the protocol stack level does not realize that the connection is a transferred connection. More specifically, the protocol state can be injected into the protocol stack. The aggregate data of the connection status may also be combined on the second device. At block 3314, the connection is continued at the second device. For example, continue the connection on the second device as if the connection has never been terminated elsewhere.

[0360] FIG. 34 illustrates an exemplary method of connection transfer from a perspective view of the initiating device 3400. The connection transfer is at least partially completed by the connection transfer 310 in the initiating device 3400. In one described implementation, the initiating device 3400 is a device that is part of the network load balancing infrastructure 106. For example, the initiating device 3400 may include a classifier 304, possibly a transmission device 302, a request router 306, and so on.

[0361] As illustrated, the initiating device 3400 includes the physical network interface (PND3410, PNI miniport 3408, hardware protocol interface 3406, protocol stack 3404, and socket layer 3402 as part of its network stack). The initiating device 3400 also includes

CN 1578320 Β

Including load balancing functions 106, such as classifier 304 and connection transfer 310 at the application level. Specifically, the connecting transfer 310 includes a transfer intermediate driver 3414 and a transfer pad 3412. The connection transfer 310 can offload a connection from the initiating device 3400.

[0362] In one described implementation, the physical network interface 3410 may be a network interface card (NIC) (for example, an Ethernet NIC), a wireless interface, and so on. Although only one physical network interface 3410 is shown, a given device may actually have multiple such physical network interfaces 3410 (ie, the initiating device 3400 may be multi-homed). Each physical network interface 3410 generally corresponds to one or more actual network addresses.

[0363] The PNI miniport 3408 is a software module that can understand the specific hardware implementation of the physical network interface 3410 and connect with it. The hardware protocol interface 3406 is a layer including one or more respective interfaces between one or more respective protocols and the PNI miniport 3408.

[0364] The protocol stack 3404 includes one or more modules each pointing to one or more respective protocols. Examples of such protocols will be further described below with reference to FIGS. 36 and 37. In a transient environment, the protocol stack 3404 includes the protocol state 3420 of each connection that exists on the initiating device 3400. The socket layer 3402 is located between the program such as the load balancing function 106 and the protocol stack 3404. The socket layer 3402 provides an API between the load balancing function 106 and the protocol stack 3404, and among other things, it also enables the program to register the connection.

[0365] The transfer intermediate driver 3414, or more generally the transfer driver 3414, is located at the hardware protocol interface layer

3406. The translator pad 3412 is transparently located between the protocol stack 33404 and the socket layer 3402.

[0366] When an initial packet (not shown) requesting a new connection is presented to the initiating device 3400, the packet is directed upward from the physical network interface 3410 to the PNI miniport 3408, and to the protocol stack 3404 via the hardware protocol interface 3406. When the packet traverses one or more protocols of the protocol stack 3404, the protocol state 3420 is created here. Also, as a result of the initial grouping or as a result of the load balancing function 106 accepting the connection to spy the request, the data 3416 arrives at the initiating device 3400.

[036] In operation, the transfer intermediate driver 3414 transfers a copy of the data 3416 to the logical part connected to the transfer 310. When the load balancing function 106 issues a transfer connection function call, the transfer function call is passed to the highest layer of the protocol stack 3404 to start the connection state assembly 3418. The protocol status 3420 is assembled from one or more protocols of the protocol stack 3404. In the TCP/IP implementation, the protocol status 3420 can include (i) the destination and source TCP port and IP address (for example, a TCP/IP four-byte group), (ii) the TCP window status, (iii) the initial sequence number, (Iv) Timeout information, (ν) IP fragment ID, (vi) routing information, and (vii), etc.

[0368] The connection state aggregation 3418 also aggregates the data 3416 that has been converted to the connection transfer 310 and that has been confirmed by the source device 3400 (for example, through the load balancing function 106). The aggregated connection status 3418 includes protocol status 3420 and data 3416 (and optionally other connection-related information). Then the assembled connection status 3418 is sent from the initiating device 3400 to the target device in a binary block 3422 using a reliable protocol. If the connection is subsequently to be tunneled with the tunneler 312, the binary block 3422 can also be bundled with a stream identifier. The use of tunneled flow identifiers will be further described below with particular reference to FIGS. 38 and 39.

[0369] FIG. 35 illustrates an exemplary method of connection transfer from a perspective view of the target device 3500. In terms of the various layers/modules illustrated, including the connection transfer 310, the target device 3500 is similar to the initiating device 3400. However, as illustrated, at least one application 316 at the application level interfaces with the socket layer 3402. The target device 3500 may therefore include the host 108. Moreover, the connection transfer 310 can load a connection from the initiating device 3400.

[0370] In a described implementation, the application 316 is the initial connection score received by the initiating device 3400.

The destination of the group. From the initiating device 3400, the target device 3500 receives the binary block 3422. Binary block 3422 includes the connection state associated with the connection being transferred to target device 3500 and optionally includes a flow identifier. The connection status includes protocol status 3420 and confirmed data 3416 (and possibly other connection-related information).

[0371] In operation, when the binary block 3422 reaches the hardware protocol interface layer 3406, the transfer intermediate driver 3414 recognizes it as a block for connection transfer and converts it. At 3502, the connection state is injected to show the application that the connection was initially terminated at the target device 3500.

[0372] Specifically, the protocol state 3420 injected into the connection state 3502 is injected into the protocol stack 3404. In one described implementation, the protocol state 3420 is first injected into the higher-level protocols of the protocol stack 3404 and then to the lower-level protocols. After the protocol state 3420 is injected into the protocol stack 3404, the data 3416 is directed to the application 316. This data 3416 is provided to the application as if it were part of a new locally terminated connection.

[0373] After the connection state injection 3502 is completed, the connection started by the packet received at the initiating device 3400 is successfully transferred from the initiating device to the target device 3500. The subsequent packets of the connection are directly transmitted to the target device 3500 without passing through the initiating device, or only simple routing and non-application-level analysis are applied. Optionally, these packets can be tunneled so that the transfer intermediate driver 3414 operates efficiently as a software-based virtual NIC tied to a virtual IP address.

[0374] FIG. 36 shows an exemplary method of an offloading process 3600 for connection transfer. The transfer offloading process 3600 illustrates additional exemplary details of the connection transfer performed by an initiating device 3400. As illustrated, the general protocol stack 3404 includes a TCP protocol stack 3404 (T), an IP protocol stack 3404 (I), and an address resolution protocol (ARP) stack 3404 (A). However, other specific protocol stacks 34040 can optionally be used. [0375] As an example, the hardware protocol interface layer 3406 can be used as a network drive interface specification (NDIS-based) layer in the Microsoft Windows® operating system (OS) environment. to realise. Moreover, the socket layer 3402 can be implemented as the WinsockTM layer in the Microsoft Windows ® OS environment.

[0376] In one described implementation, the transfer intermediate driver 3414 includes a hardware protocol interface 3406 at the junction of the ARP stack 3404 (A) and the PNI miniport 3408. The transfer intermediate driver 3414 serves as an unloading target in the transfer unloading process 3600. The offload target is the hardware protocol interface 3406 miniport as shown in this example. In the transfer loading process 3700 (as in FIG. 37), the transfer intermediate driver 3414 acts as a loading converter.

[0377] More specifically, the transfer intermediate driver 3414 is bound to each physical network interface 3410, and the TPC connection can be transferred through the interface 3410. The transfer intermediate driver 3414 generally operates as a pass-through driver, and transmits the packet up or down in the network stack without other interaction with the packet. However, the transfer intermediate driver 3414 still interacts with the packets involved in connection transfer (optionally including subsequent tunneled packets).

[0378] The responsibilities of the transfer intermediate driver 3414 include: (1) accepting transfer unloading requests; (ii) assembling protocol status information and confirmed data related to the TCP connection being transferred as compiled from the specific protocol stack 3404() , To generate connection status information; and (iii) transfer the assembled connection status to the target device 3500 for the transfer loading process 3700. A reliable wire protocol for such transmission can be shared with the protocol used by the session tracking components 2002 and 2010 to send and receive the session information message 2008 (for example, as described above with reference to FIG. 20).

[0379] Another responsibility of the transfer intermediate driver 3414 (for example, in the transfer loading process 3700) is to start loading and buffering transfer connections that it receives from other devices and to transfer connections that are in the process of being loaded.

CN 1578320 Β

Any incoming group of the related. To load the connection, the transfer intermediate driver 3414 sends a load request to the transfer shim 3412. The transfer pad 3412 issues an injection command to the protocol stack 3404 in the TCP stack 3404 (A) below, and the connection is instantiated in the protocol stack 3404 part of the network stack.

[0380] The transfer pad 3412 exposes a client interface to the TCP stack 3404 (T), and exposes a provider interface to the socket layer 3402. The transfer pad 3412 has two roles: (i) initiates the connection transfer unloading process 3600 on the initiating device 3400 and then initiates the transfer loading process 3700 on the target device 3500, and (ii) serves as the host application 316 program, load The intermediate of the classification process between the balance classifier 304 program and the socket layer 3402. Both the transfer pad 3412 and the transfer intermediate driver 3414 will be further described with reference to FIGS. 36 and 37 below.

[0381] For the exemplary transfer offloading process 3600, the transfer of the TCP connection is performed after the classifier 304 uses one, two or more packets of the incoming TCP connection to classify the incoming TCP connection. The transfer uninstall process 3600 is described at points <1> to <7>.

[0382] In <1>, initialization is performed before the classification operation. The protocol stack 3404 makes a query at the hardware protocol interface layer 3406 to determine what offload capabilities (if any) are available. The transfer intermediate driver 3414 indicates that connection transfer offloading is possible, and propagates the query result down to the PNI miniport 3408. If the physical network interface 3410 provides TCP chimney offload capability, then the PNI miniport 3408 also indicates so. TCP chimney offloading enables some TCP/IP processing to be offloaded to the hardware of the physical network interface 3410 and involves some compilation of the protocol state 3420. Thus, some assembly and assembly logic can be shared between the two offloading mechanisms.

[0383] In <2>, once a TCP connection is classified, the classifier 304 initiates a TCP connection transfer to the selected host 108. Specifically, issue a transfer command instructing the target device 3500 to pass through the socket layer 3402 to the transfer pad 3412.

[0384] In <3>, the transfer pad 3412 starts the TCP connection transfer to assemble the TCP protocol state. Specifically, the transfer pad 3412 calls TCP to initiate a transfer to uninstall the APK or, more generally, transfer connection function calls or transfer connection commands). This routine assembles the relevant state of the specific TCP connection to restore the connection on the target device 3500. The compiled protocol state 3420 includes the state from the middle stack layer, which includes the TCP stack 3404 (T), the IP stack 3404 (I), and the APR stack 3404 (A).

[0385] In <4>, once the protocol stack 3404 has the assembly protocol state 3420 of the TCP connection being transferred, it calls the initiating transfer offloading API on the small port to which it is bound; in this example, the The small port is the transfer intermediate driver 3414. However, in practice, there can be other intermediate drivers inserted between the protocol stack 3404 and the transfer driver 3414, such as IP Qoso. If this is the case, if relevant, those IM drivers can be assembled/assembled by their status The connection status information of the connection being transferred is used to participate in the transfer process. The intermediate driver continues to propagate the initiating transfer offload command down to the network stack, which ultimately leads to execution in the transfer offload processor in the transfer intermediate driver 3414. At this point, the transfer intermediate driver 3414 also aggregates any confirmed data with the remaining connection status for the transfer of the TCP connection to the target device 3500.

[0386] In <5>, after storing/copying the connection status information for the TCP connection being transferred, the transfer intermediate driver 3414 notifies the network stack that the transfer is in the final stage by calling the transfer unload completion API. The initiating transfer unloading completion API follows its reverse path through the same intermediate driver (if any) to reach the network stack and finally to the protocol stack 3404. As each layer processes the command, the state information associated with the transferred connection can be released. Until the processing of the command is completed, each layer sends an update notification to the network stack to update any part of the connection state that has changed since the transfer was initiated.

CN 1578320 Β

[0387] In <6>, when the initiating transfer unloading completion routine reaches the TCP stack 3404 (T), TCP silently (that is, no reset is sent to the client 108) closes the connection, and clears all connections related to the transfer The associated status is connected, and the initiating transfer uninstall completion command is propagated to the transfer pad 3412. At this point, the network stack does not have any residual knowledge of the transferred TCP connection.

[0388] In <7>, when the initiating transfer uninstall completion command returns to the transfer intermediate driver 3414 (by connecting the transfer pad 3412 part of the transfer 310), the transfer from the initiating device 3400 to the target device 3500 The transfer of the TCP connection follows the transfer of the connection state to the target device. The connection status can be transferred asynchronously and reliably.

[0389] Once the transfer starts, the initiating device 3400 is also responsible for ensuring that subsequent data from the client 108 is transferred to the target device 3500. Thus, even after the connection is successfully transferred to the target, the initiator still retains a certain amount of state of the connection (for example, a routing table entry) in order to correctly route subsequent packets to the target. When the connection is terminated, the target informs the initiator, so that the initiator is aware of any remaining status of the transferred connection.

[0390] Further, as a result of the asynchronous nature of the connection transfer, the data packet for the transfer connection transmitted by the initiating device 3400 (or if it is a separate device and therefore designated as the transmission device) can be received at the target device 3500 The transferred connection state started to reach the target device 3500 before. The transfer intermediate driver 3414 on the target device 3500 is responsible for caching these packets until the associated transfer connection is established on the target device 3500.

[0391] FIG. 37 illustrates an exemplary method of a loading process 3700 for connection transfer. The transfer loader 3700 illustrates additional exemplary details of the connection transfer performed by the target device 3500.

[0392] When the transferred connection reaches the target device 3500, it is relayed to the transfer intermediate driver 3414 for processing. After merging and absorbing the transferred connection state, the transfer intermediate driver 3414 and the transfer pad 3412 inject the transferred connection into the local network stack in a transparent manner to the application 316. For the exemplary transfer loading process 3700, the transfer of TCP connections at points <1> to <8> is described.

[0393] In <1>, as described above with reference to the transfer uninstallation process 3600, initialization is performed before the application hosting operation. Specifically, the protocol stack 3404 makes a query about what offload capabilities (if any) are available. The transfer intermediate driver 3414 fills in the TCP connection transfer support query to indicate that connection transfer loading is available, and propagates the query down to the PNI miniport 3408 for possible TCP chimney unloading capabilities.

[0394] In <2>, when the connection transfer data arrives at the target device 3500, the connection transfer information (for example, the bundled binary block 3422) is sent to the transfer intermediate driver 3414. The transfer intermediate driver 3414 reassembles the connection state, matches it with any relevant data that has arrived during the transfer, and prepares for loading into the network stack. Any data from the client 102 that arrives during the process of loading the transferred connection is cached by the transfer intermediate driver 3414. Once the transfer is successfully completed, the data will be sent to the application 316.

[0395] In <3>, in order to start loading the transferred connection to the local network stack, the transfer intermediate driver 3414 notifies the transfer pad 3412 that the transferred connection request has arrived. The diverter intermediate driver 3414 also sends the connection status (or at least the protocol status 3420) to the diverter pad 3412.

[0396] In <4>, the transfer pad 3412 starts the injection routine (or more generally the injection protocol state routine) by calling TCP and provides the transferred protocol state 3420 to the TCP stack 3404 (T), to Start loading the transferred connection. In <5>, TCP/IP uses the provided protocol state 3420 throughout the entire protocol stack 3404 to recreate the transferred connection

Pick up. The protocol status 3420 includes one or more of transmission status (TCP), path status (IP), adjacent and next hop status (ARP), and so on.

[0397] In <6>, if the transferred connection is successfully re-established on the target device 3500, TCP initiates a connection event to the client part of the transfer pad 3412 to indicate that a new connection has been created . There are many possible reasons for the failure, but general reasons may include lack of a corresponding listener, routing failure, and so on. In these cases where the network stack cannot re-establish the transferred connection, no connection event is indicated, and a failure state is specified in the start injection completion command. The connection transfer 310 is responsible for sorting out the transfer and sending a reset notification to the client 102 to abandon the connection.

[0398] In <7>, the transfer pad 3412 acts as a provider to propagate connection events to the socket layer 3402, so as to indicate to the listening application 316 that a new connection has been established. If the application 316 accepts the connection, it processes the request and responds through normal read and write socket operations; the application 316 may not realize that the connection is transferred. If the connection is not accepted by the application 316, TCP terminates the connection but does not send back a reset notification to the client 102. Again, a failure state is specified in the start injection completion command, and the connection transfer 310 is responsible for sorting out the transfer and sending back a reset notification to the client 102 to abandon the connection.

[0399] When the application 316 and the classifier 304 are co-located on the same device, a special situation arises: the transfer pad 3412 can arbitrate between them. When two types of programs reside on the same host 108, they can both listen to the same IP address and port. However, TCP generally has a listener on each unique IP address and port. Thus, the transfer pad 3412 can conceal such a configuration that the two programs are listening on the same IP address and port by multiplexing the two sockets into a single listener at the TCP layer.

[0400] In such a case, when a connection event reaches the client part of the diverter pad 3412, the diverter pad 3412 acts as a provider to determine which listening socket is on to deliver the connection notification at the socket layer 3402. If only one socket monitors the corresponding IP address and port, then this socket receives the connection event. If there is more than one socket listening, the reception depends on the environment in which the connection event is indicated. If the connection event is a brand new connection using a virtual IP address, then the connection event is sent to the classifier 304; if the connection event is a dedicated IP address (non-load-balanced IP address) or As a result of loading a transferred connection, then the connection event is sent to the target application 316.

[0401] In <8>, once the injection of the transferred connection is completed, TCP notifies the transfer pad 3412 by calling the provided start injection completion processing program. Regardless of whether the connection is successfully loaded, a status code is provided to notify the transfer pad 3412. If the loading of the transferred connection fails, the connection transfer 310 is responsible for sorting out the transfer and notifying the client 102 that the connection has been abandoned by sending a reset to the client 102. If the transferred connection is successfully injected into the local network stack, the transfer intermediate driver 3414 can start transmitting any buffered data from the client 102 by uploading the received packet through the packet receiving path of the hardware protocol interface 3406.

[0402] When the transferred connection is terminated (due to loading failure, due to the transferred connection being subsequently closed by normal means, etc.), the target device 3500 notifies the initiating device 3400. The initiating device 3400 uses these notifications to more effectively and reliably clear the lingering state of the transferred connection, including routing table entries. Therefore, in consideration of successfully transferred connections that will be arbitrarily terminated in the future, the transfer pads 3412 can monitor their activity and notify the transfer intermediate driver 3414 when their sockets are closed.

[0403] FIG. 38 illustrates an exemplary method of packet tunneling between the transmission device 302 and the host 108. The encapsulated packet 3808 can be tunneled from the transmission device 302 to the host 108 without causing any damage to each transmitted packet.

CN 1578320 Β

Overhead. As described further below, the tunneling is accomplished using the flow identifier 3814 and the respective encapsulation mapping tables 3806 and 3810 of the tunnelers 312(F) and 312(H) of the transmission device 302 and the host 108, respectively. The flow identifier 3814 is inserted into the encapsulated packet 3808.

[0404] As shown above with reference to FIG. 32, connected packets arriving after the connection transfer can be routed to the host 108(1) by tunneling performed by the transmission device 302 using the tunneler 312. In (8) (in FIG. 32), the transfer device 302 transfers this subsequent packet from the transfer device 302 with the network address "F" to the host 108 (1) with the network address "H1". As described above with reference to FIG. 4, in order to route incoming packets to the host 108(1), the transmission device 302 may perform NAT, semi-NAT, tunneling, and so on.

[0405] This incoming packet includes the destination IP address of the virtual IP ("VIP") address and the source IP address "C1" of the packet arriving from the client 102(1). The packet that is routed to host 108(1) has a destination IP address H1 and a source address C1 (for half-NAT) or "F" (for full NAT). Such address rewriting can hinder some protocols that expect the client 102(1) and the host 108(1) to have the same knowledge of the source and destination addresses.

[0406] In addition, at least with regard to full NAT, since the host 108(1) does not know the address of the client 102(1), the return path from the host 108(1) to the client 102(1) does not pass through the transmission device 302 banned. In the case where the traffic from the host 108(1) to the client 102(1) is particularly high and/or significantly higher than the traffic in the opposite direction (for example, when the host 108(1) provides streaming media to the client At the end 102(1)), a direct path from the host 108(1) to the client 102(1) is desired.

[0407] The tunneling performed by the tunneler 312 as described herein can provide the application 316 on the client 102 and the host 108 with consistent knowledge of the source and destination addresses (and ports). As an example and referring to FIGS. 34 and 35, the tunnel 312 in each of the transfer devices 302 and the host 108 may operate as part of or in conjunction with the transfer intermediate driver 3414 of the transfer device 310.

[0408] In an implementation described with FIG. 38, the connection transfer 310 provides an encapsulation mapping 3812 between the flow identifier 3814 and the TCP/IP quattrogram 3804. The connection transfer 310 may be associated with the classifier 304, And the connection transfer 310 (optionally together with such a sorter 304) may be located on the same equipment as the transfer device 302. Optionally, the connection transfer 310 (and the sorter 304) may be located on a device different from the transfer device 302. The encapsulation map 3812 may optionally be provided by or in combination with the tunneler 312 function, for example, the tunneler function is located in or associated with the classifier 304.

[0409] The flow identifier 3814 is used to identify the flow of the encapsulated packet 3808 for a certain connection by being mapped to the TCP/IP quartet 3804 in the encapsulation mapping 3812. The TCP/IP quartet 3804 includes the source and destination network addresses (and ports, etc.) for a connection according to the TCP/IP protocol or any similar or comparable protocol. Because the connection established according to the Internet IPv4 protocol uses 32 bits, the flow identifier 3814 is 32 bits in a described implementation. However, flow identifiers 3814 of other lengths can optionally be used, especially for other protocols such as IPv6, UDP, etc.

[0410] The flow identifier 3814 can be generated by any suitable mechanism, such as an increment connection counter. In addition, the TCP/IP quartet 3804 is more generally a source/destination pair. Each source value and destination value of a single source/destination pair can include the respective source and destination network node identifiers (incoming network address, port, some combination of them) of a given packet transmitted on a certain connection Wait).

[0411] The connection transfer 310 provides a package map 3812 to the host 108. The tunneler 312(H) in the host 108 stores the encapsulation map 3812 as the encapsulation map entry 3810 in the encapsulation map table 3819. Tunnel 312 (H) thereafter

The flow identifier 3814 can be used to map to and identify the specific connection corresponding to the TCP/IP quartet 3804. The encapsulation map 3812 can optionally be provided to the host 108 as part of a bundled binary block 3422 during the connection transfer operation.

[0412] The transmission device 302 also includes a tunneler 312 (F) component with an encapsulation mapping table 3806. The encapsulation mapping table 3806 stores an encapsulation mapping entry 3806 (1) that links/maps the TCP/IP quartet 3804 for a certain connection to the stream identifier 3814. The tunneler 312(F) also receives the mapping information of the encapsulation mapping entry 3806(1) from the connection transfer 310 (for example, as an encapsulation mapping 3812) [0413] Although only one encapsulation mapping entry 3806(1) is shown And 3810(1), but the package mapping table 3896 and package mapping table 3810 can each have multiple such entries. These encapsulation mapping tables 3806 and 3810 are combined with other information such as a table of session information of the session tracker 308.

[0414] When the 3808 sending device (such as the transmitting device 302) and the receiving device (such as the host 108) of the encapsulated packet only tunnel between each other, their encapsulation mapping tables may have the same encapsulation mapping entries. Otherwise, the encapsulation mapping table 3807 and the encapsulation mapping table 3810 may respectively have a different overall group of encapsulation mapping entries 3806 0 and encapsulation mapping entries 3810().

[0415] In operation, the transmission device 302 receives an incoming packet 3802 for a certain connection. This connection is associated with the TCP/IP quartet 3804. The incoming packet 3802 includes a TCP/IP four-byte group 3804 with a source IP address (of the client 102), a destination IP address (virtual IP), a source TCP port (of the client 102), and a destination TCP port.

[0416] The tunneler 312 (F) accepts the incoming packet 3802 for tunneling to the host 108. Using the TCP/IP quattrogram 3804, the tunnel 312(F) accesses the encapsulation mapping table 3806 to locate the encapsulation mapping entry 3806(1). The flow identifier 3814 is extracted from the encapsulation mapping entry 3806(1) that is linked/mapped to the TCP/IP quartet 3804.

[0417] In order to create the encapsulated packet 3808, the tunneler 312(F) inserts the flow identifier 3814 into the source and destination port portions of the TCP/IP quaternary header. For the Internet IPv4 implementation, these two TCP ports provide a total space of 32 bits. Also, for the source IP address portion of the TCP/IP quad header, the tunnel 312 (F) inserts the IP address "F" of the transmission device 302. For the destination IP address part of the TCP/IP quartet header, the tunnel 312 (F) inserts the IP address "H" of the host 108.

[0418] The transmission device 302 routes/transmits the encapsulated packet 3808 to the host 108, and the host 108 then receives the encapsulated packet from the transmission device 302. The tunneler 312(H) component of the host 108 detects that the encapsulated packet 3808 is a tunneled packet to be decapsulated.

[0419] The flow identifier 3814 is extracted from the encapsulated packet 3808, and is used to search the encapsulation mapping entry 3810(1) of the encapsulation mapping table 3810 for the corresponding TCP/IP quartet 3804 linked to it. TCP/IP The quad 3804 is used by the tunneler 312 (H) to recreate the TCP/IP quad 3804 header as if it were originally received in the incoming packet 3802 of the transmission device 302.

[0420] Specifically, the IP address F of the transmission device 302 is replaced by the source IP address, and the IP address H of the host 108 is replaced by the destination IP address. In addition, the flow identifier 3814 is replaced by the source TCP port and the destination TCP port. The decapsulated packet is then directed upwards from the network stack of the host 108 to the target application 316.

[0421] More generally, a part of the packet header of a given packet can be used to carry the stream identifier 3814, where the packet header part includes a source/destination pair part, and the header part does not need to be used for transmission. The given group. By giving at least part of the source/destination pair in the host 108 in advance, the flow identifier 3814 can be used to tunnel the packet

Channelization (for example, encapsulation and/or decapsulation) without introducing encapsulation overhead on each packet. In addition, full-size packets relative to a given protocol can be tunneled without being split.

[0422] FIG. 39 illustrates a flowchart 3900 of an exemplary method of tunneling a packet between a first device and a second device. For example, the first device and the second device may correspond to the initiating device 3400 and the target device 3500 of the load balancing infrastructure 106 and a cluster of hosts 108, respectively. However, channelization can also be used in non-load balancing implementations.

[0423] The flow chart 3900 includes twelve blocks 3902-3924. Although the operations of the flow chart 3900 can be performed in other environments in combination with a variety of software methods, it is particularly described using FIGS. 1-3, 32, 34, and 35. Some aspects and examples of methods.

[0424] At block 3902, a mapping of the flow identifier to the TCP/IP quartet is sent from the initiating device to the target device. For example, the initiating device 3400 may send an encapsulation map 3812 linking the flow identifier 3814 to a TCP/IP quartet 3804. At block 3914, the target device receives the mapping of the flow identifier from the initiating device to the TCP/IP quartet. For example, the target device 3500 receives the encapsulation map 3812 from the initiating device 3400 linking the flow identifier 3814 to the TCP/IP quaternary 3804.

[0425] Optionally, the target device 3500 may receive an encapsulation map 3812 from another device. As indicated by the dashed arrows 3962 and 3928, the operations of blocks 3904-3912 and blocks 3916-3924 may occur at some time after the operations of blocks 3902 and 3914, respectively.

[0426] At block 3904, an incoming packet from the client is received in the initiating device. For example, the initiating device 3400 receives an incoming packet 3802 from the client 102 with a header with a TCP/IP quattrogram 3804. At block 3906, the TCP/IP quartet of the incoming packet is used to look up the flow identifier for the connection corresponding to the client's packet. For example, the TCP/IP quartet 3804 mapped to the connection with the client 102 may be used to look up the flow identifier 3814 in the encapsulation mapping entry 3806(1) of the encapsulation mapping table 3806 for the connection.

[0427] At block 3908, the source IP and destination IP of the incoming packet are replaced by the source IP address of the initiating device and the target IP address of the target device, respectively. For example, the initiating device 3400 may use the IP addresses of the initiating device 3400 and the target device 3500 to replace the IP address portion of the TCP/IP quadlet 3804 part of the header of the incoming packet 3802.

[0428] At block 3910, the source port and destination port of the incoming packet are replaced with the flow identifier. For example, the initiating device 3400 may use the flow identifier 3814 to replace the source and destination TCP ports of the TCP/IP quartet 3804 part of the header of the incoming packet 3802. At block 3912, the encapsulated packet is sent from the initiating device to the target device. For example, the initiating device 3400 may send the encapsulated packet 3808 to the target device 3500.

[0429] At block 3916, the encapsulated packet from the initiating device is received at the target device. For example, the target device 3500 may receive the encapsulated packet 3808 from the initiating device 3400. At block 3918, the flow identifier is used to look up the TCP/IP quartet corresponding to the connection received from the client. For example, the target device 3500 may access the encapsulation mapping table 3810 after mapping the flow identifier 3814 to the encapsulation mapping entry 3810(1) of the TCP/IP quartet 3804.

[0430] In block 3920, by using the found TCP/IP four-byte group, the source IP and the destination IP are used to replace the originating IP address and the destination IP address, respectively. For example, the target device 3500 can use the source IP address and the destination IP address of the TCP/IP four-byte group 3804 obtained from the encapsulation mapping table 3810 instead of the initiator device 3400 and the target device 3500 in the encapsulated packet 3808. IP address.

[0431] In block 3922, replace the flow identifier with the source port and destination port of the incoming packet by using the found TCP/IP quartet. For example, the target device 3500 can use the TCP/IP quartet 3804

Instead of the flow identifier 3814 in the encapsulated packet 3808, the source TCP port and destination TCP port of. At block 3924, the client's grouping is directed upwards to the application on the target device. For example, an unencapsulated version of the encapsulated packet 3808 or the incoming packet 3802 is directed upward to the application 316 of the target device 3500.

[0432] The operations, aspects, features, components, etc., described in FIGS. 1-39 are described in a schematic diagram divided into multiple blocks. However, the sequence, internal connection relationship, layout, etc. described and/or shown in FIGS. 1-39 should not be construed as any limitation, and any number of blocks can be used to implement one or more Systems, methods, equipment, procedures, media, APIs, devices, configurations, etc. for network load balancing can be combined, rearranged, expanded, omitted, etc. in any manner. In addition, although the description herein includes reference to specific implementations (and the exemplary operating environment in FIG. 40), the illustrated and/or described implementations can be implemented in any suitable hardware, software, firmware, or Their combination and use any suitable network organization, transmission/communication protocol, application programming interface (API), client-server structure system, etc. to achieve.

[0433] Example operating environment of a computer or other equipment

[0434] FIG. 40 exemplifies that at least one system, equipment, device, component, configuration, protocol, scheme, method, program, medium, API, and their functions can be implemented (in whole or in part) for performing network load balancing described herein. Exemplary computing (or general equipment) operating environment 4000 of some combinations and so on. The operating environment 4000 can be used in the computer and network structure described below or in an isolated situation.

[0435] The exemplary operating environment 4000 is only an example of an environment, and does not imply the function and scope of use of the structure of the application equipment (including computers, network nodes, entertainment equipment, mobile devices, general electronic equipment, etc.) Any restrictions. Neither can the operating environment 4000 (or its equipment) be interpreted as a dependency and requirement related to any one component or any combination of components illustrated in FIG. 40.

[0436] In addition, network load balancing can be implemented in a variety of other general-purpose or special-purpose device (including computing system) environments or configurations. Examples of applicable well-known devices, systems, environments and/or configurations include personal computers, server computers, thin clients, thick clients, personal digital assistants (PDAs) or mobile phones, watches, handheld or Laptop devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, video game consoles, game consoles, portable or handheld game units, network PCs, small computers, mainframe computers, networks Nodes, distributed or multi-processing computing environments including the above-mentioned systems or devices or their combinations, etc., but are not limited to this.

[0437] The implementation for network load balancing will be described in the general context of processor executable instructions. Generally, processor-executable instructions include routines, programs, protocols, objects, interfaces, components, data structures, etc., that perform and/or implement specific tasks and/or implement specific abstract data types. Network load balancing, such as certain implementations described herein, can also be applied in a distributed processing environment, in which tasks can be performed by processing devices connected remotely through a communication link and/or a network. Especially in a distributed computing environment, instructions executable by a processor may be located in a separate storage medium, executed by different processors, and/or propagated on a transmission medium.

[0438] The exemplary operating environment 4000 includes a general-purpose computing device in the form of a computer 4002, which includes any (eg, electronic) device with computing/processing capabilities. The components of the computer 4002 include one or more processors or processing units 4004, a system memory 4006, and a system bus 4008 that couples various system components including the processor 4004 to the system memory 4006, but is not limited thereto.

[0439] The processors 4004 are not limited by the materials constituting them or the processing mechanisms used therein. For example, the processor 4004 may include semiconductors and/or transistors (eg, electronic integrated circuits (IO)). In such a context,

CN 1578320 Β

In this context, processor-executable instructions may be electronically executable instructions. Optionally, the mechanism of the processor 4004 or the mechanism used in the processor 4004 and the mechanism of the computer 4002 or used in the computer 4002 include quantum computing, optical computing, mechanical computing (for example, using nanometer technology), etc., but It is not limited to this.

[0440] The system bus 4008 represents any one or more of a variety of types of wired or wireless bus structures. These bus structures include a memory bus or a memory controller, point-to-point connections, switching structures, peripheral buses, accelerated graphics ports, and A processor or local bus using any one of a variety of bus structures, but not limited to this. As examples, this structure includes the industry standard architecture (ISA) bus, the microchannel architecture (MCA) bus, the enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and also known as the Mezzanine bus. Peripheral Component Interconnect (PCI) bus, and some of their combinations, etc.

[0441] The computer 4002 generally includes a variety of media that can be accessed by a processor. These media can be any available media that can be accessed by the computer 4002 or another (for example, electronic) device, and it includes volatile and nonvolatile media, removable and non-removable media, and Storage and transmission media.

[0442] The system memory 4006 includes a processor-accessible storage medium in the form of a volatile memory, such as a random access memory (RAM) 4040, and/or a non-volatile memory, such as a read only memory (ROM) 4012. The basic input/output system (BIOS) 4014, which contains basic routines that help transfer information between elements inside the computer 4002, such as during startup, is generally stored in the ROM 4012. The RAM 4010 generally contains data and/or program modules/instructions that can be accessed and/or operated immediately by the processing unit 4004.

[0443] The computer 4002 may also include other removable/non-removable and/or volatile/nonvolatile storage media. As an example, FIG. 40 illustrates a hard disk drive or disk drive array 4016, which is used to perform read and write operations on (generally) non-removable, non-volatile magnetic media (not separately shown); a disk drive 4018 is used to Perform read and write operations on a removable, non-volatile disk 4020 (for example, a "floppy disk"); and an optical disk drive 4022, used to perform a (generally) removable, non-volatile optical disk 4024, For example, CD, DVD, or other optical media, perform read and write operations. Each of the hard disk drive 4016, the magnetic disk drive 4018, and the optical disk drive 4022 is connected to the system bus 4008 through one or more storage medium interfaces 4026. Optionally, the hard disk drive 4016, the magnetic disk drive 4018, and the optical disk drive 4022 may be connected to the system bus 4008 through one or more other separate or combined interfaces (not shown).

[0444] Disk drives and their associated processor-accessible media provide non-volatile storage of instructions executable to the processor, such as data structures, program modules, and other data for the computer 4002. Although the exemplary computer 4002 illustrates a hard disk 4016, a removable disk 4020, and a removable optical disk 4024, it should be understood that other types of processor-accessible media can also be used to store instructions that can be accessed by the device, such as tape cartridges. Or other magnetic storage devices, flash memory, compact disc (CD), digital versatile disc (DVD) or other optical storage, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), etc. This medium may also include so-called dedicated or hard-wired IC chips. In other words, any processor-accessible medium can be used to implement the storage medium of the exemplary operating environment 4000.

[0445] Any number of program modules (or other instruction/code units or groups) can be stored on the hard disk 4016, magnetic disk 4020, optical disk 4024, ROM 4012, and/or RAM 4040±, including the operating system 4028 as a general example , One or more application programs 4030, other program modules 4032, and program data 4034.

[0446] The user can input commands and/or information into the computer 4002 through input devices, such as a keyboard 4036 and a pointing device 4038 (for example, a "mouse"). Other input devices 4040 (not specifically shown) may include microphones, joysticks, gamepads, satellite reflectors, serial ports, scanners, and/or similar devices. These and other losses

CN 1578320 Β

The input device is connected to the processing unit 4004 through an input/output interface 4042 coupled to the system bus 4008. However, input devices and/or output devices can be connected via other interfaces and bus structures instead, such as parallel ports, game ports, universal serial bus (USB) ports, infrared ports, IEEE 1394 ("Firewire") interfaces, IEEE 802. 11 wireless interface, Bluetooth wireless interface, etc.

[0447] The monitor/visual display 4044 or other types of display devices may also be connected to the system bus 4008 through an interface such as a video adapter 4046. The video adapter 4046 (or another component) may be or include a graphics card for processing graphics-intensive calculations and processing display requirements. Generally, a graphics card includes a graphics processing unit (GPU), video RAM (VRAM), etc., to help quickly display graphics and demonstrations of graphics operations. In addition to the monitor 4044, other peripheral output devices include components such as speakers (not shown) and a printer 4048, which can be connected to the computer 4002 through the input/output interface 4042.

[0448] The computer 4002 may run in a networked environment using logical connections to one or more remote computers such as remote computing devices. As an example, the remote computing device 4050 may be a personal computer, a portable computer (e.g., a laptop computer, a tablet computer, a PDA, a mobile station, etc.), a palm or pocket-sized computer, a watch, a gaming device, a server, a router, Network computers, peer-to-peer devices, additional network nodes, or other types of equipment as listed above, etc. However, the remote computing device 4050 is exemplified as a portable computer, which includes many or all of the elements and features of the computer 4002 described herein.

[0449] The logical connection between the computer 4002 and the remote computer 4050 is described as a local area network (LAN) 4052 and a general wide area network (WAN) 4054. These network environments are in offices, enterprise-wide computer networks, intranet, Internet, fixed and mobile telephone networks, ad-hoc and infrastructure wireless networks, other wireless networks, gaming networks, some combinations of them, Waiting is very common. These networks and communication connections are examples of transmission media.

[0450] When implemented in a LAN networking environment, the computer 4002 is usually connected to the LAN 4052 through a network interface or adapter 4056. When implemented in a WAN networking environment, the computer 4002 generally includes a modem 4058 or other devices used to connect to the WAN 4054. The device that establishes communication. The modem 4058 located inside or outside the computer 4002 can be connected to the system bus 4008 through the input/output interface 4042 or any other suitable method. It should be understood that the illustrated network connection is exemplary and other means may be used to establish a communication link between the computers 4002 and 4050.

[0451] Further, other hardware specifically designed for servers can be used. For example, you can use an SSL accelerator card to offload SSL computing. In addition, especially in an operating environment for network load balancing, the TCP offload hardware and/or packet classifier on the network interface or adapter 4056 (such as on the network interface card) can be installed and applied in the server device.

[0452] In a networked environment, such as an environment exemplified by the operating environment 4000, the program modules or other instructions described with respect to the computer 4002, or parts of them, can be stored in a remote medium storage in whole or in part. In the device. As an example, the remote application program 4060 resides on the memory component of the remote computer 4050, but can be used or accessed through the computer 4002. Moreover, for illustrative purposes, the application programs 4030 and other processor-executable instructions, such as the operating system 4028, are exemplified here as discrete blocks, but it should be recognized that these programs, components, and other instructions reside at various times. It remains in the different storage components of the computing device 4002 (and/or the remote computing device 4050) and is executed by the processor 4004 of the computer 4002 (and/or the remote computing device 4050).

[0453] Although the system, medium, device, method, process, device, technology, scheme, manner, configuration, and other implementation manners are described in language specific to structure, logic, algorithm, and functional features and/or schematic diagrams, But should understand the origin

CN 1578320 Β

The description is not necessarily limited to the specific features or schematic diagrams described. Rather, specific features and schematic diagrams are disclosed only as exemplary forms for implementing the claimed invention.

CN 1578320 Β