|
|
|
Included Topics |
ClusterXL has four working modes. This section briefly describes each mode and its relative advantages and disadvantages.
Refer to the High Availability Legacy appendix for a detailed discussion of legacy High Availability functionality. It is recommended that you use the High Availability New Mode to avoid problems with backward compatibility.
|
Note - Many examples in the section refer to the sample deployment shown in the ClusterXL example. |
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 make 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.
This scenario describes a user logging from the Internet to a Web server behind the cluster that is configured in Load Sharing Multicast 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.
In this scenario, we use a Load Sharing Unicast cluster as the Security Gateway between the end user computer and the Web server.
The 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 stand-alone Security Gateway would have resulted 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. Thus, 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 one involving money transactions over the Internet.)
To achieve this purpose, ClusterXL New High Availability mode designates one of the cluster members as the active member, while the other members remain in stand-by mode. The cluster virtual IP addresses are associated with the physical network interfaces of the active member (by matching the virtual IP address with the unique MAC address of the appropriate interface). Thus, all traffic directed at the cluster is actually routed (and filtered) by the active member. The role of each cluster member is chosen according to its priority, with the active member being the one with the highest ranking. Member priorities correspond to the order in which they appear in the Cluster Members page of the Cluster Properties window. The top-most member has the highest priority. You can modify this ranking at any time.
In addition to its role as a firewall, the active member is also responsible for informing the stand-by members of any changes to its connection and state tables, keeping these members up-to-date with the current traffic passing through the cluster.
Whenever the cluster detects a problem in the active member that is severe enough to cause a failover event, it passes the role of the active member to one of the standby members (the member with the currently highest priority). If State Synchronization is applied, any open connections are recognized by the new active member, and are handled according to their last known state. Upon the recovery of a member with a higher priority, the role of the active member may or may not be switched back to that member, depending on the user configuration.
It is important to note that the cluster may encounter problems in standby members as well. In this case, these members are not considered for the role of active members, in the event of a failover.
This scenario describes a user logging from the Internet to a Web server behind the firewall cluster.
.This table summarizes the similarities and differences between the ClusterXL modes.
|
Legacy High Availability |
New High Availability |
Load Sharing Multicast |
Load Sharing |
|---|---|---|---|---|
High Availability |
Yes |
Yes |
Yes |
Yes |
Load Sharing |
No |
No |
Yes |
Yes |
Performance |
Good |
Good |
Excellent |
Very Good |
Hardware Support |
All |
All |
Not all routers are supported |
All |
SecureXL Support |
Yes |
Yes |
Yes, with Performance Pack or SecureXL Turbocard. |
Yes |
State Synchronization Mandatory |
No |
No |
Yes |
Yes |
VLAN Tagging Support |
Yes |
Yes |
Yes |
Yes |
|
Note - For further details regarding VLAN Tagging Support, see sk40107. |