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.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat