CoreXL - number of active cores changing during runtime

Check Point
#1

Are you aware of any scenario where the number of active cores can change during runtime?


One of the issues that indeni checks is that all cluster memebers running CoreXL are configured with the same number cores. The rule uses the output of the "fw ctl multik stat" command, counts the number of Active cores (identified as "Yes") and compares the number between the cluster members. According to the Check Point documentation, a change to the number of Active cores can only be put into effect by booting the device.


Image title



Recently we have noticed that the number of Active cores, reported by the command. can drop on one of the cluster members for a period of 30 to 60 minutes and than reverts to the previous value.

#2

More information from logs that were provided by one of oure customers:

  1. The CoreXL core count difference is observed at some time on almost all of the clusters.
  2. In all cases the duration of the mismatch is one hour and the difference in the number of cores is one.


Assuming that this is a valid behavior for CoreXL, we can avoid alerting on this scenario by delaying the alert by a configureable number of minutes, where 60 minutes is the default settings. The alert will watch for CoreXl mismatches that last more than 60 minutes.


The unknown is whether this is a valid scenario for CoreXL.

#3

Thats correct, we've also seen this in our environment. I can only think it is a counter anomoly as the cores are not really changing in live time