Load Sharing Modes

See:

Load Sharing Multicast Mode

Load Sharing A redundant cluster mode, where all Cluster Members process all incoming traffic in parallel. For more information, see "Load Sharing Multicast Mode" and "Load Sharing Unicast Mode". Synonyms: Active/Active, Load Balancing mode. Acronym: LS. lets you distribute network traffic between Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Members. In contrast to High Availability A redundant cluster mode, where only one Cluster Member (Active member) processes all the traffic, while other Cluster Members (Standby members) are ready to be promoted to Active state if the current Active member fails. In the High Availability mode, the Cluster Virtual IP address (that represents the cluster on that network) is associated: (1) With physical MAC Address of Active member (2) With virtual MAC Address. Synonym: Active/Standby. Acronym: HA., where only a single member is active State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism. at any given time, all Cluster Members in a Load Sharing solution are active. The Cluster Members decide, which Cluster Member Security Gateway that is part of a cluster. handles which packet. The cluster decision function A special cluster algorithm applied by each Cluster Member on the incoming traffic in order to decide, which Cluster Member should process the received packet. Each Cluster Members maintains a table of hash values generated based on connections tuple (source and destination IP addresses/Ports, and Protocol number). performs this task - examining each packet going through the cluster, and determining which Cluster Member should handle it. As a result, a Load Sharing cluster utilizes all Cluster Members, which usually leads to an increase in its total throughput.

It is important to understand that ClusterXL Cluster of Check Point Security Gateways that work together in a redundant configuration. The ClusterXL both handles the traffic and performs State Synchronization. These Check Point Security Gateways are installed on Gaia OS: (1) ClusterXL supports up to 5 Cluster Members, (2) VRRP Cluster supports up to 2 Cluster Members, (3) VSX VSLS cluster supports up to 13 Cluster Members. Note: In ClusterXL Load Sharing mode, configuring more than 4 Cluster Members significantly decreases the cluster performance due to amount of Delta Sync traffic. Load Sharing, provides a full High Availability solution as well. When all Cluster Members are Active, traffic is evenly distributed between the Cluster Members. In case of a failover Transferring of a control over traffic (packet filtering) from a Cluster Member that suffered a failure to another Cluster Member (based on internal cluster algorithms). Synonym: Fail-over. event, caused by a problem in one of the Cluster Members, the processing of all connections handled by the faulty member is immediately taken over by the other Cluster Members.

ClusterXL offers two separate Load Sharing solutions: Multicast and Unicast. The two modes differ in the way Cluster Members receive the packets sent to the cluster. This section describes the Load Sharing Multicast mode.

The Multicast mechanism, which is provided by the Ethernet network layer, allows several interfaces to be associated with a single physical (MAC) address. Unlike Broadcast, which binds all interfaces in the same subnet to a single MAC address, Multicast enables grouping within networks. This means that it is possible to select the interfaces within a single subnet that will receive packets sent to a given MAC address.

ClusterXL uses the Multicast mechanism to associate the cluster Virtual IP addresses with Multicast MAC addresses. This makes sure that all packets sent to the cluster, acting as a default gateway on the network, will reach all Cluster Members. Each Cluster Member then decides, whether it should process the packets or not. This decision is the core of the Load Sharing mechanism: it has to assure that at least one Cluster Member will process each packet (so that traffic is not blocked), and that no two Cluster Members will handle the same packets (so that traffic is not duplicated).

An additional requirement of the decision function, is to route each connection through a Cluster Member, to ensure that packets that belong to a single connection will be processed by the same Cluster Member. Unfortunately, this requirement cannot always be enforced, and in some cases, packets of the same connection will be handled by different Cluster Members. ClusterXL handles these situations using its State Synchronization Technology that synchronizes the relevant information about the current connections (stored in various kernel tables on Check Point Security Gateways) among all Cluster Members over Synchronization Network. Due to State Synchronization, the current connections are not cut off during cluster failover. mechanism, which mirrors connections on all Cluster Members.

Example

This scenario describes a user logging from the Internet to a Web server behind the cluster that is configured in Load Sharing Multicast mode.

The user requests a connection from 192.168.10.78 (his computer) to 10.10.0.34 (the Web server).
A router on the 192.168.10.x network recognizes 192.168.10.100 (the cluster Virtual IP address) as the default gateway to the 10.10.0.x network.
The router issues an ARP Request for IP 192.168.10.100.
One of the Active Cluster Members processes the ARP Request, and responds with the Multicast MAC assigned to the cluster Virtual IP address of 192.168.10.100.
When the Web server responds to the user requests, it recognizes 10.10.0.100 as its default gateway to the Internet.
The Web server issues an ARP Request for IP 10.10.0.100.
One of the Active members processes the ARP Request, and responds with the Multicast MAC address assigned to the cluster Virtual IP address of 10.10.0.100.
All packets sent between the user and the Web server reach every Cluster Member, which decide whether to process each packet.
When a cluster failover occurs, one of the Cluster Members goes down State of a Cluster Member during a failure when one of the Critical Devices reports its state as "problem": In ClusterXL, applies to the state of the Security Gateway component; in 3rd-party / OPSEC cluster, applies to the state of the State Synchronization mechanism. A Cluster Member in this state does not process any traffic passing through cluster.. However, traffic still reaches all of the Active Cluster Members. Therefore, there is no need to make changes in the network ARP routing. The only thing that changes, is the cluster decision function, which takes into account the new state of the Cluster Members.

Load Sharing Unicast Mode

Load Sharing Unicast mode provides a Load Sharing solution adapted to environments, where Multicast Ethernet cannot operate. In this mode, a single Cluster Member, referred to as Pivot, is associated with the cluster Virtual IP addresses. This Pivot A Cluster Member in the Unicast Load Sharing cluster that receives all packets. Cluster Virtual IP addresses are associated with Physical MAC Addresses of this Cluster Member. This Pivot Cluster Member distributes the traffic between other Non-Pivot Cluster Members. Cluster Member is the only Cluster Member to receive all packets sent to the cluster. The Pivot Cluster Member is then responsible for propagating the packets to other Cluster Members, creating a Load Sharing mechanism. Distribution of packets is performed by applying a decision function on each packet, the same way it is done in Load Sharing Multicast mode. The difference is that only one Cluster Member performs this selection The packet selection mechanism is one of the central and most important components in the ClusterXL product and State Synchronization infrastructure for 3rd-party clustering solutions. Its main purpose is to decide (to select) correctly what has to be done to the incoming and outgoing traffic on the Cluster Member. (1) In ClusterXL, the packet is selected by Cluster Member(s) depending on the cluster mode: In HA modes - by Active member; In LS Unicast mode - by Pivot member; In LS Multicast mode - by all members. Then the Cluster Member applies the Decision Function (and the Cluster Correction Layer). (2) In 3rd-party / OPSEC cluster, the 3rd-party software selects the packet, and Check Point software just inspects it (and performs State Synchronization).: any non-Pivot A Cluster Member in the Unicast Load Sharing cluster that receives all packets from the Pivot Cluster Member. member that receives a forwarded packet will handle it, without applying the decision function. Note that non-Pivot Cluster Members are still active, because they perform routing and Firewall tasks on a share of the traffic (although they do not perform decisions).

Even though the Pivot Cluster Member is responsible for the decision process, it still acts as a Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. that processes packets (for example, the decision it makes, can be to handle a packet by itself). However, since its additional tasks can be time consuming, it is usually assigned a smaller share of the total load.

When a failure A hardware or software problem that causes a Security Gateway to be unable to serve as a Cluster Member (for example, one of cluster interface has failed, or one of the monitored daemon has crashed). Cluster Member that suffered from a failure is declared as failed, and its state is changed to Down (a physical interface is considered Down only if all configured VLANs on that physical interface are Down). occurs in a non-Pivot member, its handled connections are redistributed between active non-Pivot Cluster Members, providing the same High Availability capabilities of High Availability and Load Sharing Multicast. When the Pivot Cluster Member encounters a problem, a regular failover event occurs, and, in addition, another active non-Pivot member assumes the role of the new Pivot. The Pivot member is always the active member with the highest priority. This means that when a former Pivot recuperates, it will retain its previous role.

Example

In this scenario, we use a Load Sharing Unicast cluster as the Security Gateway between the end user computer and the Web server.

The user requests a connection from 192.168.10.78 (his computer) to 10.10.0.34 (the Web server).
A router on the 192.168.10.x network recognizes 192.168.10.100 (the cluster Virtual IP address) as the default gateway to the 10.10.0.x network.
The router issues an ARP Request for IP 192.168.10.100.
The Pivot Cluster Member handles the ARP Request, and responds with the MAC address that corresponds to its own unique IP address of 192.168.10.1.
When the Web server responds to the user requests, it recognizes 10.10.0.100 as its default gateway to the Internet.
The Web server issues an ARP Request for IP 10.10.0.100.
The Pivot Cluster Member handles the ARP Request, and responds with the MAC address that corresponds to its own unique IP address of 10.10.0.1.
The user request packet reaches the Pivot Cluster Member on interface 192.168.10.1.
The Pivot Cluster Member decides that the second non-Pivot Cluster Member should handle this packet, and forwards it to 192.168.10.2.
The second Cluster Member recognizes the packet as a forwarded packet, and handles it.
Further packets are processed by either the Pivot Cluster Member, or forwarded and processed by the non-Pivot Cluster Member.
When a failover occurs from the current Pivot Cluster Member, the second Cluster Member assumes the role of Pivot.
The new Pivot member sends Gratuitous ARP Requests to both the 192.168.10.x and the 10.10.0.x networks. These GARP requests associate the cluster Virtual IP address of 192.168.10.100 with the MAC address that corresponds to the unique IP address of 192.168.10.2, and the cluster Virtual IP address of 10.10.0.100 with the MAC address that correspond to the unique IP address of 10.10.0.2.
Traffic sent to the cluster is now received by the new Pivot Cluster Member, and processed by it (as it is currently the only Active Cluster Member).
When the former Pivot Cluster Member recovers, it re-assumes the role of Pivot, by associating the cluster Virtual IP addresses with its own unique MAC addresses.