R80.30 ClusterXL with 2.6 kernel and 3.10 kernel

[HeikoAnkenbrand]

One of our customers has a failure in the hardware of a ClusterXL gateway. He wants to use a new server HP DL 380 G10 with an old server HP DL 380 G8. The idea now is to use a new 3.10 kernel on the G10 server.

Now the question?

Is it possible to use a 2.6 kernel on the HP DL 380 G8 and a new kernel 3.10 on the HP DL 380 G10 in a ClusterXL?

[Danny]

Check Point's ClusterXL Admin Guide says:

Important! The hardware for all cluster members must be exactly the same, including:

• CPU
• Motherboard
• Memory
• Number and type of interfaces

So you can't configure a Cluster consisting of two different servers. At least not one that is supported.

[HeikoAnkenbrand]

CUT>>>

Important! The hardware for all cluster members must be exactly the same, including:

CPU
Motherboard
Memory
Number and type of interfaces

<<<CUT

Thank you, I know. But had already received other statements in tickets from Check Point.

[HeikoAnkenbrand]

My feeling was more like no!

[HeikoAnkenbrand]

Hi @Danny,

Did you test that?
Does it work without any problems?

The customer also orders a new second G10 server. We would only do this for a few days.😀

I think the ClusterXL version should be identical on 2.6 kernel and 3.10 kernel. Thus, the requirements for a cluster should be met.

The interesting question is the support of this combination.

If need be, I'd rather have a statement here from Check Point.

[Danny]

The admin guide clearly states 'the hardware must be exactly the same‘ and yours is a G8 and a G10 server, so I think it‘s clear that this wouldn‘t be supported.

[HeikoAnkenbrand]

Like I said, I know that.

We just need to bridge a few days until the new server arrives:-)

[Danny]

Ok, then test it out and let us know.

[HeikoAnkenbrand]

I'm going to try this in a maintenance window:-)

Just has to run until the new hardware arrives.

[HeikoAnkenbrand]

CUT>>>

Important! The hardware for all cluster members must be exactly the same, including:

CPU
Motherboard
Memory
Number and type of interfaces

<<<CUT

Regardless of this request we could discuss these parameters in another post.

From my point of view only a few parameters are technically interesting in a ClusterXL environment:

CPU -> Equal number of cores -> Sync core number (CoreXL) of a session from one session tabel (active gw) to the standby sessin table (standby gw) => ok!

Memory -> should be equal => ok!

Network Interfaces -> same number of used interfaces in cluster => ok!

Motherdoard -> ??? why should it be the same?

But as I said, that should be discussed in another post.

[Danny]

Please pay attention to the word: including.

Check Point posted just a short listing of hardware devices, not a complete list.

[Timothy_Hall]

Heiko as long as you have all those configuration elements matching (indicated with ok!) my gut is that it will work fine as I don't see how ClusterXL would be able to freak out over any other differences.  Definitely not supported though...

[_Val_]

@HeikoAnkenbrand and all, motherboard is important because of chipset. Most importantly, the proposed configuration will not be supported. 

To the topic starter, as mentioned above, you cannot run such a cluster. 

[Kurpeus]

Hi Timothy

I've a cluster on two identical Dell power edge servers running R80.30 on 2.6. I want to upgrade them to use R80.30 3.10. During the upgrade window which will likely last few days, the cluster members will be running different OS kernel version. I don't think this will be an issue but given the current context with COVID 19  if things go south most likely  i'll follow too 🙂

[Timothy_Hall]

I don't think the cluster members will be able to sync at all with the different kernels but I'm not sure.  You may want to temporarily uncheck "Drop out of state TCP packets" on the Stateful Inspection screen of Global Properties until everything is fully upgraded.  Doing this will help blunt the impact of any  non-stateful failovers that occur.

[Kurpeus]

I'm desperately in need for multi queue so i'll give it a try a report back. Thanks for the tip about out of state TCP packets that's a very good point. 

I forgot to mention , to make matter worse, atm my cluster is running on VmWare and during the upgrade one member will run on VmWare while the other one is re-imaged on bare metal.  ClusterXL may go mental 

Anyway we only live once 🙂

[_Val_]

No, not supported, will not work.

[Kurpeus]

There is a difference between not supported and will not work. I can do with a cluster not supported for few days.  Now if the cluster doesn't work that's a different story

[_Val_]

1. Not supported.

2. Will not work.

[PhoneBoy]

Right, but you can potentially put R80.40 on the new box which does support clustering with different versions.

[_Val_]

How does it help, exactly? G8 and G10 have different amount of cores. R80.40 or otherwise, we cannot have a cluster, if amount of cores is different on two cluster members.

Well, technically, you can, but one of the members will always in Ready state. No HA, no Sync. 

[PhoneBoy]

I clearly missed that detail 🤦🏼‍♂️

[_Val_]

After some internal discussion with R&D:

1. The main issue in hands is the different number of CPU cores in G8 and G10 models.

2. State sync doesn't work with different configurations and specifically, the different number of cores. That means, it is impossible to have a healthy cluster in your case, regardless of kernel version.

3. We have multi-version cluster support with R80.40. If the number of cores is the same on both servers, you can form a healthy cluster with different kernel versions in R80.40.

4. The whole issue is state sync. As mentioned in another comment, you still can run the cluster, but the state will be Active/Down on one and Ready/Active on the second member. Sync will not work, and in case of a failover, there will be a traffic cut: all connections will have to be reinitialized. If this risk is acceptabe for you, you can go this way, as a temporal emergency measure only, before you can fully recover/replace the faulty model. This by all means is not recommended as a long term solution.  

Many thanks to @Gera_Dorfman and @Dorit_Dor for looking into this.

[Henrik_Noerr1]

Or you could just disable the extra cores on the G10 temporarily?