ClusterXL has these working modes. This section briefly describes each mode and its relative advantages and disadvantages.
Important:
|
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.
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] |
Chain of events:
.
.
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):
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.
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.
This table summarizes the similarities and differences between the ClusterXL modes.
|
High Availability |
Load Sharing |
Load Sharing |
---|---|---|---|
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 |