Chapter 5. Red Hat Satellite Capsule Servers

The Red Satellite Capsule Server is a Satellite component that provides federated services to discover, provision, and configure hosts outside of the primary Satellite server. A Satellite Capsule Server provides the following features:
  • Pulp Server/Content Node features, including:
    • Repository synchronization
    • Content delivery
  • Red Hat Satellite Provisioning Smart Proxy features, including:
    • DHCP, including ISC DHCP servers
    • DNS, including Bind and MS DNS servers
    • Any UNIX-based TFTP server
    • Puppet Master servers from 0.24
    • Puppet CA to manage certificate signing and cleaning
    • Baseboard Management Controller (BMC) for power management
The Satellite Capsule Server is a means to scale out the Satellite installation. Organizations can create various capsules in different geographical locations where the data centers are located. These are centrally managed through the Satellite Server. When a Satellite user promotes content to the production environment, the Satellite Server will push the content from the Satellite Server to each of the Satellite Capsule Servers. Host systems pull content and configuration from the Satellite Capsule Servers in their location and not from the central Satellite Server.
Creating various Satellite Capsule Servers will decrease the load on the central server, increase redundancy, and reduce bandwidth usage.

5.1. Red Hat Satellite Capsule Server Scalability

The maximum number of Capsule Servers that the Satellite Server can support has no fixed limit but has been tested on a Satellite Server with a Red Hat Enterprise Linux 6.5 and 7 hostsystems. Currently, running fourteen capsules with two vCPUs have been tested to run without issues.

5.1.1. Capsule Scalability with Puppet Clients

Capsule scalability depends heavily on the following factors, especially when managing puppet clients:
  1. Number of CPUs
  2. Run-interval distribution
  3. Number of puppet classes
The Capsule Server has a concurrency limitations of 100 concurrent puppet agents running at any single point in time. Running more than 100 concurrent puppet agents will result in a 503 HTTP error.
For example, assuming that the puppet agent runs are evenly distributed with less than 100 concurrent puppet agents running at any single point during a run-interval, a Capsule Server with four CPUs can expect a maximum of 1250-1600 puppet clients with a moderate workload of 10 puppet classes assigned to each puppet client. Depending on the number of puppet clients required, the Satellite installation can scale out the number of Capsule Servers to support them.
Based on the following assumptions:
  1. There are no external puppet clients reporting directly to the Satellite 6 integrated capsule.
  2. All other puppet clients report directly to an external capsule.
Puppet scalability within Satellite on Red Hat Enterprise Linux 6.5 Capsules are as follows:
  1. On the minimum amount of CPUs (two CPUs):
    1. At 1 puppet class per host: Not tested
    2. At 10 puppet classes per host: Maximum of 1020-860
    3. At 20 puppet classes per host: Maximum of 375-330
  2. On the recommended amount of CPUs (four CPUs):
    1. At 1 puppet class per host: Maximum of 2250-1875
    2. At 10 puppet classes per host: Maximum of 1600-1250
    3. At 20 puppet classes per host: Maximum of 700-560

Note

The maximums in the above given numbers represent an evenly distributed run interval of all puppet agents. Any deviation runs the risk of filling the passenger request queue and is subject to the concurrency limitation of 100 concurrent requests.