R82 - ElasticXL

[HeikoAnkenbrand]

ElasticXL is a new cluster technology that enables simplified operation with a single management object with automatic configuration and software synchronisation between all cluster members.

ElasticXL is expected to be delivered with R82 or later versions. ElasticXL is based on similar technology to Maestro, but without MHOs. It is based on Check Point's SP versions for a scalable platform that allows you to increase the performance of the security gateways almost linearly.

This is achieved naturally by load balancing between individual gateways that operate in a cluster as a single entity.

This new cluster technology will some of the Maestro featchers such as SMO (Singel Management Object) use.

A ElasticX gateway will work as a pivot member and act simelar as a MHO's in a Maestro environment and simultaneously takes on the role of SMO.

The pivot member takes over the network connection and controls the ARP requests in the network. The pivot member distributes the connections via a distribution matrix to the connected member in the security group similar to a Maestro environment.

Same as the Maestro environments, the familiar SP commands will also be available here and there will also be a gclish. The management traffic will be handled by the SMO (pivot member).

Installation process:

1) The gateways are installed as usual via the First Configuration Wizard. ElasticXL" is now selected instead of "ClusterXL" on the product page.
2) After that, the SIC to the first gateway (pivot member) will be established single gateway (not as a cluster object). Afterwards, the policy can be installed.
3) In the following step the next gateways can be added by (host name, serial number).

Here you can find detailed installation information about ElasticXL:
Install ElasticXL Cluster

>>> Please note that this information is not yet an official statement from Check Point and may change at any time. <<<

[PhoneBoy]

Don't be so sure 😉
I maintained a DEC firewall in 1995...don't remember which one it was.
Quite a big gateway to protect an ISDN line for Internet.
I also did a couple of installs of TIS Gauntlet before I got exposed to Check Point FireWall-1.

[the_rock]

Maybe embarrassing to admit, but the only thing I remember as a kid back in eastern Europe was commodore 64 😂😂😂

I still recall very first computer we ever owned, had whooping 64K of ram and 128 MBs hdd 🙂

Andy

[Jim_Holmes]

... Even before that there was a DECnet firewall but we won't go there because I guess there is nobody here who goes that far back 😉

Don't bet on it.

[Garrett_DirSec]

Hello -- I'm digging into this more with imminent release of R82_EA.

Any ideas on the hardware requirements for the Pivot member?    I suggest it won't need to be same specs as the adjacent gateways that will end up handing the connections and persistent sessions.

Should we assume that day one that all nodes of an ElasticXL cluster will need to be same model, but this may change for future?    I'm thinking through the sales conversations about "a new clustering technology that allows you -- Mr Customer -- to leverage investment in gateways day one.   However, you'll now need to buy THREE instead of TWO gateways ... and they'll need to be same model".   

This could get expensive.

Thanks --

ref

@PhoneBoy 

[PhoneBoy]

Same model is probably a safe assumption for ElasticXL in R82, at least initially.
One gateway will be the SMO (gets policy from management) and distribute to other gateways like Maestro does today.
I don’t believe a gateway will be a “pivot member” similar to how ClusterXL Active/Active clustering works in unicast mode today, though there is a correction layer that ensures the same gateway gets all the traffic for a connection (again, similar to Maestro).

[genisis__]

If we can do a mixed cluster, that would be a huge game changer.

[_Val_]

No, you cannot mix different appliances, not even with ElasticXL

[Steffen_Appel]

Will Quantum Spark Appliances be supported?

[the_rock]

I dont believe those appliances will be supported.

[PhoneBoy]

This feature will require R82 and Quantum Spark appliances will not receive this release until sometime after it is released for regular Quantum gateways.
Whether it will support ElasticXL for Quantum Spark is unknown at this time.

[Steffen_Appel]

OK - thanks.

[Kyaw_Myo_Oo]

Thanks for sharing.

[babicmilan]

Hello, I'm interesting in what clustering technology is ElasticXL (Active/Active or Active/Standby)?

[the_rock]

I believe its load sharing principle, as its based on Maestro.

[_Val_]

No, not like Maestro, as it has neither up/down links, nor a load balancer.

ElasticXL is an iteration of a pivot-based load-sharing, pretty similar to the Unicast Load Sharing mode of the classic ClusterXL.

[the_rock]

Right. I meant more like Maestro as far as load sharing.

Andy

[PhoneBoy]

Maestro uses actual hardware (the orchestrator) for Load Balancing; ElasticXL does not.
I would, therefore, expect the performance to be similar to ClusterXL Load Sharing.
However, you get all the other benefits of Maestro (SMO, better API support, etc).

[Mikula83]

Hello, I have some misunderstanding regarding ElasticXL as a new clustering technology in R82.

Is this clustering technology intended as a replacement for ClusterXL in the future? If answer is yes, is it applicable on all ClusterXL modes (High Availability, Load Sharing Multicast, Load Sharing Unicast, Active-Active),

For example, we have a many sites with two gateways configured as ClusterXL High Availability (one gateway is active, second one is standby). What about ElasticXl in this design as you know in ElasticXL all gateways are active. Does it have some limitations if we compare ElasticXL and ClusterXL High Availability. Is it better to use ElasticXL regarding ClusterXL High Availability?

Best regards
Milan Babic

[_Val_]

What is new in ElasticXL, is provisioning and cluster management, with Maestro-like SMO.

Under the hood, however, ElasticXL is using the unicast Load sharing (pivot mode) you already know from ClusterXL. EXL support up to three members per site, and can be implemented in a dual-site setup. In this case, with just a single member per site deployed, you will have your classic HA pair.

ElasticXL is not intended to replace the classic ClusterXL at this point, but it has some advantages when it comes to deployment and operations. 

[Bob_Zimmerman]

There are certain clustering situations which ElasticXL will probably never be able to handle. For example, I don't see any way there could ever be a "full HA" (both management HA and firewall HA on a single pair of devices; popular for small deployments) cluster with ElasticXL.

[PhoneBoy]

Yeah, I doubt ElasticXL will ever support this use case.

[the_rock]

I think last time I had seen someone use full HA was 6-7 years ago...I have to say, that setup is great when it works, but once it breaks, o boy : - )

Andy

[Mikula83]

OK, I understand but still loking for some answers.

Can I find somewhere matrix of compatibility between ClusterXL HA and ElasticXL? What is supported on one clustering technology and not supported on other. For example (NAT, IPsec VPN with 3rd party gateways, Remote Access VPN), is it all supported on ElasticXL? There is no a lot of documentation regarding ElasticXL.

Imagine that you want to configure a new cluster of two gateways. What would you choose ClusterXL or ElasticXL?

Best regards,

Milan Babic

[the_rock]

I keep consulting Copilot AI lately for these things and I think this answer is really good. See if it helps.

Andy

Pozdrav : - )

********************

Certainly! Here are the key differences between ClusterXL and ElasticXL:

ClusterXL:

1. Architecture:

   • Traditional clustering technology.
   • Supports up to 5 Cluster Members.
   • Handles both traffic and state synchronization.
   • Interfaces are treated as Critical Devices.
   • Supports Load Sharing and High Availability modes.

2. Configuration:

   • Requires manual configuration for each cluster member.
   • Uses Cluster Control Protocol (CCP) for synchronization.

3. Management:

   • Each cluster member is managed individually.
   • Requires manual intervention for adding or removing members.

4. Performance:

   • Performance can degrade with more than 4 Cluster Members in Load Sharing mode due to Delta Sync traffic.

ElasticXL:

1. Architecture:

   • New clustering technology with simplified operations.
   • Supports up to 3 ElasticXL Cluster Members per site and 6 in total.
   • Single Management Object (SMO) for the entire cluster.
   • Automatic synchronization of configuration and software packages from the SMO.

2. Configuration:

   • Only the first Security Appliance (SMO) needs to be configured manually.
   • Additional members automatically clone the configuration and software from the SMO.
   • Supports automatic configuration of the internal synchronization network.

3. Management:

   • Managed through a Global Gaia Portal and Global Gaia Clish.
   • Allows adding and removing members on-the-fly.
   • Supports Gaia RESTful API for management.

4. Performance:

   • Efficient scale architecture with better performance and administrator experience.
   • Supports only the "General" Distribution Mode for traffic assignment.

5. Additional Features:

   • Dual Site support.
   • Automatic assignment of unicast MAC Addresses to data interfaces.
   • Hidden bond interfaces for management and synchronization to prevent changes.

Summary Table:

Feature	ClusterXL	ElasticXL
Architecture	Traditional clustering	New clustering technology
Max Members	Up to 5	Up to 6 (3 per site)
Configuration	Manual for each member	Automatic cloning from SMO
Management	Individual management	Single Management Object (SMO)
Performance	Degrades with >4 members in Load Sharing	Efficient scale architecture
Synchronization	Uses CCP	Automatic internal sync network
Additional Features	-	Dual Site support, RESTful API

For more detailed information, you can refer to the respective administration guides for ClusterXL and ElasticXL.

Learn more:

1. R82 Scalable Platforms Administration Guide - Working-with-ElasticXL
2. R81 ClusterXL Administration Guide - Viewing-Cluster-Interfaces

07:47 AM

[_Val_]

ElasticXL limitations are actually listed among R82 limitations: https://support.checkpoint.com/results/sk/sk181128

All features you mentioned are supported with ElasticXL. Once again, from a clustering perspective, ElasticXL is a Unicast LS cluster. The differences are mostly about installation, provisioning, and management of a cluster/ SMO object.

[Mikula83]

Thanks a lot for explanation.

[PhoneBoy]

Review the Known Limitations for R82, specifically the following two sections: ElasticXL and Maestro/Scalable Platforms (which ElasticXL is an implementation of).

The only place where ClusterXL has to be used, to the best of my knowledge, is a "Full HA" configuration (management + gateway on both cluster members).
For an HA-only cluster (no load sharing) you have to set up ElasticXL as "Dual Site" where each site has a single member.
Otherwise, I can't think of a reason one should choose ClusterXL over ElasticXL (beyond familiarity with ClusterXL).