VM specifications for the R80.20.M1

[Vladimir]

Can someone point me to the specifications for the VMs that should be running the R80.20.M1 ?

I am interested in vSphere ESXi VM configuration in particular (i.e. Linux distro and version).

[Jerry]

GW: 4xCore, 8-16GB RAM, 250GB VMDK

MGM: 4-8xCore, 16-32GB RAM, 500-1TB VMDK.

Got it exactly like this on R80.10 and planning an upgrade next month to R80.20 unless some EA plans changes ...

good luck with the built !

J.

[Jerry]

ps. number of NIC's for GW - up2U  / number of NIC's for MGM - if you use vMotion/vCenter I'd do LACP/vMAC aggregation if I were you but all depends - lab/prod

[Vladimir]

Thanks Jerry.

I am specifically looking for official sources on Linux Version and the supported and recommended virtual NICs:

  

I got the SMS running just fine on RHEL 5 x 64 with E1000s, but would like to know what's officially what, before doing that in production.

Regards,

Vladimir

[Jerry]

see this mate:

https://community.checkpoint.com/thread/1253 

[Jerry]

and this:

https://community.checkpoint.com/thread/6434-what-are-the-system-requirements-for-installing-r8010-o... 

[Vladimir]

Thank you again. I am familiar with those posts, but the only oficial references in them are to the Open Server. The rest is just based on community experience.

The reason I am inquiring is the new kernel in R80.20.M1.

Cheers,

Vladimir

[Jerry]

right, gotcha, you think it has changed am I right? you believe that R80.20 Virtual env. has different req. than R80.10 am I correct? I believe that some of the folks here will be able to confirm that R80.10 or .20 has very very similar specs regardless of their functionality and layout.

I believe that Linix wise this hasn't changed much. Let's see what Dameon Welch Abernathy‌ or other folks cite

[_Val_]

Indeed, there is a new 3.10.0-693cpx86_64 kernel used in R80.20.m1. 

Considering it is only Management release, you can choose standard RH7 or "Other Linux 3.x 64 bit kernel HW settings.

[PhoneBoy]

While we haven't documented an "official" answer to the best of my knowledge, what you've described is what generally works.

For R80.20.M1, you can use RHEL7 as the Linux kernel we use is consistent with this version.

RAM/CPU depends on the expected load of course.

I expect as we get an R80.20 Gateway version with the newer kernel, we may get the answers further clarified /documented.

[_Val_]

There is a chance the new kernel will not make it into R80.20 gateway GA.

[Timothy_Hall]

As far as memory and CPU core allocations for R80.10 vs. R80.20.M1 SMS in regards to management performance, I've reviewed the $CPDIR/conf/CpSetupInfo_resourceProfiles.conf file on both versions and the updates appear to be relatively minor.  This file is used to set Java heap sizes and other performance-related variables at SMS boot time based on the amount of cores/memory detected.  This file and its associated components was first discussed in my post here:

https://community.checkpoint.com/thread/7331-mangement-server-r8010-slowness?commentID=16840#comment... 

So after looking over everything in R80.20.M1 I'll restate my personal SMS performance recommendations.  Note that this is just for an SMS, Provider-1/MDSM is another ball of wax entirely.

Cores - In my experience, up to 8 cores will provide a quite noticeable performance improvement as each core is added and is strongly recommended; more cores beyond 8 seems to help a bit but will probably not make a big difference in most situations.  Digging deeper it appears that having more than 12 cores does not further tweak any performance-related settings via CpSetupInfo_resourceProfiles.conf, so while adding more cores beyond 8 may help a little bit (and this definitely tracks with my real-world experience), going beyond 12 is probably not worthwhile.

Memory - I'd strongly recommend at least 16GB minimum, more will certainly help especially if there is strong contention for the disk path being used by a SMS VM or with larger policy configurations.  As memory is added Java heap sizes and such for the various management processes will be automatically scaled up, but this scaling tops out above 35.8GB of RAM.  So increasing memory substantially beyond 35.8GB of RAM will not allocate any extra heap resources to Java, but certainly may help with the buffering/caching of disk operations performed by Gaia/Linux.

Hyperthreading - On bare-metal SMS R80/R80.10 open hardware there was a general recommendation to leave SMT/Hyperthreading off due to the possibility of exacerbating a bottleneck in the 2.6.18 disk I/O driver.  This was supposed to be rectified by use of the new 3.10 kernel and its corresponding updated driver, but if anyone with Check Point would like to update this unofficial recommendation specifically for R80.20.M1, I'm all ears.

Note again that the preceding recommendations are just for an SMS, Provider-1/MDSM is another ball of wax entirely and adding more core/memory resources beyond that stated above is quite likely to enhance Provider-1/MDSM management performance.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[_Val_]

Thanks, Timothy Hall‌, very informative

[Vladimir]

Thank you for this detailed breakdown. It certainly helps in the absence of official recommendations, specifically about hyperthreading, networking and VM versions in various virtualization environments.

In regards to MDS, I am shying away from recommending the upgrade to anyone at this point as there are still quirks that are not addressed yet in R80.X and am passing it off to CP ProServe for those bent on doing it anyway.

Since you have mentioned the 35.8 GB of RAM as a limit at which SMS performance tops-out (provided your IOPS are not maxed out), I wander if we can infer from it the optimal amount of memory for MDS appliances, based on number of domains in them, if logging is done on MLS.

[Tomer_Sole]

Hi, we will publish our recommended guidelines for R80.20 (and R80.20.M1) closer to the R80.20 release.

Generally though: for RAM, HD and CPU always refer to the appliance data sheet, and based on the input of how many gateways, domains, log rate etc. choose the specs under the appliance that says to fit those criterias, then create a VM with those specs. 

For Hyper-Threading, our tests showed different results for different use cases. So even though the updated Linux kernel allows that, it is not something that we currently recommend to activate or recommend not to activate to every customer. 

For Management Performance Profiles (CpSetupInfo_resourceProfiles.conf), what do they mean and should you change their defaults, see the R80.10 Security Management Performance Tuning Guide 

[Kris_Pellens]

Hello Tomer,

Have the recommended guidelines (VM specs) already been published?

Regards,

Kris

[PhoneBoy]

I haven't seen in the docs (or HCL) a list of what virtual hardware works so far.

The guidelines in this thread, I assume, still apply.