ClusterXL Modes

Introduction to ClusterXL Modes

ClusterXL has four working modes. This section briefly describes each mode and its relative advantages and disadvantages.

High Availability Mode
Load Sharing Multicast Mode
Load Sharing Unicast Mode

Note - Many examples in the section refer to the sample deployment shown in the ClusterXL example.

Load Sharing Multicast Mode

Load Sharing lets you distribute network traffic between Cluster Members. In contrast to High Availability, where only a single member is active at any given time, all Cluster Members in a Load Sharing solution are active. The Cluster Members decide, which Cluster Member handles which packet. The cluster decision function 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 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 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 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. 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 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: any non-Pivot 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 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 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 G-ARP 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.

High Availability Mode

The ClusterXL High Availability mode provides basic High Availability capabilities in a cluster environment. This means that the cluster can provide Firewall services even when it encounters a problem, which on a regular Security Gateway results in a complete loss of connectivity. When combined with Check Point State Synchronization, ClusterXL High Availability can maintain connections through failover events, in a user-transparent manner, allowing a flawless connectivity experience. As a result, High Availability provides a backup mechanism, which organizations can use to reduce the risk of unexpected downtime, especially in a mission-critical environment (such as money transactions).

To achieve this, ClusterXL High Availability mode designates one of the Cluster Members as the Active member, while the other Cluster Members remain in Standby mode. The cluster associates the Virtual IP addresses with the physical MAC addresses of the physical interfaces on the Active member (by matching the cluster Virtual IP address with the unique MAC address of the appropriate physical interface). Therefore, all traffic directed at the cluster Virtual IP addresses, is actually routed (and filtered) by the Active Cluster Member.

The role of each Cluster Member is chosen according to its cluster state and Cluster Member priority. Cluster Member priorities correspond to the order, in which they appear in the Cluster Members page of the cluster object in SmartConsole. The top-most Cluster Member has the highest priority. You can modify this ranking at any time (requires policy installation and causes a failover).

In addition to its role as a Firewall, the Active Cluster Member is also responsible for informing the Standby Cluster Members of any changes to its cluster state and kernel tables. This keeps the peer Cluster Members up-to-date with the current traffic passing through the cluster.

Whenever the Active Cluster Member detects a problem that is severe enough to prevent this Cluster Member from working correctly, failover occurs in the cluster. One of the Standby Cluster Members (the Cluster Member with the next highest priority) assumes the role of the Active Cluster Member. If State Synchronization is enabled, the new Active Cluster Member recognizes any open connections and handles them according to their last known state.

Upon the recovery of a failed former Active Cluster Member with a higher priority, the role of the Active Cluster Member may or may not be switched back to that Cluster Member. This depends on the cluster object configuration - Maintain current active Cluster Member, or Switch to higher priority Cluster.

It is important to note that Standby Cluster Members may encounter problems as well. In this case, in the event of a cluster failover, the Standby Cluster Members are not considered for the role of a new Active Cluster Member.

Example

This scenario describes a connection from a Client computer on the external network to a Web server behind the Cluster (on the internal network). The cluster of two members is configured in High Availability mode.

Example topology:

[Client on]
[external network]
{IP 192.168.10.78/24}
{DG 192.168.10.100}
|
|
{VIP 192.168.10.100/24}
/ \
| |
{IP 192.168.10.1/24} {IP 192.168.10.2/24}
| |
{Active} {Standby}
[Member1]-----sync-----[Member2]
| |
{IP 10.10.0.1/24} {IP 10.10.0.2/24}
| |
\ /
{VIP 10.10.0.100/24}
|
|
{DG 10.10.0.100}
{IP 10.10.0.34/24}
[Web server on]
[internal network]

Chain of events:

The user tries to connect from his Client computer 192.168.10.78 to the Web server 10.10.0.34.
The Default Gateway on Client computer is 192.168.10.100 (the cluster Virtual IP address).
The Client computer issues an ARP Request for IP 192.168.10.100.
The Active Cluster Member (Member1) handles the ARP Request for IP 192.168.10.100.
The Active Cluster Member sends the ARP Reply with the MAC address of the external interface, on which the IP address 192.168.10.1 is configured.
The Client computer sends the HTTP request packet to the Active Cluster Member - to the VIP address 192.168.10.100 and MAC address of the corresponding external interface.
The Active Cluster Member handles the HTTP request packet.
The Active Cluster Member sends the HTTP request packet to the Web server 10.10.0.34.
The Web server handles the HTTP request packet.
The Web server generates the HTTP response packet.
The Default Gateway on Web server computer is 10.10.0.100 (the cluster Virtual IP address).
The Web server issues an ARP Request for IP 10.10.0.100.
The Active Cluster Member handles the ARP Request for IP 10.10.0.100.
The Active Cluster Member sends the ARP Reply with the MAC address of the internal interface, on which the IP address 10.10.0.1 is configured.
The Web server sends the HTTP response packet to the Active Cluster Member - to VIP address 10.10.0.100 and MAC address of the corresponding internal interface.
The Active Cluster Member handles the HTTP response packet.
The Active Cluster Member sends the HTTP response packet to the Client computer 192.168.10.78.
From now, all traffic between the Client computer and the Web server is routed through the Active Cluster Member (Member1).
If a failure occurs on the current Active Cluster Member (Member1), the cluster fails over.
The Standby Cluster Member (Member2) assumes the role of the Active Cluster Member.
The Standby Cluster 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 addresses with the MAC addresses of the physical interfaces on the new Active Cluster Member (former Standby Cluster Member):
- Cluster VIP address 192.168.10.100 and MAC address of the corresponding external interface, on which the IP address 192.168.10.2 is configured.
- Cluster VIP address 10.10.0.100 and MAC address of the corresponding internal interface, on which the IP address 10.10.0.2 is configured.
From now, all traffic between the Client computer and the Web server is routed through the new Active Cluster Member (Member2).
The former Active member (Member1) is now considered to be "down". Upon the recovery of a former Active Cluster Member, the role of the Active Cluster Member may or may not be switched back to that Cluster Member, depending on the cluster object configuration.

Mode Comparison Table

This table summarizes the similarities and differences between the ClusterXL modes.

	High Availability	Load Sharing Multicast	Load Sharing Unicast
High Availability	Yes	Yes	Yes
Load Sharing	No	Yes	Yes
Performance	Good	Excellent	Very Good
Hardware Support	All routers	Not all routers are supported	All routers
SecureXL Support	Yes	Yes	Yes
State Synchronization	Optional	Mandatory	Mandatory
VLAN Tagging Support	Yes	Yes	Yes