The present invention relates to a cluster system which functions as a router for transferring IP packets and a cluster member constituting the cluster system and, more particularly, to a cluster system and cluster member having a function of restoring the session state of the existing session on a cluster member newly added in place of a faulty cluster member.
Routers installed in IP networks include devices which perform processing by referring to information of an upper layer of an IP layer. Examples are a firewall device used to interrupt unauthorized access, and a VPN gateway device which terminates an IPsec tunnel. Whenever receiving a packet, these devices identify the session of an upper layer to which the received packet belongs, and perform processing (e.g., unauthorized packet discarding) corresponding to the state (stored in an internal storage unit) of the identified session and the contents of the header of the received packet, resulting in a very large processing amount. Therefore, techniques (cluster systems) which distribute the load by preparing a plurality of devices have been developed.
A technique described in Japanese Patent Laid-Open No. 2003-517221 or 2003-518338 is known as prior art of the cluster system. As shown in
All the router devices 1200 to 120n receive an IP packet (to be also simply referred to as a packet hereinafter) from an adjacent IP node 1210 to the cluster system, by multicast using a data link layer protocol. The traffic distribution filter in each of the router devices 1200 to 120n passes or discards the IP packet multicast on a data link 1220, in accordance with traffic distribution rules.
The traffic distribution rules of the traffic distribution filter in each of the router devices 1200 to 120n satisfy the following conditions.
The same packet does not pass through the traffic distribution filters in a plurality of router devices.
A packet necessarily passes through the traffic distribution filter in one of the router devices.
The master router device 1200 sets the traffic distribution rules of the traffic distribution filters in the router devices 1201 to 120n. The master router device 1200 has detected the traffic distribution rules set in the traffic distribution filters in the router devices 1201 to 120n, and sets traffic distribution rules so as to evenly distribute the loads on the router devices 1201 to 120n. Also, the master router device 1200 incorporates a traffic distribution filter which processes a packet which does not apply to the traffic distribution rules. Furthermore, the master router device 1200 generates new traffic distribution rules from the session state of the processed packet, and sets the new rules in the traffic distribution filters of the router devices 1201 to 120n. Note that if the master router device 1200 fails, one of the router devices 1201 to 120n operates as a master router device.
The session processor in each of the router devices 1201 to 120n processes and discards or transfers a packet having passed through the packet distribution filter, by referring to session processing rules and session states set in the session processor.
The master router device 1200 sets the session processing rules of the session processors in the router devices 1201 to 120n. The router devices 1200 to 120n including the master router device 1200 exchange the session states indicating their own session states. The router devices 1200 to 120n perform this session state exchange for every predetermined time, and hold the session processing rules of the other router devices and the exchanged latest session states of the other router devices. If one of the router devices 1201 to 120n fails, therefore, the master router device 1200 can determine a substitute device and hand over the processing rules and session states set in the faulty router device to the substitute device. If the master router device 1200 fails, another router device can take over the processing of the master router device 1200.
In the prior art described above, the cluster system can automatically recover from a failure in any router device constituting the system. After this automatic recovery, however, another router device takes over processing which has been performed by the router device (faulty router device) in which the failure has occurred, so the load on the other router device increases. Although automatic recovery is possible, therefore, it is unfavorable to leave the cluster system to stand in the recovered state; it is desirable to add a normally operable router device (new router device) to the cluster system to return the number of devices to the original number.
The addition of a new router device requires the session state held by the faulty router device to be restored on the new router device. In the above prior art, the master router device communicates with the new router device to restore the session state on it. Unfortunately, this raises the communication cost because control information for acknowledgement or the like must be exchanged in addition to the session state.
It is, therefore, an object of the present invention to reduce the communication cost when restoring the session state on a newly added cluster member.
To achieve the above object, a cluster system according to the present invention is characterized by comprising a cluster member which performs current processing and a cluster member which performs spare processing for each of a plurality of partial ranges obtained by dividing a total range of traffics to be processed, wherein the cluster member which performs spare processing comprises session state holding means for holding a session state of a session to which a received packet belongs, session-dependent processing means for storing, in the session state holding means, a session state of a session to which a packet received in a partial range within which the cluster member performs spare processing belongs, if the session state of the session to which the packet belongs is not held in the session state holding means and the packet is a normal packet, and taking-over control means for allowing, if another cluster member which performs current processing in the partial range has failed, the session-dependent processing means to take over the processing which has been performed by the other cluster member by using the session state held in the session state holding means.
A cluster member according to the present invention is characterized by comprising session state holding means for holding a session state of a session to which a received packet belongs, session-dependent processing means for storing, in the session state holding means, a session state of a session to which a packet received in a partial range within which the cluster member performs spare processing belongs, if the session state of the session to which the packet belongs is not held in the session state holding means and the packet is a normal packet, and taking-over control means for allowing, if another cluster member which performs current processing in the partial range has failed, the session-dependent processing means to take over the processing which has been performed by the other cluster member by using the session state held in the session state holding means.
In the present invention, when a normal packet is received in a partial range within which a cluster member performs spare processing, the session state holding means registers the session state of a session to which the packet belongs. Accordingly, if a cluster member which performs spare processing fails or if this cluster member disappears by taking over to current processing, the session state can be restored on a newly added cluster member which operates instead of the faulty or disappeared cluster member, without exchanging any control information for acknowledgement or the like. Therefore, the communication cost for restoring the session state can be reduced.
Embodiments of the present invention will be explained in detail below with reference to the accompanying drawings.
The first embodiment of the present invention will be explained below. As shown in
A common cluster IP address “C” is allocated to the cluster members 1-1 to 1-n. The adjacent IP nodes 2-1 to 2-m detect the cluster system 1 as a single IP node having the cluster IP address “C”.
Also, a common cluster multicast MAC address “M” is allocated to the cluster members 1-1 to 1-n. The cluster system is preset to allow all the cluster members 1-1 to 1-n to receive a packet sent to the cluster multicast MAC address “M”.
Furthermore, individual IP addresses “c1” to “cn” are allocated to the cluster members 1-1 to 1-n, respectively. These IP addresses are used in, e.g., communications between the cluster members 1-1 to 1-nm.
The ranges of current processing and spare processing performed by the cluster members 1-1 to 1-n will be explained below with reference to
Note that it is desirable to determine the partial ranges T1 to Tn so as to equalize the loads on (equalize the numbers of packets to be processed by) the cluster members 1-1 to 1-n. An example is as follows. A commutative operation (e.g., addition or multiplication) is performed for the IP source address and IP destination address of a packet, and the operation result is divided by the number “n” of cluster members. Packets whose remainders are “0” to “n−1” are regarded as packets which belong to the partial ranges T1 to Tn, respectively.
Note also that the cluster members 1-1 to 1-n perform current processing and spare processing within the ranges shown in
mf1∪mf2∪ . . . ∪mfn=T (1)
mf1∩mf2∩ . . . ∩mfn=φ (2)
bf1∪bf2∪ . . . ∪bfn=T (3)
bf1∩bf2∩ . . . ∩bfn=φ (4)
bfi∩mfi=φ (5)
Although one cluster member performs current processing and spare processing in different partial ranges in this embodiment, one cluster member can also perform current processing or spare processing in one partial range. In this case, the number of cluster members must be twice that of partial ranges.
An example of the arrangement of the cluster member 1-1 will be explained below with reference to
The interface units 11-1 to 11-m connect to the data links 3-1 to 3-m, and transmit and receive packets and the like.
The current processing packet filter 12 has a function of transferring, to the session processor 15, packets in the partial range within which the cluster member 1-1 performs current processing, from packets and the like input from the interface units 11-1 to 11-m, and transferring other packets to the spare processing packet filter 13.
The spare packet filter 13 has a function of transferring, to the session processor 15, packets in the partial range within which the cluster member 1-1 performs spare processing, from the packets and the like transferred from the current processing packet filter 12, and outputting other packets to the session state holding unit 16 and health watchdog unit 20.
The session processor 15 performs the following processing when receiving packets from the current processing packet filter 12 and spare processing packet filter 13.
The session processor 15 identifies a session to which the packet belongs. This is the function of a session identification unit 151 shown in
If the packet is a session establishment packet (e.g., a SYN packet of TCP), the session processor 15 registers, in the session state holding unit 18, the session identifier and session state of the session to which the packet belongs such that the session identifier and session state correspond to each other. This is the function of a session state storage 152 shown in
If the packet is an unauthorized packet, the session processor 15 discards the packet, and notifies the session state synchronization unit 16 of the session identifier of the session to which this unauthorized packet belongs. This is the function of an unauthorized packet processor 153 shown in
If the packet is a normal packet of the existing session, the session processor 15 updates the session state held in the session state holding unit 18, and transfers the packet to the route controller 22. This is the function of a session state updating unit 154 shown in
The session processor 15 identifies a session to which the packet belongs. This is the function of the session identification unit 151 shown in
If the packet is a session establishment packet, the session processor 15 registers, in the session state holding unit 18, the session identifier and session state of the session to which the packet belongs such that the session identifier and session state correspond to each other. After that, the session processor 15 discards the packet. This is the function of the session state storage 152 shown in
If the packet belongs to the existing session, the session processor 15 updates the corresponding session state registered in the session state holding unit 18, and discards the packet. This is the function of the session state updating unit 154 shown in
If the packet does not belong to the existing session, the session processor 15 registers, in the session state holding unit 18, the session identifier, session state, and hold flag (hold identifier) of the session to which the packet belongs such that the session identifier, session state, and hold flag correspond to each other, instructs the session monitoring timer unit 17 to set a session monitoring timer for the session, and discards the packet. This is the function of the session state storage 152 shown in
A session herein mentioned indicates a virtual communication path provided by an IP extension protocol and upper layer protocol, and includes, e.g., a TCP connection and IPsec Security Association. A session state indicates information uniquely held for each session, and includes, e.g., the connection state, sequence number, and response number in the case of TCP connection. In the case of IPsec SA, the session state includes SA parameters defined by RFC2401.
If an error which may cause the cluster member 1-1 to overlook a packet occurs in the cluster member 1-1, an error detecting means (not shown) sets error flag=“1” in an error flag 24.
The session state synchronization unit 16 has the following functions.
When receiving the session identifier of a session to which a discarded packet belongs from the session processor 15, the session state synchronization unit 16 transmits a transfer rejection notification containing the session identifier and the value of the error flag 24 to a cluster member (to be also referred to as a paired spare cluster member hereinafter) which performs spare processing in the partial range within which the cluster member 1-1 performs current processing, and updates the error flag 24 to “0”. This is the function of a transfer rejection notification transmitter 161 shown in
The session state synchronization unit 16 transmits, for every predetermined time, a transfer rejection notification (which contains no session identifier and will be also referred to as an empty transfer rejection notification hereinafter) containing the value of the error flag 24 to the paired spare cluster member, and updates the error flag 24 to “0”. This is the function of an empty transfer rejection notification transmitter 162 shown in
When receiving a transfer rejection notification from a cluster member (to be also referred to as a paired current cluster member hereinafter) which performs current processing in the partial range within which the cluster member 1-1 performs spare processing, if an error flag contained in the notification is “1”, the session state synchronization unit 16 deletes the session state of a session specified by a session identifier contained in the transfer rejection notification, from the session states held in the session state holding unit 18. If the error flag is “0”, the session state synchronization unit 16 deletes the session state of the session specified by the session identifier contained in the transfer rejection notification, from the session states held in the session state holding unit 18, and also deletes the hold flag of a session state regarded as a hold flag delete candidate. In addition, the session state synchronization unit 16 holds, as a hold flag delete candidate, the session identifier of a session state to which a hold flag is attached. These are the functions of a session state deleting unit 163 and hold flag deleting unit 164 shown in
The session monitoring timer unit 17 has a function of measuring a time from the time when a session state is registered in the session state holding unit 18, and deleting, from the session state holding unit 18, a session state to which a hold flag is kept attached for a predetermined time or more (i.e., the session state of a session corresponding to a timed-out session monitoring timer).
The redundant configuration information holding unit 19 stores the IP addresses of cluster members (a paired current cluster member and paired spare cluster member) having configurations redundant to the cluster member 1-1.
The health watchdog timer unit 21 has two health watchdog timers, i.e., a paired spare cluster member health watchdog timer (not shown) and paired current cluster member health watchdog timer (not shown).
The health watchdog unit 20 has the following functions.
At each member notice transmission timing, the health watchdog unit 20 transmits a member notice to the paired spare cluster member and paired current cluster member. This is the function of a member notice transmitter 201 shown in
When receiving a member notice from the paired spare cluster member or paired current cluster member, the health watchdog unit 20 instructs the health watchdog timer unit 21 to reset the corresponding health watchdog timer. This is the function of a timer reset unit 202 shown in
When the paired current cluster member health watchdog timer has timed out, the health watchdog unit 20 notifies the session processor 15 that the spare processing packet filter 13 has switched to the current processing packet filter. That is, if the paired current cluster member has failed, the health watchdog unit 20 allows the session processor 15 to take over the processing which has been performed by the paired current cluster member, by using the session state held in the session state holding unit 18. This is the function of a taking-over controller 203 shown in
When the paired spare cluster member health watchdog timer has timed out, the health watchdog unit 20 notifies the system manager of the information. This is the function of a manager notification unit 204 shown in
The route controller 22 has a function of determining an interface unit to output a packet on the basis of the destination of a packet transferred from the session processor 15 and the contents of the routing table 23, and transferring the packet to the next hop via the interface unit.
Note that the cluster member 1-1 can be implemented by a computer and is implemented by a computer as follows. A disk, semiconductor memory, or another recording medium recording a cluster member program is prepared. A computer reads out the program to control its own operation, thereby implementing the interface units 11-1 to 11-m, current processing packet filter 12, spare processing packet filter 13, session-dependent processor 14, session monitoring timer unit 17, health watchdog unit 20, health watchdog timer unit 21, and route controller 22 on the computer.
The operation of this embodiment will be explained in detail below.
First, the relationship between the cluster system 1 and adjacent IP nodes 2-1 to 2-m will be explained with reference to
The operation of each of the cluster members 1-1 to 1-n in the cluster system 1 will be explained below. Note that the operations of the cluster members 1-1 to 1-n are the same, so the operation of a cluster member 1-i (1≦i≦n) will be explained as an example.
When receiving a packet (a packet from the adjacent IP nodes 2-1 to 2-m or a member notice or transfer rejection notification from the cluster members 1-2 to 1-n) via the interface units 11-1 to 11-n, the current processing packet filter 12 in the cluster member 1-i checks whether the packet belongs to a partial range within which the cluster member 1-i performs current processing. The current processing packet filter 12 transfers the packet to the session processor 15 if the packet belongs to the partial range, and transfers the packet to the spare processing packet filter 13 if the packet does not belong to the partial range.
When receiving the packet from the current processing packet filter 12, the spare processing packet filter 13 checks whether the packet belongs to a partial range within which the cluster member 1-i performs spare processing. The spare processing packet filter 13 transfers the packet to the session processor 15 if the packet belongs to the partial range, and outputs the packet (member notice or transfer rejection notification) to the session state synchronization unit 16 and health watchdog unit 20 if the packet does not belong to the partial range.
When receiving the packet from the current processing packet filter 12 or spare processing packet filter 13, the session processor 15 executes processing indicated by a flowchart shown in
First, the operation when the session processor 15 has received the packet via the current processing packet filter 12 will be explained below with reference to
When receiving the packet via the current processing packet filter 12, the session processor 15 first identifies a session to which the packet belongs (step S41 in
If the packet is a session establishment packet (YES in step S42), the session processor 15 registers, in the session state holding unit 18, the session identifier of the session identified in step S41 and the session state of the session such that the session identifier and session state correspond to each other, and transfers the session establishment packet to the route controller 22 (steps S43 and S48). On the other hand, if the packet is not a session establishment packet (NO in step S42), the session processor 15 checks whether the packet is an unauthorized packet on the basis of header information of the packet and the session state of the corresponding session held in the session state holding unit 18 (step S44). Examples of the unauthorized packet are a packet whose session state is not held in the session state holding unit 18, and a packet whose header contents (header information) conflict with the session state held in the session state holding unit 18. Examples of the header information are the IP addresses of the destination and transmission source of the packet, and the port numbers of the destination and transmission source contained in the header of an upper layer (TCP or UDP).
If the session processor 15 determines that the packet is not an unauthorized packet but a normal packet (NO in step S44), the session processor 15 updates the corresponding session state registered in the session state holding unit 18 in accordance with the contents of the header of the input packet, and transfers the packet to the route controller 22 (steps S47 and S48). When receiving the packet, the route controller 22 determines an interface unit to output a packet on the basis the destination of the packet and the contents of the routing table 23, and transfers the packet to the next hop via the interface unit.
On the other hand, if the session processor 15 determines that the packet is an unauthorized packet (YES in step S44), the session processor 15 discards the packet and transfers the session identifier of the session to which the discarded packet belongs to the session state synchronization unit 16 (steps S45 and S46).
When receiving the session identifier from the session processor 15, the session state synchronization unit 16 first refers to the error flag 24 as shown in a flowchart of
The session state synchronization unit 16 transmits a transfer rejection notification to the paired spare cluster member not only when receiving the session identifier of the session to which the discarded packet belongs from the session processor 15, but also whenever a predetermined time elapses. Referring to
The operation when the session processor 15 has received the packet via the spare processing packet filter 13 will be explained below with reference to
When receiving the packet via the spare processing packet filter 13, the session processor 15 first identifies a session to which the packet belongs (step S51 in
If the packet is a session establishment packet (YES in step S52), the session processor 15 registers, in the session state holding unit 18, the session identifier of the session identified in step S51 and the session state of the session such that the session identifier and session state correspond to each other, and discards the packet (steps S53 and S58). On the other hand, if the packet is not a session establishment packet (NO in step S52), the session processor 15 checks whether the packet belongs to the existing session (step S54).
If the packet belongs to the existing session (YES in step S54), the session processor 15 updates the corresponding session state registered in the session state holding unit 18, and discards the packet (steps S55 and S58).
On the other hand, if the packet does not belong to the existing session (NO in step S54), the session processor 15 registers, in the session state holding unit 18, the session identifier of the session identified in step S51, the session state of the session, and the hold flag such that the session identifier, session state, and hold flag correspond to each other (step S56), instructs the session monitoring timer unit 17 to set a session monitoring timer for the session (step S57), and discards the packet (step S58).
In accordance with the instruction from the session processor 15, the session monitoring timer unit 17 sets the session monitoring timer (not shown) for the designated session. The session monitoring timer unit 17 also performs a session monitoring timer monitoring process shown in a flowchart of
The foregoing are the operations of the cluster member 1-i when the session processor 15 has received packets via the current processing packet filter 12 and spare processing packet filter 13.
When the cluster members 1-1 to 1-n execute the above operations, two cluster members which perform current processing and spare processing in the same partial range hold the same session state.
Processing performed by the cluster members 1-1 to 1-n to detect and restore failures of the paired spare cluster member and paired current cluster member will be explained below. This processing will be explained by taking the operation of the cluster member 1-i as an example.
As shown in a flowchart of
The member notice received by the cluster member 1-i from another cluster member enters the health watchdog unit 20 via the current processing packet filter 12 and spare processing packet filter 13. If the transmission source of the input member notice is the paired current cluster member or paired spare cluster member, the health watchdog unit 20 instructs the health watchdog timer unit 21 to reset the corresponding health watchdog timer as shown in a flowchart of
The health watchdog unit 20 also performs a health watchdog timer monitoring process shown in a flowchart of
Referring to
In this embodiment, if one cluster member fails, no cluster members perform spare processing an longer in two partial ranges. That is, no cluster members perform spare processing any longer in a partial range within which the faulty cluster member has performed spare processing and in a partial range within which the faulty cluster member has performed current processing.
For example, if the cluster member 1-2 fails in the cluster system 1 while the cluster members 1-1, 1-2, . . . , 1-n perform current processing (indicated by the solid-line arrows) in the partial ranges T1, T2, . . . , Tn and spare processing (indicated by the broken-line arrows) in the partial ranges T2, T3, . . . , T1 as shown in
In this case, as shown in
The operation when the new cluster member 1-2a is added instead of the faulty cluster member 1-2 will be explained below.
If a packet input to the added cluster member 1-2a belongs to the partial range T2 within which the cluster member 1-2a performs current processing, this packet is input to the session processor 15 via the current processing packet filter 12. If the packet belongs to the partial range T3 within which the cluster member 1-2a performs spare processing, the packet is input to the session processor 15 via the spare processing packet filter 13. If the packet does not belong to either partial range, it is input to the session state synchronization unit 16 and health watchdog unit 20.
The session processor 15 executes the processing shown in the flowchart of
If the packet input via the spare processing packet filter 13 dos not belong to the existing session, i.e., if the packet belongs to a session whose session state is not held in the session state holding unit 18 (NO in step S54 of
The session state of the session to which the packet belongs is thus registered in the session state holding unit 18 by attaching the hold flag for the reason explained below. That is, the cluster member 1-3 which performs current processing in the partial range T3 may have processed the packet as a normal packet which belongs to the existing session. If the packet is a normal packet which belongs to the existing session, processing shown in a flowchart of
When receiving, via the spare processing packet filter 13, a transfer rejection notification transmitted if the paired current cluster member (in this case, the cluster member 1-3) detects an unauthorized packet, the session state synchronization unit 16 in the cluster member 1-2a performs the processing shown in the flowchart of
If the error flag is “0”, i.e., if the cluster member 1-3 is normally operating (NO in step S131), the session state synchronization unit 16 deletes a session state specified by a session identifier in the transfer rejection notification, from the session states held in the session state holding unit 18 (step S133). This step deletes the session state concerning the unauthorized packet from the session state holding unit 18.
In this embodiment, the session state synchronization unit 16 regards a packet received by the cluster member 1-2a before this unauthorized packet as a normal packet in principle, and deletes a hold flag from the session state of a session to which the packet regarded as a normal packet belongs. In this case, the session state synchronization unit 16 regards, as a hold flag delete candidate, a session state with a hold flag held in the session state holding unit 18 after processing when the last transfer rejection notification is received, and deletes the hold flag of this session state as a candidate upon reception of the current transfer rejection notification (step S134).
Also, the session state synchronization unit 16 holds the session identifier of a session state with a hold flag, as a hold flag delete candidate, of the session states held in the session state holding unit 18 (step S135). Since this processing is performed, therefore, even if the session monitoring timer times out after that, the session state of a session to which a normal packet belongs is not deleted from the session state holding unit 18 because the hold flag is deleted from the session state.
If, however, the paired current cluster member 1-3 has overlooked an unauthorized packet and does not notify the cluster member 1-2a of the existence of this unauthorized packet by a transfer rejection notification, a hold flag is deleted from a session state pertaining to the unauthorized packet held in the cluster member 1-2a in response to a transfer rejection notification transmitted when the paired current cluster member 1-3 detects an unauthorized packet for the next time, so this session state is kept held.
To prevent this, if an error flag contained in a transfer rejection notification is “1”, i.e., if an error which may cause the paired current cluster member 1-3 to overlook a packet has occurred (YES in step S131), this embodiment performs only the process of deleting, from the session state holding unit 18, the session state of a session specified by a session identifier in the transfer rejection notification (step S132), and does not perform the processing after hold flag deletion. Even if the paired current cluster member 1-3 has overlooked an unauthorized packet, therefore, when the unauthorized packet is detected after that, the session state of this unauthorized packet can be deleted from the session state holding unit 18 of the cluster member 1-2a. Note that the session state synchronization units 16 in the other cluster members also perform the processing shown in the flowchart of
In this embodiment as described above, the paired current cluster member 1-3 transmits a transfer rejection notification when detecting an unauthorized packet, and the cluster member 1-2a deletes a hold flag from the session state of a normal packet. Accordingly, this method keeps attaching a hold flag to the session state of a normal packet if no unauthorized packet is sent to at least the paired current cluster member 1-3. In addition, when the number of packets to be transferred by the paired current cluster member 1-3 increases, the possibility of packet overlooking rises, so an error flag contained in a transfer rejection notification is “1” even if an unauthorized packet is sent, and this makes it impossible to delete a hold flag. However, a hold flag is desirably deleted within as short a time as possible. This is so because if the paired current cluster member 1-3 fails and the cluster member 1-2a takes over the processing, all session states with hold flags must be discarded since the validity of any of these session states cannot be determined.
In this embodiment as described above, therefore, the paired current cluster member 1-3 periodically transmits an empty transfer rejection notification containing no session state identifier. If an error flag is “0” (YES in step S131), the cluster member 1-2a having received this empty transfer rejection notification deletes a hold flag attached to a session state as a hold flag delete candidate, and designates the next hold flag delete candidate, without performing the session state deleting process (steps S134 and S135). This improves the state in which a hold flag is kept attached for a long time.
The above processing allows the cluster member 1-2a to restore the session state concerning the partial range T3 and held by the cluster member 1-3 when a packet of the session is actually transferred.
The second embodiment of the present invention will be explained below. This embodiment is characterized by making a transfer rejection notification unnecessary.
The differences of a cluster member 1-1a used in this embodiment shown in
The differences of the session-dependent processor 14a from the session-dependent processor 14 are that the session-dependent processor 14a comprises a session processor 15a instead of the session processor 15, additionally has a data link monitoring unit 25, and does not comprise the session state synchronization unit 16.
Note that the cluster member 1-1a can be implemented by a computer and is implemented by a computer as follows. A disk, semiconductor memory, or another recording medium recording a cluster member program is prepared. A computer reads out the program to control its own operation, thereby implementing interface units 11-1 to 11-m, a current processing packet filter 12, a spare processing packet filter 13, the session-dependent processor 14a, the session monitoring timer unit 17a, a health watchdog unit 20, a health watchdog timer unit 21, and a route controller 22 on the computer.
The operation of this embodiment will be explained below. In this embodiment, only the differences from the first embodiment described above will be explained.
The session processor 15a performs processing shown in a flowchart of
The flowchart shown in
The flowchart shown in
The data link monitoring unit 25 monitors a data link on the transmitting side. When detecting a packet having a packet identifier transferred from the session processor 15a (when a packet is transferred to the next hop), the data link monitoring unit 25 deletes a session monitoring timer for a session to which the packet belongs (this stops the time measurement by the session monitoring timer unit 17a), and deletes a hold flag from the session state of the session held in the session state holding unit 18. If the data link monitoring unit 25 is unable to detect a packet having the packet identifier, a session monitoring timer set in the session monitoring timer unit 17a and corresponding to a session to which the packet belongs times out, thereby deleting the session state of the session held in the session state holding unit 18.
The cluster member of this embodiment performs the above processing. When a new cluster member is added in place of a faulty cluster member, therefore, the same session state as a session state concerning a partial range within which the new cluster member performs spare processing, and held in a cluster member (paired current cluster member) which performs current processing, can be restored on the new cluster member. Unlike in the first embodiment, this embodiment obviates the need to transmit any transfer rejection notification from the paired current cluster member to the new cluster member, thereby further reducing the communication cost.
Number | Date | Country | Kind |
---|---|---|---|
120235/2004 | Apr 2004 | JP | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/JP05/07310 | 4/15/2005 | WO | 10/6/2006 |