KR19980018141A - Gateways and Methods for Routing Incoming Messages Across Cluster Boundaries - Google Patents

Abstract

The TCP connection router splits each encapsulated cluster into multiple virtual ECs (VECs) and dynamically distributes incoming connections within the VEC based on current server load metrics according to configurable policies. Thereby executing the encapsulated clusters. In one embodiment, the access router supports dynamic configuration of the cluster, making it possible to transparently recover to provide uninterrupted services for VEC clients.

Description

Gateways and Methods for Routing Incoming Messages Across Cluster Boundaries

TECHNICAL FIELD The present invention relates to networked computer processing, and more particularly, to clustering of computers that support a series of remote services.

An encapsulated cluster (EC) is characterized by having a plurality of server hosts and connection router (CR) nodes that provide a set of services (eg, web services, NFS, etc.). An example of an encapsulated and clustered system is described in US Pat. No. 5,371,852 entitled METHOD AND APPARATUS FOR MAKING A CLUSTER OF COMPUTERS APPEAR AS A SINGLE HOST ON A COMPUTER NETWORK.

The remote client requests the service from the EC, for example using the TCP / IP protocol (eg HTTP). The service time for each request varies with the type of service and availability of the server application. Therefore, the connections are quickly and naturally allocated in one place, resulting in insufficient utilization of the available EC resources, resulting in unnecessary delays to the request.

The prior art shows that there are many problems with performance in terms of scaling of servers. See, for example, NCSA's World Wide Web Server: Design and performance IEEE Computer, Volume 28, Number 11, November 1995, Pages 68-74. Consider an EC that uses round-robin DNS, or httpd daemons, to support a Web server. The server provides access services, database queries, and static web pages for the video stream over http. Service times for various needs vary widely depending on the actual content associated with the type of service provided. Complex database queries, for example, take tens of times longer than providing static HTML pages that are pre-loaded. This imbalance in demand processing time often results in unbalanced utilization of server clusters. Issues with round robin DNS are described in Kwa et al. In User Access Patterns to NCSA's Worldwide Web Server, Technical Report UIUCDSD-R-95-1394, Department of Computer Science, University of Illinois Urbana-Chapaign, Febrary 1995. .

The prior art demonstrates the need to dynamically allocate resources. See, for example, Evaluating Management Decisions via Delegation, The Third International Symposium on Integrated Network Management, San Francisco, CA, April 1993 by German Goldszmit and Yechiam Yemeni. The EC typically provides a collection of services of a single system image by a collection of hosts. In actual installations, however, services need to be assigned according to specific user policies, which can be dynamic. For example, one group of specific hosts may be allocated for the secure transaction of a commercial web server, while another group of hosts, including dedicated hardware, may support video on demand (VOD) services.

It is an object of the present invention to improve the overall throughput of encapsulated clusters.

Another object of the invention is to reduce the aggregate delay of remote service requests.

Another object of the present invention is to provide a means for designing a node such that a network client does not experience interruption of service while the access router is operating in error.

According to a first aspect of the invention, the encapsulated cluster (EC) is characterized by having a gateway node and a server host. The gateway node can (1) divide the EC into multiple virtual ECs (VECs) and (2) dynamically establish incoming connections within the scope of the VEC based on current server load metrics according to configurable policies. (3) support dynamic configuration of clusters.

According to a second aspect of the present invention, a system and method are provided that can transparently recover from a failure of a gateway node to provide an uninterrupted service to a client. According to this method, each node in the cluster or VEC copies and holds a portion of the state information held by the gateway. If an error occurs in the gateway, this status information is sent to the backup gateway.

In a preferred embodiment, the EC may look like (1) a single VEC (single IP address for all remote clients) or (2) multiple VECs (ie, multiple short IP addresses). The TCP-CR node owns these multiple IP addresses and receives all TCP-CR connection requests for them. Each IP address is associated with a VEC. TCP-CR distributes new TCP connections for each VEC internal hosts according to the weight associated with the VEC. TCP-CR supports dynamic configuration, allowing dynamic definition of VECs, dynamic configuration of weights associated with VECs, and automatic or manual management of VECs (ie, the addition or removal of hosts, services, etc.). Is allowed. This solution makes it possible to add or remove server hosts with respect to dynamic configuration, but without causing problems with server names stored on the network.

1 illustrates a conventional encapsulated cluster system.

2 illustrates a conventional message switch.

3 illustrates a virtually encapsulated cluster system in accordance with one embodiment of the present invention.

4 illustrates a virtually encapsulated cluster system according to another embodiment of the invention.

5 is a detailed view of the executor of FIGS. 3 and 4;

FIG. 6 is a detailed view of the manager of FIGS. 3 and 4.

7A-7C are flowcharts of an executive

8 illustrates a data structure of an executive

9 is a flowchart of a manager

10 illustrates a cluster with a high efficiency gateway in accordance with one embodiment of the present invention.

Explanation of symbols on the main parts of the drawings

105 to 108: computer node 109: gateway

110: interconnect 130: remote host

300: TCP connection router 310: VEC router

320: manager 340: executor

Introduction

The virtual encapsulated cluster system of the present invention is an implementation of the system disclosed in US Pat. No. 5,371,852. US Patent No. 5,371,852, filed Oct. 14, 1992, S / N 960,742, entitled METHOD AND APPARATUS FOR MAKING A CLUSTER OF COMPUTERS AS A SINGLE HOST ON A NETWORK, is hereby incorporated by reference herein. It is incorporated by reference in its entirety. 1 illustrates one embodiment of an encapsulated cluster of US Pat. No. 5,371,852. Like the system of US Pat. No. 5,371,852, the system of the present invention routes TCP information across the boundary of a computer cluster. This information is in the form of a port type message. Incoming messages are routed, and the server responds with each cluster looking like a computer to the foreign host. In the system of the present invention, one cluster is divided into a plurality of virtual clusters (virtually encapsulated clusters). Each of the virtual encapsulated clusters looks like a single host to other hosts outside of the cluster on the network. The messages are routed to the members of each virtual encapsulated cluster, ensuring that the load is balanced among a set of cluster nodes.

3 illustrates an embodiment of a TCP-based protocol connection router, that is, a TCP-connection router (TCP-CR) 300. The apparatus includes two or more computer nodes 105-109 connected to each other by a communication link called interconnect 110 to form a cluster. (Note that in one embodiment of the present invention the interconnect may be a network.) One of the computers in the cluster acts as a gateway 109, one over another communication link called the network 120. It is connected to the above external computer or cluster (ie hosts). The gateway may be connected to one or more networks, and one or more nodes in the cluster may be gateways. Each gateway connection, or boundary, to the network may have multiple addresses on the network. Each gateway has a TCP connection router (TCP-CR), which has a manager 320, an executor 340, and an optional recovery manager (see FIG. 10). It consists of. The manager controls routing by sending command requests 344 to the executioner and evaluating the responses 346. The implementer consists of a message switch 140 and a VEC router 310 similar to that disclosed in US Pat. No. 5,371,852.

4 illustrates another embodiment of the present invention. As in the case of the preferred embodiment described above, the nodes 107 of the cluster communicate their responses directly to the client 130. However, in another embodiment of the present invention, there is no dedicated interconnect 110 as shown in FIG. 3, and all cluster nodes are connected by an external network 120. The TCP connection router is the same as that of the preferred embodiment described above. The illustrated request 348 goes from the client 130 to the cluster node 107 via the gateway 109 via the external network 120. The corresponding response 350 is sent straight from the node 107 to the client 130 via the external network 120.

The components of the manager 320 implement a connection allocation policy and enable dynamic configuration of the virtual encapsulated cluster. The manager monitors and evaluates the current load on the members of each encapsulated cluster through a dynamic feedback control loop. By implementing a connection allocation policy, the manager intelligently distributes incoming connections across virtually encapsulated cluster servers, increasing the speed of service for client requests. New weight assignments are calculated through a manager algorithm that can be configured by cluster administrators. The input of the decision algorithm for this weighting assignment includes the evaluated load metric and parameters configurable by the administrator (eg, time threshold). Incoming connections are dynamically allocated for each VEC based on the inputs so that cluster resources are allocated to provide the fastest service to the client. The manager also includes a command interface used by the manager to dynamically construct virtual encapsulated clusters. A more detailed description of the manager is provided in section 3.

If TCP connection router node 109 is to stop working, all nodes in the cluster will be unable to provide services to their remote clients. In order to deal with this problem, in this specification, a recovery manager is added to enable a designated backup gateway when an error occurs in a gateway in operation, and the server node retains recovery data. The client does not need to do anything to recover from the gateway's failure, and continues to receive service from the cluster without interruption. A more detailed description of the recovery manager is provided in Section 4.

2. Executor

5 illustrates a preferred embodiment of the performer 340. The performer consists of a command processor 540, a message switch 140, and a VEC router 310. The command processor 540 receives a request for the executor 340 and returns a response 346. The command processor interacts with the message switch 140 and the VEC router 310 to fulfill the request and construct the response. The command processor may change one of the connection table 510, the VEC table 550, the port table 520, and the server table 530. The message switch 140 and the connection table 510 are the same as those disclosed in US Pat. No. 5,371,852. In a preferred embodiment of the present invention, the VEC router 310 does not change the incoming packet. Packets are sent to the server, where the server is configured to send responses directly to the client via an internal node.

The message switch 140 is essentially the same as the message switch disclosed in US Pat. No. 5,371,852. However, the present invention optimizes the message switch of the preferred embodiment of the present invention and further checks are made on the message switch. In other words, this message switch must check that the message is for a VEC known to the VEC router.

VEC routers have a set of addresses representing each VEC to clients on the external network. The VEC router sends requests to the internal nodes of the cluster without modifying the received request. Each internal node of the cluster is associated with one or more VECs and only receives requests for related VECs. Using techniques well known in the art, the present invention is configured to allow internal nodes to receive packets sent to addresses representing the VEC and respond directly to the client. In the prior art, the message switch 140 had to rewrite the packet header for an incoming request (see reference numeral 140 in FIG. 1) and in response to the request (see reference numeral 120 in FIG. 1). We also had to rewrite the packet header. In the present invention, it is not necessary to rewrite the packet header. (Prior art can be used with the technology of the present invention.) The performance of the present invention is better than the prior art, because the packet header is not rewritten and the response packet is sent through the gateway node 109. Because it is not. Since the response packet is not sent through the TCP connection router, the message switch does not receive any response packet from the node inside the cluster. As a result, in the present preferred embodiment, header rewriting is excluded, and inspection of response packets from internal nodes is also excluded.

The direct result of this improvement is that the VEC router only examines the flow between the client and the internal node providing the service. This makes it difficult to have an accurate connection table. To solve this problem, the present invention utilizes two new timers that describe their connection table in detail: the stale timeout and the FIN timeout. Using these two timers and the communication flow and known timers, the connection table can be maintained accurately.

Entries in the connection table are considered to be in one of two states: ACTIVE or FIN. Each time a new connection is established, an entry in the connection table is created and placed in an active state. Each time a packet flows on a connection that has an entry in the connection table, the connection table entry is time stamped. When the VEC router detects the FIN flow from the client to the serving node, the associated connection table entry is placed in the FIN state. (Packets may continue to flow on connections that are in the FIN state.) Connection table entries can be closed and erased when the FIN timeout timer identifies that a predetermined time has elapsed since the last packet was sent from the client to the server on the connection. Become. If the client fails without sending a FIN, the connection record entry remains. The stale timeout indicates how long the user has waited since the last packet on an active conversation before the connection table entry was cleared.

7A-7C show a flowchart of the VEC router 310. In FIG. 7A, the VEC router waits for a packet (step 702). When a packet is received, the VEC router checks whether the packet is for an existing TCP connection or for a new TCP connection (step 704). If the packet is for an existing TCP connection, then it is checked whether the packet is FIN, SYN, or RST (step 708). FIN, SYN, RST are all well known packet types in the art. If the packet is not one of them, send this packet to the internal node associated with the connection (step 722). If not, then check if the packet is an RST (step 710). If the packet is an RST, the connection is reset to clear the conversation from the connection table (step 712), and the packet is sent to the internal node associated with the connection (step 722). If the packet is not an RST, the VEC router 310 checks if the packet is a SYN (step 714). If the packet is a SYN, the connection is set up to make this connection active even if the connection already exists (step 716). Next, the VEC router 310 checks if the packet is a FIN (step 718). If the packet is a FIN, the connection is placed in the FIN state (step 720). After FIN processing or if the packet was not a FIN, the packet is sent to the server associated with the connection 722 (step 722).

7B shows a flowchart in the case of a connection that does not currently exist. If the check step 704 finds that the connection does not currently exist, the VEC router first checks if this packet is a SYN (step 724). If the packet is not SYN then it is discarded (step 726). If the packet is a SYN, the connection is established (step 728), the server is selected (step 730), and the packet is sent to the selected server (step 722).

7C is a flowchart of the process of selecting a server for a new connection. In the present invention, this function is implemented by weighted routing. To discuss server selection, the internal nodes of the VEC are considered numbered from 1 to n. For example, when the VEC has seven nodes, the numbers are assigned 1, 2, 3, 4, 5, 6, 7. To discuss server selection, it is assumed that a number from 1 to the maximum allowance is given for the weights that may be applied. For example, if the maximum allowable value is 5, the applicable weights will be 5, 4, 3, 2, 1. 0 is a special value. The weights are also selected in descending order. The present invention associates a weight with each internal node that provides a particular service. At least one of the nodes will have a non-zero maximum weight, or all of the nodes will have a weight of zero.

The server selection function (step 730) first selects the number corresponding to the next highest server and the weight currently applicable (step 734). Next, it is checked if this number is too large (step 735). If this number is not so large, it is checked if the server corresponding to this number is the preferred choice (step 746). This test will be described later in detail. If the number is too large, select the first server and the next lowest weight (step 736). Thereafter, it is checked if the next lowest weight selected above is zero (step 738). If this weight is non-zero, it is used in place of the currently eligible weight, and this function checks if the current server is the preferred choice (step 746). After selecting the first server and the maximum weight, the function checks if there is another server capable of routing the packet (step 742). When all of the available nodes have a weight of zero, no server is available. If no server is available, the packet is returned without selecting a server (step 744). If there is a server available, this function checks if this is the preferred choice (step 746). Preferred selection is defined as a server having a weight greater than or equal to the current qualifying weight. If this is the preferred choice, the server is selected (step 748) and returned to the VEC router (step 750). If not, the algorithm selects the next server (step 734).

The server selection function will always terminate because the maximum weight is not zero and at least one node has the maximum weight or all nodes have a weight of zero. If there is a node with a positive weight, the function of selecting a server distributes the packet based on the ratio of the weights. For example, if one of the two nodes has a weight of 3 and the other has a weight of 2, each time a node with a weight of 2 receives two packets, the node with a weight of 3 receives three packets. Will have

8 illustrates one embodiment of a data structure used by a VEC router. The VEC table 550 includes a series of addresses corresponding to VEC addresses on the external network. In particular, all parameters related to VEC are included in this table. Each VEC is associated with a port table 520, which includes a series of ports 802 for which the VEC is serving. Each port entry 802 is associated with a stale timeout 804, a FIN timeout 806, and other unique attributes 808 depending on the port. Each related port is a subset of the VEC internal nodes that are used to provide services related to it. The node table 530 contains addresses of nodes associated with the port, current weights 822 associated with these nodes, and other information unique to the node 830. (An example of unique information per node may include counters that indicate the number of active connections, the number of connections in the FIN state, and the total number of terminated connections.) The node table 530 also includes this table. Contains the state needed for the ability to select a server to implement weighted routing for a series of nodes within. The node table includes a total number of nodes 810, a final selected node 812, a currently qualified weight 814, a maximum weight 816, and a weight bound 818. The weight limit is used to limit the change in maximum weight. No node has a weight greater than the weight limit.

3. Manager

The invention of an access router manager (i.e., manager 320) is a method and apparatus for dynamically distributing incoming connections using multiple load metrics in accordance with configurable policies. The manager provides a control loop that dynamically changes the weight of the executor 340 routing algorithm to optimize cluster resource allocation. The aim of the present invention is to improve the total throughput of the cluster and reduce the overall delay of the service request by distributing the incoming TCP connection according to the current cluster state. Therefore, the present invention describes a method of distributing connections to a server host to reduce the delay in meeting the needs while improving the utilization of the server.

6 illustrates one embodiment of a manager 320 in accordance with the present invention within a cluster 600 of five nodes 105, 106, 07, 108, and 109. Although FIG. 6 uses the network configuration of the other embodiment of FIG. 4, it is also possible to use the configuration of FIG. One of these nodes is gateway 109, which is connected to external network 120 to execute TCP connection router 300 (ie, executor 340 and manager 320). Manager 320 includes five comprehensive components: load manager (Mbuddy) 610, external control interface (Callbuddy) 620, cluster host metric manager (host monitor) 630, and forward metric generator. (FMG) 640, a user programmable metric manager (UPMM) 650.

The load manager 610 may use four different kinds of metrics, namely input metrics, host metrics, service metrics, and user metrics, to calculate the weighting function for the performer. The load manager 610 receives these metrics and other related information from the executor interface 346, the external control interface 624, the host monitor interface 634, the FMG interface 644, the UPMM interface 654. The load manager controls the weight associated with the performer routing algorithm for each VEC port server via interface 344.

The load manager 610 will periodically request the performer 340 to send the values of the internal counters associated with each server via the interface 346. For example, it will periodically ask for the value of the counter for the total number of connections established for each server. By obtaining the difference between the two counters of the servers polled at times T1 and T2, the load manager 610 can calculate the amount of change in the metric, so that the amount of change in the metric that is calculated during the time T1-T2 Indicates the number. This collection of input metrics provides an approximation for the characteristic rate of connection request for each VEC and each port service.

The host monitor 630 will periodically send information about the status of each host in the cluster to the load manager 610 via the message interface 634. Various methods are known for obtaining such state information. For example, the host monitor may use a monitoring agent 635 to execute program scripts that evaluate unique metrics based on the host. For example, the script may evaluate the current utilization level of the memory buffer for the network connection. If a metric report is not received within a policy specific threshold time, the host metric is given a predetermined value, and the manager determines that the host is inaccessible, so that the connection request is no longer sent. The host monitor 630 combines the reports of all monitoring agents and provides them to the load manager.

The transmission metric generator (FMG) 640 generates and evaluates a unique metric according to a service or a unique metric according to an application using a transmission request generated by the gateway 109 computer. This evaluation is made by generating an appropriate request for each of the cluster host servers and measuring their response delays. For example, to obtain a transmission delay metric on an HTTP server, the FMG may issue an HTTP GET / request for each HTTP server in the cluster serving a particular port (eg, port 80). Next, the FMG 640 will measure the delay incurred in servicing the HTTP request and send the metric vector to the load manager 610. If the request is not answered within a unique threshold time according to the policy, the FMG will indicate that the service node has not temporarily received a new request of a particular service type. Using this information, the manager determines that a particular host's service is temporarily unavailable, so that this type of connection request is no longer sent.

User Programmable Metric Manager (UPMM) 650 allows a user of the present invention to define any new metrics that are considered management of a connection. This metric may describe any policies that any given cluster installation wishes to enforce. For example, some policies may require that a particular cluster host cluster not receive any TCP connections for a certain time for management. The UPMM 650 communicates these policies as a metric via the interface 654 to the load manager.

Components of the external control interface 620 allow administrators to dynamically control any of the parameters of the load manager 610. The external control interface 620 allows an administrator to configure an algorithm to calculate the weight assignments implemented by the load manager. For example, an administrator may want to dynamically change the weights associated with each of the current metrics. The administrator may, for example, choose to (1) increase the weight of the host metric, (2) lower the weight of the service metric, and (3) increase the frequency of polling the performer 340 for each input metric. Components of the external control interface 620 receive manager requests via interface 622 and inform load manager 610 via interface 624.

The components of the load manager 610 are load managers that form a dynamic feedback control loop between the server and the access router gateway node. The load manager adjusts the weight of the routing algorithm of the executor 610 to allow more heavily loaded servers to receive more incoming TCP connections for their type according to the load metric. Given any set of load and policy metrics as defined above, the load manager will calculate a new associated weight for each server of each port in each VEC.

Weight assignment is calculated for each port of all VECs as follows.

(1) Calculate all aggregate metrics (AM) for all running servers.

(2) Calculate all current weight proportions (CWPs) for each running server.

(2) Calculate the value of the metric proportion (MP) for each server S with respect to each metric M (relative to the total AM).

(3) Calculate the new weight (NW) for each server. In other words,

(3a) If the server is stopped, NW is set to zero.

(3b) If the server has a fixed weight W, use the value of W as NW.

(3c) A vector NWV is calculated using Equation 1 below. At this time, each entry NWV [i] is based on a single metric M [i].

[Equation 1]

NWV [i] = AW + [(CWP-MP) / SF]

However, AW is an average weight within the current range of weights, and SF is a smoothing factor parameter.

(3d) A new weighted NW of each server is calculated using Equation 2 below.

[Equation 2]

NW = NWV [1] * W [1] + NWV [2] * W [2] +. + NWV [i] * W [i]

9 is a flowchart illustrating a method for a manager to receive a metric and calculate a weight assignment using the present invention. In block 910 the load manager waits for a message or timeout event. The decision block 920 determines the type of event that has occurred. If it is determined that it is timed out and needs to be replenished, the input metric is provided by querying the performer at block 930 to obtain a series of counter values (block 935). If at block 920 it is determined that the event is a request for parameter update, the parameter is updated (block 928). For example, an administrator may update the weight or polling period associated with any metric. If at block 920 it is determined that the event was the reception of a metric update, at 925 the metric is retrieved and internal variables are set accordingly. When a new metric arrives, at block 490 the algorithm will calculate the current rate and current weight of all the metrics. Next, at block 950, a new weighted NW will be calculated for each server node using the equation above. This block generates a new weight vector NW [i], where each server i has a weight entry. Decision block 960 determines whether the calculated new weight vector NW [i] is different from the current weight vector by any threshold function. If the new vector is different, then inform the performer of the new weight at block 970, otherwise the algorithm returns to the beginning and waits for a new event.

4. Recovery Manager

As soon as it detects that an error has occurred in the function of the gateway, the recovery manager in the designated backup gateway is activated. Error detection is described, for example, by A. Bhide et al. In A Highly Available Netwotk File Server, USENIX Conference, Winter 1991, Dallas, Texas, or F. Jahanian et al. Specification, Design and Implementation, Proceedings of the 12th Symposium of Reliable Distributed Systems, Pages 2-11, Princeton, New Jersey, October 1993, IEEE Computer Society.

The recovery manager, as disclosed in HA / NFS 4, first removes the network connection from the failed gateway, then queries all active server nodes to obtain state information from their shadow connection tables. From this information, the gateway's message switch connection table is constructed. This takeover process must be terminated within the timeout interval of TCP / IP so that existing connections are not lost. To achieve this, internal nodes implement a novel hybrid algorithm (described later) to detect when a connection is deactivated and to remove these deactivated connections from the shadow connection table inside the node, so that only active connections Allows the description of a taking-over gateway. When all functioning cluster nodes respond (assuming that a node that does not respond within a certain time is not functioning), the running recovery manager in the backup gateway receives a packet whose network interface is addressed to the cluster ip-address. Do it. This final step terminates the work required to keep the backup gateway running. The relevant static configuration data used by the manager component is retained in the form of a file shared between the primary gateway and the backup gateway and is read by the backup during acquisition.

Another obvious but unacceptable solution is to copy and retain the connection information to the backup gateway. This requires a two-phase protocol between the primary and backup gateways on each established and terminated connection, and has been ruled out as a costly implementation.

10 illustrates the configuration of an encapsulated cluster using a high efficiency gateway. The primary gateway 1050 is activated and connected to the external network 120. The designated backup gateway 1030 includes an inactive physical connection to the network 120. In addition to the regular encapsulated cluster gateway component manager 320 and the performer 340, each gateway includes a recovery manager 1020. (The primary gateway may be backed up after a failure and recovery.) Each server node 107 includes a shadow connection table 1010, which shadow active table information for the external network 120. Holds.

The message (ip packet) is directed to a specific TCP or UDP protocol port to reach the cluster gateway. Message switches inside the gateway allow message routing functions to be installed for protocol ports. For each message arriving at the relevant port, a routing function is called, responsible for selecting the port and internal node to which the message is sent. Information describing the established connection and the cluster node holding the connection is recorded in a table in the gateway, which is used by the message switch to send an incoming packet on the established connection to the correct cluster node.

Relatively static information, such as for example that the server port has installed the message switch function, is retained and other manager configuration information is held in a shared file that can be accessed by the primary gateway and backup gateway. Current connection information changes very quickly and is managed according to the techniques described herein.

Each internal node 107 maintains a shadow table 1010 of the gateway routing table for its own connection (not for another node). This shadow table is used by the node to respond to a request of an acquisition gateway from the recovery manager 1020 in the backup gateway 1030 during acquisition. This table considerably reduces the time it takes for an internal node to respond to an acquisition gateway, which means that the acquisition gateway times out in order to keep the established connection intact (ie, the time for the connection-based protocol to successfully terminate communication). This is important because it must work within.

In order to calibrate the space for the shadows held in the internal node and the entries in the connection table in the gateway, we process as follows. The connection is in one of two states: active or terminated (FIN). Connection table entries are visually checked each time they are referenced. A user configurable timer called FIN_TIME_OUT is held. This timer indicates the time after the last reference to the conversation in the FIN state to be assumed to be closed. The timer may be applied globally for a service address or port. Active close (that is, one side of the connection sends a FIN but the other side continues to be connected) means that the server can continue to send data to the client and the conversation stops at the end of the data transfer. will be. The client can actively terminate the conversation to tell the server that no request will be sent from the client. For this discussion, we will assume that the client's request is being sent through the router. This protocol works because the server continues to send data to be subsequently approved. The router, i.e., the server, will eventually acknowledge the acknowledgment and continue visually acknowledging the connection table entry. Once the server has finished sending data to the client and terminates half of the conversation, a final acknowledgment will be sent from the client to the server. After the FIN_TIME_OUT time has elapsed, the server may delete the connection entry. The second timer, STALE_TIME_OUT, is held at the gate. All connections that are active but have been inactive for longer than STALE_TIME_OUT can be dropped.

The algorithm described above (connection reconfiguration algorithm) is also executed at the inner node to correct the space for entries in the shadow of the connection table held by the inner node to support the acquisition process by the backup gateway. In this way, the number of entries in the shadow table is kept as small as possible so that the acquisition process proceeds as quickly as possible.

By default, FIN_TIME_OUT should be set to a value that is three times the minimum segment length (MSL) of TCP. The default STALE_TIME_OUT must be longer than the TCP stale timeout. A more reasonable FIN_TIME_OUT value can be estimated by considering the protocol with which the timer is associated.

When it is determined that the backup gateway should be activated as a gateway for the cluster, it is determined that an error has occurred in the primary gateway (by some means of the type which is not described herein but can be described as (5)) or By explicit management decision, the recovery manager 1020 of the backup gateway 1030 takes the following steps.

(1) Using the ip-address acquisition as described in (3), the backup gateway removes the network connection of the primary gateway. This step requires ensuring that the gateway does not accept messages from the network that are supposed to be down. Without this step, some type of error, that is, a partially failed gateway, can continue to receive messages and carry out the process, which compromises the integrity of the system.

(2) The backup gateway queries each functioning node of the cluster for the requirements of all UDP ports assigned to each node, and the TCP connection established through the primary gateway between the host and itself outside the cluster. The backup gate does this using a dedicated ip protocol. The shadow connection table held at each node allows the node to respond immediately, increasing the probability that the established connection will not time out during gate acquisition. The algorithm described above, which recognizes terminated connections and corrects the space used to support these connections, minimizes the size of the shadow connection table and reduces the time required to perform gateway acquisition.

(3) The response from each node in which the backup gateway is functioning is recorded, and the UDP port and the TCP connection of the node are set in the connection table 510 (see FIG. 5) of the performer 340 (see FIG. 10) of the backup gateway. Record it.

(4) When all the functioning cluster nodes respond (assuming that nodes that do not respond within a certain time are not functioning), the backup gateway enables its network interface to send packets addressed to the cluster ip-address. Receive. This final step completes the work required to make the backup gateway operational.

Since the present invention has been described through the preferred embodiments, various modifications or changes may be made by those skilled in the art. Accordingly, it should be understood that the above-described preferred embodiments are provided by way of example only, and are not intended to limit the present invention. It is intended that the scope of the invention only be limited by the appended claims.

According to the present invention, the TCP connection router divides each encapsulated cluster into a plurality of virtual ECs (VECs) and calls within the VEC based on current server load metrics in accordance with configurable policy. By dynamically distributing connections, it encapsulates encapsulated clusters. These access routers support dynamic configuration of clusters, allowing for transparent recovery to provide uninterrupted service for VEC clients.

Claims (13)

A method for routing an incoming message across a boundary of a cluster consisting of computer nodes connected to one or more networks, (1) searching and reading a port number and a target address in a message header of a port type message; Selecting a subset of computer nodes based on the target address; Selecting, based on the port number, a predetermined function for determining a routing destination of a message among a plurality of possible destinations in the subset, wherein the message routing destination is one of the computer nodes in the subset; ④ sending a message to the routing destination; ⑤ dynamically changing the number of subsets and at least one component belonging to the subset while the message is routed across the boundary; How to route incoming messages across the boundary of the cluster. The method of claim 1, The selection step is based on the port number and protocol identifier in the message header How to route incoming messages across the boundary of the cluster. The method of claim 1, The number of the subset is dynamically changed by the monitoring function. How to route incoming messages across the boundary of the cluster. The method of claim 1, Components of the subset are dynamically changed by the monitoring function. How to route incoming messages across the boundary of the cluster. The method of claim 3, wherein The modifying step comprises replacing members of the subset at least once and adding members to the subset How to route incoming messages across the boundary of the cluster. A gateway that consists of computer nodes and transparently routes incoming messages across a cluster connected to one or more networks, Means for searching for and reading a port number and a target address in a message header of a port type message, and selecting a subset of computer nodes based on the target address; Means for selecting a predetermined function for determining, based on the port number, a routing destination of a message among a plurality of possible destinations in the subset, wherein the message routing destination is one of the computer nodes in the subset; Means for dynamically changing the number of subsets and at least one component of the subset Gateway that transparently routes incoming messages across the cluster. The method of claim 6, The number of the subset is dynamically changed by the monitoring function. Gateway that transparently routes incoming messages across the cluster. The method of claim 7, wherein Components of the subset are dynamically changed by the monitoring function. Gateway that transparently routes incoming messages across the cluster. The method of claim 7, wherein The change is made by replacing members of the subset at least once and adding members to the subset Gateway that transparently routes incoming messages across the cluster. A method of routing an incoming message past a boundary node of a cluster consisting of computer nodes connected to one or more networks, the method comprising: ① at the boundary node, 탐색 searching for and reading the port number in the message header of a port type message; Selecting a predetermined function that determines, based on the port number, a routing destination of the message among a plurality of possible destinations, the routing destination being one of the computer nodes in the cluster; (2) detecting an error of the border node; In response to the error detection, transmitting subsets of state information from each node in the cluster to an alternate boundary node; ① at the alternate boundary node, Collecting the subsets of the state information from nodes in a cluster; Using the state information to recover the operational state of the border node prior to the failure, causing the alternate border node to distribute messages in the same manner as the border node did before the failure. doing How to route incoming messages past the edge nodes of the cluster. The method of claim 10, Searching and reading the port number and the target address in the message header of the port type message; Based on the target address, selecting a subset of computer nodes, The routing destination is selected only from the subset How to route incoming messages past the edge nodes of the cluster. In a system for recovering from a failure of a boundary node of a cluster of computer nodes, At the border node, it searches for and reads a port number in the message header of a port type message, and based on the port number, a routing destination of the message among a plurality of possible destinations—this routing destination is a computer in the cluster. Means for selecting a predetermined function of determining one of the nodes; Means for detecting an error of the border node; (3) include alternate boundary nodes, The alternate boundary node, Means for collecting subsets of state information from respective nodes in the cluster in response to the error detection; Means for restoring the operational state of the boundary node prior to the failure from the subset so that the alternate boundary node distributes the messages in the same manner as the boundary node did before the failure occurred; A system that recovers from the failure of a boundary node in a cluster. In a boundary node used in a cluster of computer nodes, Search for and read a port number from a message header of a port type message and, based on the port number, a routing destination of the message among a plurality of possible destinations, which routing destination is one of the computer nodes in the cluster. Means for selecting a predetermined function for determining Means for collecting subsets of state information from respective nodes in the cluster in response to an error of an active boundary node in the cluster; Means for restoring the operational state of the border node prior to the failure from the subset, such that the border node distributes the messages in the same manner as the active border node did before the error occurred. Perimeter node used in a cluster.