VSX & coreXL instances on VSs

[Nadezda_Zuka]

Hi guys, Could you please help me understand what will be the effect of increasing coreXL instances per VS on VSX? On vsenv0 we have the following: :0]# fw ctl multik stat ID | Active | CPU | Connections | Peak ---------------------------------------------- 0 | Yes | 8-19 | 161 | 932 1 | Yes | 8-19 | 239 | 6012 Other VSs have the similar output as vsenv 1: :1]# fw ctl multik stat fw: CoreXL is disabled I have enabled 4 coreXL instances on one of test VSs: :75]# fw ctl multik stat ID | Active | CPU | Connections | Peak ---------------------------------------------- 0 | Yes | 8-19 | 0 | 63 1 | Yes | 8-19 | 1 | 39 2 | Yes | 8-19 | 0 | 366 3 | Yes | 8-19 | 0 | 80 The Check Point support recommended us to enable/increase coreXL instances count on customer VSs that consume a lot of CPU. I just wanted to understand if this action will influence other VSs that have coreXL disabled? Will it give us more even spread of load between VSX CPU cores? What will it give for the affected VS?

[Daniel_Taney]

I believe that unlike "traditional" FWK's, VSX FWK's run in user mode processes instead of being physically bound to kernel processes that run on each core. Given that, the load of these processes can be distributed and shifted across cores on the Gateway. This should enable you to grossly under or oversubscribe CoreXL cores to each VS instance.

If you are seeing heavy CPU load on a few VS's, but the Gateway itself sees overall low utilization, you should be able to add more cores without much concern. If there is plenty of CPU headroom left, I don't suspect you should see this change affect other VS's. 

Another option could be to consider using VSLS mode; which will allow you to use multiple VSX Gateways Active/Active to distribute VS load. The only thing to keep in mind with VSLS is that you want to have enough capacity to survive a Gateway failure should one Gateway go down. 

[_Val_]

By default, each VS comes with a single FWK instance. If some particular VSs are handling more traffic than others, you may want to add more FWK instances to those, allowing better performance indicators: number of concurrent connections, throughput and bandwidth. 

CoreXL has to be enabled (and is by default enabled with 4 and more cores) to benefit from that. Number of FWK instances is defined on VS object in SmartConsole. Mind, increasing or decreasing the number of FWKs will lead to VS re-build and will cause a short interruption of traffic crossing that VS.

[Esger_Mutsaerts]

Is this still the case in R80.20? I saw a Check Point presentation that claims changes to the number of workers on VSX VSLS in R80.20 does not introduce downtime anymore.

[Raman_Arora]

This is true, if you modify number of instances, there wouldn't be any downtime. vs restarts itself after stateful failover.