Stateful firewall clustering for processing-intensive network applications

BACKGROUND

0001The present invention relates to the field of digital communications, clustering and high availability.

0002The evolution over the past 20 years of digital communications technology has resulted in the current distributed client-server data networks. In these distributed client-server networks, multiple clients are able to access and share data stored on servers located at various points or nodes through a given network. In the case of the Internet, a client computer is able to access data stored on a server located at any point on the planet, as long as the server is also connected to the Internet.

0003With the rapid proliferation in use of distributed data networks, such as the Internet, more and more clients from around the world are attempting to connect to and extract data stored on a finite number of servers. Those establishing and maintaining the servers containing the desired data, such as web pages from popular web sites, are finding it difficult to insure that all the clients attempting to access data will be able to do so.

0004One way to insure that the network servers will have enough resources to process all connection requests is to deploy multiple mirrored servers in conjunction with a load balancer. The mirrored servers are typically connected to the same network and are referred to as a server cluster. When a client attempts to connect to and access data from a server cluster, the client's request is first received by the load balancer which determines which of the servers is best suited to handle the client's request.

0005There are several known clustering technologies. For example, one clustering technology is referred to as a “stateless failure recovery” clustering. In this type of clustering, in case of a hardware failure, a standby system takes over the tasks of the active failed system. For example, a simple master-slave system with a short failover time (hot standby) would fulfill this requirement. Unfortunately, such a system may not be able to recover the previously established connections after a failover.

0006Another type of clustering is referred to as a “stateful failure recovery.” In this type of clustering, in case of a system failure, the existing packet or filter connections are not lost. Unfortunately, the stateful failure recovery system requires the cluster applications to be written in a specific way, commonly referred to as “HA-aware.” Furthermore, the effort of re-writing applications to support HA is quite high.

0007The major drawback of the existing load balancing solutions is that they all require additional hardware, such as load balancers. Additional hardware introduces a set of complications related to performance, synchronization and network address translation.

0008Accordingly, there is a need to provide a stateful clustering technology that can balance network traffic between multiple servers without the help of a dedicated load balancer.

SUMMARY

0009In accordance with implementations of the invention, one or more of the following capabilities may be provided. The present invention provides a method and apparatus for a stateful clustering technology that, in some embodiments, can balance network traffic between multiple servers without the help of a dedicated load balancer. The present invention can preserve the state of the balanced network packets by transmitting the packet state information with each network packet.

0010These and other capabilities of the invention, along with the invention itself, will be more fully understood after a review of the following figures, detailed description, and claims.

0011Some embodiments hereof provide a method for balancing network traffic, including the steps of receiving data packets at a master node, applying a set of conditions to determine one or more slave nodes for processing the data packets, forwarding the data packets and a filter state information to the determined slave nodes for processing, receiving the processed data packets and the filter state information from the slave nodes; and outputting the data packets from the master node.

0012Other embodiments are directed to a system for balancing network traffic including a master node addressable by an external device, at least one slave node addressable by the master node, at least one filter running on the master node and the at least one slave node, a clusterware application running on the master node and the at least one slave node, wherein the clusterware application is configured to distribute the network traffic between the master node and the at least one slave node. In some embodiments, the clusterware application running on the master node monitors and maintains a list of slave nodes. In some embodiments, the list of slave nodes is maintained in RAM. In yet other embodiments, the list of slave nodes is saved on the disk storage. In still other embodiments, the list of slave nodes is saved in the database file.

0013According to some embodiments, in case of the master node's failure, the clusterware application running on the slave nodes selects a new master. In other embodiments, the new master is selected from the slave nodes based on the hardware configuration of the slave nodes. In other embodiments, the slave nodes are addressable by the master node using a separate synchronization interface. In some embodiments each synchronization interface of the slave nodes is uniquely identified by the MAC and IP address.

0014In addition, some embodiments are directed to a file synchronization between the master node and the slave nodes is implemented using a dedicated file synchronization software. In some embodiments, the dedicated file synchronization software is Csync2. In other embodiments, the synchronization between applications running on the master node and the slave nodes is handled by the applications. In other embodiments, the synchronization between the applications is implemented using the remote procedure calls (RPC). In yet other embodiments, the system is configured using the graphical user interface application running on the master node. Still, in other embodiments, the master and the slave nodes monitor each other. In yet other embodiments, the network is distributed for firewall network processing. In other embodiments, the firewall network processing includes encryption of the network traffic. In yet other embodiments, the firewall network process includes decryption of the network traffic. And in other embodiments, the firewall network processing includes the virus scanning of the network traffic.

BRIEF DESCRIPTION OF THE DRAWINGS

0015<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary embodiment of a load balancing system according to the present invention;

0016<figref idref="DRAWINGS">FIG. 2</figref> illustrates a flowchart of a process that can be implemented by one of the software components, according to an exemplary embodiment of the present invention that can route data packets within a cluster; and

0017<figref idref="DRAWINGS">FIG. 3</figref> shows an exemplary network topology having a stateful clustering system that may be used to shield a private network from security threats from the Internet.

DETAILED DESCRIPTION

0018Embodiments of the invention provide techniques for load balancing network traffic. The embodiments presented in this disclosure are exemplary, however, and not limiting of the invention as other implementations are possible.

0019Referring to <figref idref="DRAWINGS">FIG. 1</figref>, a clustering system <b>10</b> according to the present invention includes a master node server <b>100</b> and a slave node server <b>150</b> that can communicate over a network connection. The master node <b>100</b> and the slave node <b>150</b> are computing devices. Generally, each of the master node <b>100</b> and the slave node <b>150</b> can include a display, motherboard, CPU (microprocessor), primary storage (RAM), expansion cards, power supply, optical disc drives, secondary storage (HD), network cards and other computer components, for example. In <figref idref="DRAWINGS">FIG. 1</figref>, a single slave node <b>150</b> is shown for illustrative purposes. However, the cluster <b>10</b> may include more than one, or many, slave nodes <b>150</b>.

0020The master node <b>100</b> is configured to include an inbound network interface <b>1</b><b>10</b>, an outbound network interface <b>120</b> and a synchronization network interface <b>140</b>. In other embodiments of the present invention, the inbound network interface <b>110</b>, the outbound network interface <b>120</b> and a synchronization network interface <b>140</b> can be combined into a single physical interface, carrying out all <b>3</b> functions. The network interfaces are generally configured to contain, for example, a network interface card (NIC), a driver that manages the NIC card and a network stack, sometimes referred to as a protocol stack. Each of the network interfaces <b>110</b>, <b>120</b> and <b>140</b> can include additional components. The master node <b>100</b> is further configured to include a clusterware software component <b>130</b>. The clusterware software <b>130</b> includes filter modules <b>131</b>, <b>132</b>, <b>133</b>, <b>134</b>. Generally, the clusterware software component <b>130</b> is a collection of instructions organized in functions, classes, modules, files, applications and dynamically linked libraries. The clusterware software component <b>130</b> can contain, for example, multiple software functions, classes, files, applications and dynamically linked libraries. Software components are sometimes referred to as modules. For example, the clusterware software component <b>130</b> interacts with the filter modules <b>131</b>, <b>132</b>, <b>133</b> and <b>134</b>. Each filter module is also a software component that can contain a collection of instructions organized as functions, classes, modules, files, applications or dynamically linked libraries, for example.

0021The master node <b>100</b> is configured to be visible to external devices. In one embodiment, the external devices may access the master node <b>100</b> using the official IP address. Preferably, the master node <b>100</b> controls other nodes within the cluster. The master node <b>100</b> may take over all primary tasks, including packet handling, cluster node control and configuration of the cluster. The master node <b>100</b> can serve as a single point of control for the whole, or portions of, the cluster. Preferably, the cluster <b>10</b> has a single master node <b>100</b> active at any time.

0022The inbound network interface <b>110</b> is configured to provide the connection point between the master node <b>100</b> and a public or private network. Preferably, the network interface <b>110</b> has a network interface card (NIC) that physically connects to the network cable. The network interface <b>110</b> also includes a driver that manages the operation of the NIC and all communications between the NIC and the processor of the master node <b>100</b>. Preferably, the interface also has the network stack that can be necessary for receiving the data sent using common network protocols. In one embodiment, the network interface <b>110</b> can be dedicated to accepting the inbound traffic. In other embodiments, the same interface can be used for the inbound, outbound and synchronization traffics.

0023The outbound network interface <b>120</b> is a connection point between the master node <b>100</b> and the public or private network. The outbound network interface may be dedicated to the outbound traffic. For example, the inbound traffic may have the data packets sent by other devices located on the public network. The packets arrive to the inbound network interface <b>110</b>. The cluster <b>10</b>, as illustrated on <figref idref="DRAWINGS">FIG. 1</figref>, processes the data packet (by scanning the contents of the file, encrypting, decrypting, etc.). The processed data packet can be output from the outbound network interface <b>120</b>.

0024The synchronization network interface <b>140</b> is configured to be used for the inter-cluster data communications. For example, the synchronization network interface <b>140</b> can be used by the master node <b>100</b> to send the received data packet to the slave node <b>150</b>. Similarly, the synchronization network interface <b>140</b> can be used by the master node <b>100</b> to receive the processed data packet from the slave node <b>150</b>.

0025The clusterware <b>130</b> is a software application configured to run on the master node <b>100</b> and manage the operations of the cluster <b>10</b>. The clusterware <b>130</b> decides how to process data packets received from the network. The clusterware <b>130</b> also decides what slave nodes <b>150</b> should be responsible for particular processing. In one embodiment, the clusterware <b>130</b> can be responsible for monitoring the state of other nodes within the cluster <b>10</b>. For example, if one of the slave nodes <b>150</b> is no longer available, the master node <b>100</b> can notify an administrator.

0026The clusterware <b>130</b> can be configured to manage a collection of filter modules <b>131</b>, <b>132</b>, <b>133</b>, <b>134</b>, running on the master node <b>100</b>. Each filter module <b>131</b>,<b>132</b>, <b>133</b>, <b>134</b> is configured to be responsible for processing data packets. For example, filter module <b>131</b> can decrypt the data packet, filter module <b>132</b> can scan the data packet for potentially dangerous information, filter module <b>133</b> can scan the data packet for viruses or filter module <b>134</b> can encrypt the data packet. Other functions are possible and envisioned.

0027The slave node <b>150</b> includes an inbound network interface <b>160</b>, an outbound network interface <b>170</b> and a synchronization network interface <b>190</b>. The network interfaces are generally configured to contain, for example, a network interface card (NIC), and a driver that manages this card and a network stack, sometimes referred to as a protocol stack. Each of the network interfaces <b>160</b>, <b>170</b> and <b>190</b> can include additional components.

0028In the embodiment of the invention depicted in <figref idref="DRAWINGS">FIG. 1</figref>, only the master node <b>100</b> can communicate with the external network. As a result, the inbound network interface <b>160</b> and the outbound network interface <b>170</b> can be inactive. However, the inbound network interface <b>160</b> and the outbound network interface <b>170</b> can have an IP address and can become operative if the slave node <b>150</b> becomes the master node <b>100</b> of the cluster. For example, if the master node <b>100</b> fails, the slave node <b>150</b> can become the new master of the cluster. To function as a master, the slave node <b>150</b> can activate the inbound network interface <b>160</b> and the outbound network interface <b>170</b>. The slave node <b>150</b> can also become a master node of the cluster in case of a software upgrade.

0029In the embodiment of the invention depicted in <figref idref="DRAWINGS">FIG. 1</figref>, the cluster nodes comprise a single master device and one or more slave nodes. Each node, preferably, has substantially the same number of interfaces and substantially the same hardware. Further, the networked cluster according to the present invention can be configured using the graphical user interface. The graphical user interface can be implemented as a software component running on the master node or on any other node within or outside of the cluster. The configuration of the cluster can be synchronized from the master to the slave nodes. For example, the cluster configuration can propagate automatically from the master node to all slave members of the cluster. In one embodiment, no extra configuration should be required for the slave members of the cluster.

0030The synchronization network interface <b>190</b> can be configured for inter-cluster data communications. For example, the synchronization network interface <b>190</b> can be used by the slave node <b>150</b> for receiving data packets from the master node <b>100</b>. Similarly, the synchronization network interface <b>190</b> can be used by the slave node <b>150</b> to send the processed data packet to the master node <b>100</b>.

0031The slave node <b>150</b> is configured to include a clusterware software component <b>180</b> that manages and interacts with the signal filter modules <b>181</b>, <b>182</b>, <b>183</b> and <b>184</b>. Each filter module is also a software component that can contain a collection of instructions organized as functions, classes, modules, files, applications or dynamically linked libraries, for example.

0032The slave node <b>150</b> can be hidden from external devices. In some embodiments, the slave node <b>150</b> can have an assigned IP address that can remain inactive. The slave node <b>150</b> does not have to provide ARP responses and can drop any directly received external packets.

0033Generally, the slave node <b>150</b> is used by the master node <b>100</b> for the CPU-intensive processing. In one embodiment, the master node <b>100</b> can use slave nodes <b>150</b> for firewall engine processing of the network packets. For example, the slave node <b>150</b> can be used for content scanning proxies for HTTP, SMTP and POP3 protocols. The slave node <b>150</b> can also be used for encryption and decryption of IPSec traffic. The slave nodes can also be used for the Snort Intrusion Protection.

0034The clusterware <b>180</b> is configured to run on the slave node <b>150</b> and perform instructions of the clusterware <b>130</b>, running on the master node <b>100</b>. For example, a clusterware <b>180</b> may receive a data packet and the packet state information from the master node <b>100</b> with the instruction to scan the data packet for viruses. The clusterware <b>180</b> is configured to redirect the data packet to the virus scanning filter module, instruct the filter module to process the packet and send the processed packet together with the packet state information back to the master node <b>100</b>.

0035The clusterware <b>180</b> is further configured for managing a collection of filter modules <b>181</b>,<b>182</b>, <b>183</b>, <b>184</b> running on the slave node <b>150</b>. Each filter module <b>181</b>, <b>182</b>, <b>183</b>, <b>184</b> can be responsible for processing data packets. For example, filter module <b>181</b> can decrypt the data packet, filter module <b>182</b> can scan the data packet for potentially dangerous information, filter module <b>183</b> can scan the data packet for viruses or filter module <b>184</b> can encrypt the data packet. Other functions are possible and envisioned.

0036With continued reference to <figref idref="DRAWINGS">FIG. 1</figref>, the cluster <b>10</b> is configured to be used for stateful firewall clustering. Stateful firewall clustering is configured to provide the benefits of using multiple servers for firewall processing of network traffic. Stateful firewall clustering also supports the high-availability of network applications. Network packets can be preserved even if one of the servers within the cluster fails. The cluster <b>10</b> is configured to balance network traffic between servers without the help of a load balancer. Specifically, the cluster <b>10</b> can balance network traffic after the network traffic arrives on a network stack of the inbound network interface <b>110</b>. The cluster <b>10</b> can support the stateful clustering because the clusterware applications <b>130</b> and <b>180</b> monitor and share the state of the data packets.

0037Network traffic is analyzed by the master node <b>100</b> and forwarded to the slave node <b>150</b> for processing various CPU-intensive tasks. For example, CPU-intensive tasks can include virus scanning, intrusion detection and IPSec decryption. The tasks can also include the Content Filter services for HTTP, POP3, SMTP, IMAP and FTP protocols, for example. In one embodiment, the filter modules can operate on various hardware based cluster nodes. The external devices that interact with the cluster <b>10</b> may not even know that the cluster <b>10</b> contains two network servers. Instead, the entire cluster <b>10</b> can be configured to operate as a single machine with a single network IP address.

0038In one embodiment, the clusterware <b>130</b> can detect the failure of one or more slave nodes within the cluster. In that embodiment, the master node can redistribute the packets among the functioning nodes within the cluster. Thus, the cluster service can appear to operate without interruptions.

0039The clusterware <b>130</b> can also maintain the packet distribution information. This information tracks what packets are routed to what nodes. This information can be useful if the packets need to be re-routed. In some embodiments, the distribution information can be maintained by one or more slave nodes of the cluster.

0040The external devices do not need to know anything about the internal configuration of the cluster <b>10</b>. Instead, to communicate with the cluster <b>10</b>, the external applications use the official IP address assigned to the master node <b>100</b>. As a result, the processing of the packet after it arrives to the master node <b>100</b> is substantially hidden from the external applications. For example, the cluster <b>10</b> balances the network traffic between servers without the help of a load balancer. Instead, the balancing decision is done by a network server, referred to as a master node <b>100</b>. Preferably, the cluster <b>10</b> has one master node that is responsible for balancing network traffic.

0041As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, the data packet arrives at the inbound network interface <b>110</b>, of the master node <b>100</b>. In one embodiment, the network interface <b>110</b> receives the data packets from the network using the official IP address. Preferably, the network interface <b>110</b> is implemented using the network card (NIC), network card drive and the network stack.

0042The flow of the data packet is controlled by the master node clusterware <b>130</b>. For example, the clusterware <b>130</b> may decide that the packet needs to be processed by the filter module <b>131</b>, filter module <b>132</b>, filter module <b>133</b> and filter module <b>134</b>. The filter modules may perform various tasks, such as analyzing the contents of the data packet, decrypting or encrypting the data, etc. The clusterware <b>130</b> routes the packet to the filter module <b>131</b> and filter module <b>132</b>, wherein both of these modules are running on the master node <b>100</b>.

0043Based on the preconfigured set of conditions, the clusterware <b>130</b> chooses to process the data packet using the filter module <b>183</b>, running on the slave node <b>150</b>. The preconfigured set of conditions can operate as a function of the active servers within the cluster. The conditions can also operate based on the specific software algorithm, such as “round robin.” In some embodiments, the conditions can operate as a function of the resource utilization on the active nodes within the cluster. For example, if the first slave node has 30% CPU utilization and the second slave node has 50% CPU utilizations the clusterware <b>130</b> can choose the first slave node because it has the smallest CPU utilization.

0044As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, the clusterware <b>130</b> can forward the data packet and the filter state information necessary to process the packet to the slave node <b>150</b> using the synchronization interface <b>140</b>.The clusterware <b>180</b> running on the slave node <b>150</b> detects an incoming data packet and the filter state information on the synchronization interface <b>190</b>. In one embodiment, when the slave node <b>150</b> receives the data packet and its filter state from the master node <b>100</b>, the slave node <b>150</b> positions the data packet in the exact same position of the filtering process. As a result, the individual filter modules of the slave node are not aware of whether the data packet being processed came in from the external network or from another node within the cluster <b>10</b>.

0045The clusterware <b>180</b> invokes the filter module <b>183</b> to process the data packet on the slave node <b>150</b>. The filter module <b>183</b> processes the data packet. The clusterware <b>180</b> running on the slave node <b>150</b> sends the data packet back to the master node <b>100</b> using the synchronization interface <b>190</b>. The clusterware <b>130</b>, running on the master node <b>100</b> receives the data packet sent by the slave node <b>150</b>. The clusterware <b>130</b> routes the packet to the filter module <b>134</b> and to the outbound network interface <b>120</b>.

0046Each node within the cluster can have a synchronization interface with separate IP and MAC addresses that uniquely identify each node. In one embodiment, all outbound and inbound network interfaces share the same IP address, but have separate MAC addresses. As a result, the cluster <b>10</b> can appear as a single machine.

0047The clusterware applications <b>130</b> and <b>180</b> can be implemented using several software components. Importantly, the exact number of software components is not limiting for the purposes of the present invention and is used solely to illustrate a possible implementation of the present invention.

0048Although the clusterware <b>130</b> running on the master node <b>100</b> and the slave node <b>150</b> can be substantially identical, they, nonetheless, can operate in different modes. For example, the clusterware <b>130</b> running on the master node <b>100</b> can handle the master tasks such as communicating with external devices, delegating network packet processing to other nodes, monitoring and maintaining the list of active nodes within the cluster. Further, the clusterware <b>130</b> running on the master node <b>100</b> is responsible for administering the cluster distribution. It can choose what cluster node should be selected for processing a particular filter or task. This selection can be based on the resource availability on the master node <b>100</b>. This selection can also be based on a software algorithm or a cpu usage of slave nodes, as explained hereinabove.

0049As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the clusterware <b>130</b> may decide that the network packet needs to be processed by the filter module <b>131</b>, filter module <b>132</b>, filter module <b>133</b> and/or filter module <b>134</b>. The filter modules <b>131</b>, <b>132</b>, <b>133</b>, <b>134</b> may perform various tasks, such as analyzing the contents of the data packet, decrypting or encrypting the data. Based on a preconfigured set of factors, the clusterware <b>130</b> may decided that the filters <b>131</b>, <b>132</b> and <b>134</b> should be processed on the master node <b>100</b>, but filter <b>133</b> (or, its equivalent, filter <b>183</b>) should be processed by the slave node <b>150</b>.

0050To delegate the processing of the filter <b>133</b> to the slave node <b>150</b>, the clusterware <b>130</b> running on the master node <b>100</b> and the clusterware running on the slave node <b>150</b> is synchronized using the synchronization interfaces <b>140</b> and <b>190</b>. The clusterware <b>130</b> can synchronize the data between the filters running on different nodes, without the need to specifically alter the filter applications. For example, the application synchronization can be implemented using an open source file synchronization tool, such as csync2. Csync2 is designed to synchronize files located on different computers. In some embodiments, csync2 can synchronize the quarantined objects of a content scanner. Csync2 can synchronize licensing information, such as license code and IP track list. It can also synchronize the software updates, virus patters and IDS signatures. Similarly, it can synchronize the remote administration certificates, such as WebAdmin and ssh public key.

0051Alternatively, network applications can be synchronized using the application-specific status updates. For example, cluster and high availability (HA-aware) applications can synchronize their internal state using their own protocols. HA-aware applications are designed to communicate with each other over the network to exchange the packet state information. In some embodiments, HA-aware applications can also synchronize the encryption key or alterable setting information. In some embodiments, the amount of the synchronization traffic can be minimized by scheduling the synchronization tasks. For example, the cluster administrator can configure the HA-aware applications running on the cluster to synchronize every 15 minutes.

0052In one example, the application specific synchronization can be used to synchronize established IPSec tunnels (Security Associations) and their encryption keys. The application specific synchronization can synchronizes IPSec sequence numbers, which can be synchronized in ranges instead of after each packet. Further, IPSec tunnel synchronization can enhance the existing IPSec-based VPN solutions, such as “Strongswan.”

0053The application specific synchronization can also be used to synchronize the database files. For example, the application specific synchronization can be used to synchronize the files of the MySQL database. In another embodiment, the applications running on different nodes within the cluster can be synchronized using the remote procedure calls (RPC). RPC allow a function running on one server to invoke another function, running on another server. For example, one type of the remote procedure calls, commonly referred to as PerlRPC, can be used to synchronize the internal configuration of the system via a web graphical user interface.

0054The cluster <b>10</b> can be configured to share the state of the data packet between multiple servers within the cluster. This information can be used to avoid the loss of the data packet in case of a server failure. In one embodiment, each node in the cluster <b>10</b> has substantially the same number of interfaces. A unique MAC address can be assigned to each interface. To ensure a faster takeover and to force an update of the ARP tables of the attached hosts, the master node <b>100</b> (or the newly elected master node) can send ARP messages containing the external IP addresses to the active slave nodes within the cluster.

0055The clusterware <b>130</b> running on the master node <b>100</b> is configured to be responsible for monitoring and maintaining the list of the active nodes within the cluster. In one embodiment, the clusterware running on the master node sends messages on the cluster synchronization interface requiring all recipients to respond. The information about responding slave nodes <b>150</b> can be stored in the random access memory (RAM) of the master node <b>100</b>. If the master node <b>100</b> is restarted, the data stored in the RAM can be lost. The list of the active nodes can be kept in RAM, recorded in the database or written to a file. If the master node <b>100</b> fails and needs to be restarted, the list of the active nodes can be retrieved from the database and verified. In one embodiment of the invention, each node keeps track of the full topology of the cluster.

0056In case of a cluster node failure, the master node <b>100</b> is configured to notify the administrator by sending an email message to the pre-configured email address. The master node <b>100</b> could also notify the administrator by making an automated phone call with a recorded message to the preconfigured phone number. For example, the clusterware <b>130</b> running on the master node <b>100</b> can detect that not all of the slave nodes <b>150</b> recorded in the list of the active nodes responded to the master's communication request. The clusterware <b>130</b> running on the master node <b>100</b> can compose an email message by emailing a pre-configured message template together with the list of failed nodes to the cluster administrator.

0057In one embodiment, each node can have a pre-assigned range of network ports. For example, the table below shows one possible configuration:

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="91pt" align="center" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="98pt" align="center" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Node</entry><entry>Start</entry><entry>End</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="91pt" align="char" char="." /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="98pt" align="center" /><tbody valign="top"><row><entry>1</entry><entry>24576</entry><entry>28671</entry></row><row><entry>2</entry><entry>28672</entry><entry>32767</entry></row><row><entry>3</entry><entry>32768</entry><entry>36863</entry></row><row><entry>4</entry><entry>36864</entry><entry>40959</entry></row><row><entry>5</entry><entry>40960</entry><entry>45055</entry></row><row><entry>6</entry><entry>45056</entry><entry>49151</entry></row><row><entry>7</entry><entry>49152</entry><entry>53247</entry></row><row><entry>8</entry><entry>53248</entry><entry>57343</entry></row><row><entry>9</entry><entry>57344</entry><entry>61439</entry></row><row><entry>10</entry><entry>61440</entry><entry>65535</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0058The port map above can ensure that all nodes have their own port range and therefore full TCP/IP and UDP/IP network access. The master nodes distributes packets according to these list to other nodes. In one example, the networked cluster according to the present invention, does not require the Network Address Translation (NAT) to be performed at the time when the network packet is received. In one embodiment this can be implemented by performing the address translation prior to transferring the data packet to a different cluster node.

0059In one embodiment, the present invention does not require the connection tracking table to be replicated to all cluster nodes. Instead, the connection tracking table can be maintained on one slave node. This reduces the amount of data to be synchronized. The complexity of the cluster system can be decreased. In other embodiments of the present invention, the connection tracking entries can be synchronized.

0060In another embodiment, the master node of the networked cluster can be dynamically reassigned. For example, if the master node fails, the slave nodes can vote for the new master to take over all control of the cluster. In one embodiment, the master node can be selected randomly. In other embodiments, the master can be selected based on the hardware characteristics of the particular slave nodes. The master can also be selected based on the node id. For example, the master selection algorithm can elect a new master by promoting the slave node with the highest node id.

0061In one embodiment of the present invention, the master and slave nodes can automatically recognize each other. For example, if a new slave node is connected to the networked cluster, the slave node will automatically register with the master node by sending a configuration request to the current master. The master node can reply with all necessary configuration options and an unused node id.

0062In one embodiment, the cluster according to the present invention can run on blade systems and Astaro Security Gateway (“ASG”) appliances. Astaro Security Gateways are hardware devices designed for complete protection of the computer networks from the network security threats. In one embodiment, the cluster status and messages can be displayed on the LCD displays of the ASGs.

0063In one embodiment the clusterware <b>130</b> can be implemented as a collection of software components. Distributing the functionality of the clusterware among multiple components can provide a more stable software environment. For example, one software component can be responsible for keeping track of the active nodes and assigning new connections to the slave nodes using a distribution algorithm, as discussed hereinabove.

0064Another software component can be responsible for saving the packet state information before the packet leaves or after the packet arrives to a particular node. This function is important because each distributed packet can contain preserved packet state information and preserved filter module information. Another software component can be responsible for insuring that data packets are properly being routed within the cluster. For example, if the master node establishes a connection and later sends a data packet to one of the slave nodes for specific filter processing, this software module can ensure that the data packet is delivered to the appropriate slave and sent back to the master.

0065<figref idref="DRAWINGS">FIG. 2</figref> illustrates a flowchart diagram <b>200</b> that can be implemented by one of the software components, according to the present invention. This component can be responsible for routing data packets within the cluster. The flow chart <b>200</b> illustrates step <b>205</b>, in which the component receives the data packet from the external device. In step <b>210</b>, the component selects a set of filters for processing of the data packet. This set of filters can include various firewall processing, such as decryption, encryption and virus scanning.

0066In step <b>215</b>, the component can map each filter to a specific node within the cluster. The flow chart <b>200</b> executes this step only once and before processing the data packet by any of the filters. In some embodiments, however, this step can be implemented immediately before the packet is processed by each filter. In that scenario the cluster will always choose the optimal node for processing a particular filter. The downside of it is frequent checks for resource utilizations of cluster nodes can decrease the overall performance of the cluster.

0067In step <b>220</b>, the component makes sure that there is at least one filter that should process the data packet. If the packet does not need to be processed by any filter, the software component may finish the processing of the data packet. When the filter processing of the data packet is complete, the software component can pass control of the packets to other software components.

0068If the packet still needs to be processed by one or more filters, step <b>225</b> can be performed to decide whether the packet needs to be processed on the master node or on a slave node of the cluster. As explained hereinabove, the decision can be as simple as consulting the filter-node map generated in the step <b>215</b>. Alternatively, the decision can involve monitoring the resource utilization of the available nodes of the cluster. If the packet should be processed on the master node, in step <b>240</b> the packet is forwarded to the filter running on the master node and then a check <b>220</b> for more filter processing can be performed.

0069Conversely, if the packet should be processed by a slave node, in step <b>230</b> the packet and the packet state information is forwarded to the selected slave node. As illustrated in the flowchart <b>200</b>, the filter processing can be synchronous, in a way that each data packet is processed by only one filter at any point in time. In other embodiments, however, the filter processing can be asynchronous. In these embodiments the master node, after forwarding the data packet to one of the slave nodes, does not need to wait for the processed packet to return. Instead, the master node can perform other processing of the data packet. When all packets are processed either by the master node or by slave nodes of the cluster, the control of the data packet can be passed to another software component.

0070<figref idref="DRAWINGS">FIG. 3</figref> shows a network topology <b>300</b> illustrating one possible implementation of the stateful clustering system. In that topology the stateful clustering system <b>320</b> is used to shield the private network <b>330</b> from the security threats coming from the Internet network <b>310</b>. The data flowing from the Internet <b>310</b> first arrives to a master node of the clustering system <b>320</b>. Clustering system <b>320</b> distributes the stateful firewall processing between itself and the available slave nodes within the cluster. After the incoming data is processed, the processed data is forwarded to the private network <b>330</b>.

0071The embodiment of the present invention described with respect to FIG. <b>1</b>,<b>2</b> and <b>3</b> is exemplary only and not limiting. This embodiment may be altered, e.g., by having stages or components added, removed, or rearranged. Other embodiments are within the scope and spirit of the invention. For example, due to the nature of software, functions described above can be implemented using software, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. Further, while the description above refers to the invention, the description may include more than one invention.