Question about changing the number of CoreXL firewall instances on a virtual system on maestro

[Uwe_Herkt]

Hello,

We have successfully replaced the hardware appliances in our Maestro environment. In the next step we now want to activate further virtual systems and want or should probably adapt the virtual system configuration of the existing system. Now two questions:
1. the R81.20 Admin Guide also says: “If you change the number of CoreXL Firewall instances on a virtual system, there will be some downtime for that virtual system.” I was of the opinion that this restriction no longer exists in R81.20. Does anyone have experience with this -> can I change the number of CoreXL Firewall instances via the Smartconsole on the VS object without downtime or do I really need to plan for downtime?

2. we have 3 9700 appliances in our Maestro environment, with default distribution SND/FW_worker so 3*28 fw_worker / 3*4 SNDs
The current coreXL configuration is: 2 VS -> 14 v. instances + 2 VS -> 2 v. instances -> so already slightly overbooked. However, the overall environment is running well and is still far from the load limit.
What would be the recommended coreXL setup in the target design with 7 virtual systems with partly very different workloads?
a)2*7 v. instances + 2*1 v. instances + 3*4 v. instances =28 v. instances, -> this would make it more difficult to adapt to different workloads and I would have to adapt the existing systems.
b) or can I simply overbook, as the allocation is only virtual anyway -> e.g. 2*14 v. instances + 2*2 v. instances + 3*8 v. instances = 56 v. instances. Especially as I theoretically have 3*28 cores available in the Maestro network, i.e. 84 fw_worker cores

What is your experience?

[Sven_Glock]

In (1) you are talking about the feature dynamic balancing which was new to maestro in R81.20.
With dynamic balancing there will be automatic balancing between CoreXL fw instances und SND instances. A change happens on the fly without reboot. 
Changing the number of VSX CoreXL instances without outage is still somewhere on the roadmap.

(2) AFAIK Check Point does not recommend to overbook more than factor 2 of your FW_workers, which is in your case 56.

[Bob_Zimmerman]

1. There will be a hard outage when you change the number of workers for a VS. The firewall tables are structured differently based on the number of CoreXL instances, so VSs with different counts can't sync.

2. The 9700 has 16 real cores plus hyperthreading for 32 virtual cores total. You don't get that many per member, you get that many total. If you tell a VS to use 12 workers, it will have 12 workers on each of the members. I would not allocate more workers for all VSs combined than a member has real cores. That is, with two VSs, if one VS has 12 workers, I would only give the other four workers. Overcommitting cores isn't as bad as it is on a VM host (VM hosts need to wait for all of the committed cores to be free before doing work; CoreXL does not have this limitation), but it's still extremely bad for performance consistency.