Current recommendations for Scaling Foreman

Hi everyone! We’re looking at using Foreman for provisioning so I’m trying to put together a design document for our infrastructure. The main concern I have is how to appropriately handle scaling issues. I’ve read through Foreman :: Journey to High Availability (and also watched the youtube video) but since that was 8 years ago, I’m wondering how relevant it is for the current version of Foreman. For example, in the document they utilized the memcached plugin with separate memcached servers for the rails cache, but this PR adds support for redis as a backend. Should that be used instead of memcached now? Also, I’m wondering, is there’s a rule of thumb for determining how many Foreman nodes you need?

For a bit of background on our environment, we currently have about 3500 nodes that we need to manage. Most of those are currently in the same datacenter, but we have two other datacenters that Foreman will need to expand to in the near future. We’re almost exclusively an Ubuntu shop, so I don’t believe we will be using Katello (someone please correct me if this is wrong). We use SaltStack for our config management, so we’ll be wanting to make use of the salt plugin. Any use of Puppet will be strictly limited to whatever Foreman needs to manage itself (The docs say it’s possible to setup Foreman without Puppet, but all I’ve found online is people that tried and weren’t able to get it to work).

Thank you in advance for any help!

Hi @mgilbert

You can see a rough estimate in Tuning Performance of Foreman. If you manage 1000+ hosts, throwing an extra CPU core and a bit of memory at your Foreman instance and Smart Proxies is IMHO very reasonable.

Depending on your networking layout, you should look into deploying multiple Smart Proxies. See Installing an External Smart Proxy Server nightly. You might also want to consider using a load balancer. See Configuring Smart Proxies with a Load Balancer.

Note that Foreman/Katello can handle content for Ubuntu.

1 Like

Thank you very much for the reply, @maximilian and for pointing me to the correct documentation. Since I haven’t been using Katello, I didn’t think to look at the Katello-specific docs.

From reading what you’ve linked, it only mentions load-balancing the proxies and not the main foreman server. Does this mean that the only real benefit of having multiple foreman master servers would be for redundancy/HA as opposed to increasing performance?

Regarding Katello, the documentation shows that it must be installed on an EL operating system. Since we don’t have any EL systems, we would prefer installing Foreman on Ubuntu, but would be open to the idea of having a one-off EL system if Katello provides enough of a benefit. I’ve only found a few blurbs about what Katello adds, but I’m not sure I fully understand. Can you speak at all to what is gained by adding Katello?

Thanks again!

I am not sure if you can/should run Foreman server in HA. I believe multiple Smart Proxy suffice because they can handle provisioning, configuration management, and deliver content. I don’t have any first hand experience though.

Yes, Foreman+Katello only runs on EL8. The benefit of Katello is lifecycle management. You can sync upstream repositories, version them, only include or exclude specific packages, and make them consumable by your managed hosts (and more). You gain a lot of control and independence from public mirrors.

Example: If one of your Smart Proxies manages 100 hosts, then you’ll only have to sync packages from the internet/an (outside) mirror once, and therefore save time and network resources.

If you’re interested in security errata for Debian and Ubuntu, you should look into orcharhino. It’s an enterprise product based on Foreman and Katello and is able to provide security errata for Debian and Ubuntu. See Disclaimer: I work for ATIX and I’d be happy to connect you.

1 Like

Having Foreman high available is possible and using Redis instead of Memcache is the way to go as Redis is already used for other components. But typically I do not need HA here as in most environments availability is high enough without it and it avoids making the environment more complicated. And it gets more and more complicated with every plugin you add as not all are designed with HA in mind.

So I would also recommend scaling via Smart Proxy instead of HA.


Having Foreman high available is possible and using Redis instead of Memcache is the way to go as Redis is already used for other components.

How to configure this?
I can’t see foreman redis plugin…
Any docs?

No need for a plugin as this is a default option and with 3.9 even the new default.

Added some documentation to the puppet module while working on it: GitHub - theforeman/puppet-foreman: Puppet module for Foreman

I saw you asked for an external redis in another thread and yes this was exactly why I added this for a customer, it is just the matter of the url used.


If I want to provide my own redis instance I should change my settings.conf to:

   :type: redis
    - redis://
     :compress: true
     :namespace: foreman

Is it correct?
What does the /4 mean after the redis port: :6379/4 ? In another example I noticed /6.

Yes, correct.

The number after the slash is redis database number, /4 is the one chosen when making redis the default rails cache. But you can use every number you want as it will be created on the fly with the first write, just use different ones for different workflows. /4 was taken to avoid conflicts with other software which are unlikely but better save than sorry. For other use cases in Foreman/Katello other numbers were already used like pulp (/8) and dynflow (/6).