R82 – Install ElasticXL Cluster

[HeikoAnkenbrand]

Overview

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.

I have tested it with the R82 EA version.

You can find more information about ElasticXL in this article:  R82 ElasticXL 

Install first ElasticXL gateway

1) Run the GAIA installation wizard on the appliance and select "ElasticXL" for clustering.
     If you want to use VSNext (replacement for the classic VSX), click the checkbox "Install as VSNext".

 

2) Assign a SIC one-time password.

3) After installation, you will find the ElasticXL Gateway under the "Cluster Management" menu item.

4) Create a new gateway object (not CLusterXL object) in the SmartConsole.
5) Now establish a SIC connection to the ElasticXL gateway IP from the SmartDashboard.
6) Afterwards, install a policy on the gateway.

Add more ElasticXL gateways to the cluster.

1) Wire the next appliances via the switch infrastructure so that all sync interfaces are connected to same network.
     Normally the ElasticXl sync interface is the eth1 interface.

2) Start the appliance and do not run the installation wizard.

3) Log in to the appliance via console cable or via LOM interface.  
    You are now in the gclish (global clish). Execute the following command:
    g> show cluster member info

    Copy the "Request ID" to the clipboard or to a text file.

4) Open a SSH session to the previously installed appliance and add the appliance with the following command in the gclish:
     g> add cluster member method request-id identifier 5aac9e10de7cd0e34cdf7fa368076b37 site-id 1 format json

5) The appliance should be installed automatically after approx. 5 minutes.
     The access policy is automatically synchronised by the first ElasticXL gateway (SMO).

6)  Both gateways should now be shown in the GAIA portal under the side 1.

    

7) Open an SSH session on the first gateway and check if the ElasticXL cluster is working.
    You can check this with the following command in the expert mode:
# asg monitor

[the_rock]

Nice! 👍

[PhoneBoy]

Possible the final instructions may differ once R82 is released as undoubtedly this was done based on EA code.
Even so, it gives people an idea of what to expect. 👍🏻

[the_rock]

Just curious...will this be available for regular Gaia appliances or only maestro?

Best,

Andy

[HeikoAnkenbrand]

@the_rock 

Should be possible on the regular appliances.
But we should wait for the GA version.

Best,
Heiko

[the_rock]

Great news.

Best,

Andy

[_Val_]

@the_rock ElasticXl is for physical clusters only, not Maestro.

[the_rock]

Thanks @_Val_ , really looking forward to it.

Best,

Andy

[PhoneBoy]

Just to be clear, the only major difference hardware-wise between Maestro and non-Maestro are:

• The addition of the hardware orchestrator
• The installation image used (though the underlying software is the same for Maestro and non-Maestro)
• Some functionality differences between Maestro and non-Maestro configurations: https://support.checkpoint.com/results/sk/sk148074 

ElasticXL brings a lot of the functionality of Maestro without the hardware orchestrator.
It is designed to replace ClusterXL for HA/Load Sharing configurations and will use a lot of the same commands and concepts as Maestro (including the Single Management Object). 

[the_rock]

Thats @PhoneBoy , super helpful.

Best,

Andy

[OTWal]

Will R82 and ElasticXL be presented at the CPX in Vienna?

[HeikoAnkenbrand · Accepted solution]

There will be a presentation in Vienna at the CPX:
Wednesday 15:20-16:20    -->   R82 - ElasticXL and VSNext Generation Under the Hood

[the_rock]

Hope the video of it is posted here, would be awesome.

Best,

Andy

[_Val_]

Aren't you coming to Vegas?

[the_rock]

No buddy, not coming.

Best,

Andy

[PhoneBoy]

Videos of CPX sessions will be posted after Las Vegas next week.
I can assure you we will also cover this topic in future CheckMates sessions 🙂

[Oliver_Fink]

And it was a really good presentation. Thanks for that.

[RamGuy239]

This is going to remove the need for 3 IP addresses per subnet I suppose? No need for 1x IP per cluster members + 1x VIP? This will make it very attractive for remote locations with restricted access to WAN subnets larger than /30 address space.

Does it have to run in active-active mode? I understand why active-active might be ideal for throughput, but there might be scenarios where you'd want it to be active-standby to have less complexity, and to avoid having the orchestration of traffic. When deploying virtual, like on "private cloud" solutions such as VMware ESXi, Nutanix AHV, etc. If both members are running on the same host, there isn't much benefit to have both members active at the same time.

ElasticXL seems like a no-brainer compared to clusterXL, both for HA and for Load Sharing. Have to see if there is any known limitations, and most customers will avoid using new technology for some time. But this all sounds like a great solution over clusterXL to me.

[HeikoAnkenbrand]

@RamGuy239 

CUT>>>

Does it have to run in active-active mode? I understand why active-active might be ideal for throughput, but there might be scenarios where you'd want it to be active-standby to have less complexity, and to avoid having the orchestration of traffic. When deploying virtual, like on "private cloud" solutions such as VMware ESXi, Nutanix AHV, etc. If both members are running on the same host, there isn't much benefit to have both members active at the same time.

<<<CUT

We are talking about a connection HA. This means that it is not a gateway HA or LS.
The advantage is that in the event of a hardware error, the connections are distributed to the remaining gateways.

PS:
VMWare is currently not supported.

[RamGuy239]

@HeikoAnkenbrand 

ElasticXL and VSnext (requires ElasticXL) is not supported on VMware ESXi? I guess this means hypervisors in general? Is this from a support point-of-view, meaning it won't be officially supported by Check Point, thus no help from TAC, or won't it work as a result of something in the current R82 software is simply not compatible with VMware and/or other hypervisors?

Asking because I have access to R82 EA and was going to play with it in on my home network (VMware ESXi 8.0) and LAB at work (also VMware ESXi 8.0). But my biggest attraction towards R82 is all related to ElasticXL, and some VSnext. So I won't waste my time if it's not supposed to work at all.

[Oliver_Fink]

There must be ways to get it working, as @Peter_Elmer from Check Point demonstrated it at CPX 2024 in Vienna. As far as I remember there is a problem with interface names when constructing sync and management bonds automatically. So, VSNext and ElasticXL seem to run in VMware. Maybe Check Point can post some hints to get this running in labs. That would be really nice.

But besides that, ElasticXL and VSNext will not be officially supported in VMware.

[RamGuy239]

@Oliver_Fink 

Thank you for the response.

This do seem to be the case, indeed. Tried to install R82 on VMware ESXi and upon selecting ElasticX and VSnext during the first-time-wizard it will automatically add interface "Mgmt" into bonding group 1, which seems to be a management bond like on Maestro, and it adds eth1-Sync and eth2-Sync into bonding group 1024. None of these interface exist when running "show interfaces" or "ifconfig".

eth1-Sync seems to correspond with eth1 (network adapter 2 on VMware ESXi), but I don't fully understand where "Mgmt" or eth2-Sync goes, and it's challenging to track as I can't use "show interface" in CLISH/GCLISH or ifconfig in expert to see the MAC addresses. There isn't help from checking the /etc/udev/rules.d/00-OS-XX.rules file either.

[RamGuy239]

Looks like I was able to get it running. The trick was to head into /etc/udev/rules.d/00-OS-XX.rules before starting the first-time-wizard. I renamed eth0 into Mgmt, eth1 into eth1-Sync and eth2 to eth2-Sync. This seems to have made it so that upon running first-time-wizard and enabling ElasticXL and VSnext it grabbed Mgmt which then corresponds to Network Adapter 1, eth1-Sync corresponding with Network Adapter 2, and eth2-Sync corresponding with Network Adapter 3. So this way I have control over what is what.

[Peter_Elmer]

Hello @Oliver_Fink ,

I see the comment added later by @RamGuy239 , who edited interface naming configuration file. In the presentation held in Vienna I mentioned that running an EA version of R82 on open servers and VMware is challenging. These days the R&D team is looking for feedback related installations of the R82 EA on appliances.

The R&D team is focused these days achieving best customer experience for EA versions of R82 ElasticXL and VSNext on appliances: note "these days". 

As development is ongoing the feedback from @HeikoAnkenbrand is important and I will bring this certainly to the attention of the relevant colleagues in R&D. 

best regards

pelmer

[RamGuy239]

Thanks for the reply! It might be too early, but does this mean we don't expect any support for ElasticXL and/or VSnext for virtual installations with R82?

So far, I have yet to run into any noticeable issues running VSnext on VMware ESXi after dealing with the interface mapping. I have to say that VSnext looks like a significant improvement! It is some new logic to get accustomed to, but overall, I will say managing it all makes far more sense.

From what I've seen, ElasticXL looks like a no-brainer compared to ClusterXL. I can't see any reason to opt for ClusterXL over ElasticXL. You can even do "regular" High Availability using one gateway "per site". Unless there are some fundamental limitations, this looks like a ClusterXL replacement. Removing VIP and needing three IPs per subnet will make it more attractive for remote sites, where public IP addresses are often limited.

[Peter_Elmer]

Hello @RamGuy239 ,

I am sorry that your tests have encountered issues, but that's what is testing a release under development is: going along with challenges. 

The R&D team is working on R82 and in our EMEA presales team we are using appliances for testing. We certainly understand that virtual environments are required to scale the learning and training experiences and are exploring options here.

I am looking forward exploring more the advantages of ElasticXL and the value it provides to customers achieving resilient active/active environments. I am looking forward holding the dialog about these values here 😀

Greetings

pelmer

[RamGuy239]

@Peter_Elmer, I think you misread me. I have not encountered any issues after fixing the interface mapping. It's looking really solid so far. It's been a very good experience!

[PhoneBoy]

ElasticXL is meant to run in VM according to the various R82 slides from CPX:

From the various internal documentation I'm reading, it appears this should work without renaming the interfaces, though it will rename eth0.
Possible this is not in the EA version you're using yet.
Having said that, this is something I expect we'll support in GA (or even in the upcoming Public EA).

[Oliver_Fink]

Are you quite sure, ClusterXL is not installable in VM? Or do you mean, it ist not supported? I am quite sure to remember that I did some lab installations of ClusterXL on VMware… 😉

[_Val_]

Yeah, that slide needs a bit of tuning. AFAIK, you can run ClusterXL on VMware, but it may not be supported, since there is/was virtual edition for VMware native.