Capsule

Latest response

Thanks in advance for the responses.

I have a customer interested in implementing Satellite . This is a relatively small environment, 10 remote locations. The Capsule server HW requirements present a cost challenge for them.

Looking to the community for feedback, thoughts, suggestions on Satellite in smaller environs.

Responses

"It depends".

How small is the "small environment"? How many clients at each remote location, and is the network bandwidth to each remote location good enough that downloading packages/patches from the Satellite once for each client will not be a problem?

We have a couple of off-premises locations with dozens of clients each, but no remote Capsules - the network links between sites are all 1Gb or faster, so there is no performance or network congestion issue.

+1 to what James said. Capsules serve three purposes:

  • make the content more local to your endpoints so that things like patching or provisioning happen faster (better QoS).
  • provide a single node in an isolated network (like a PCI Zone or DMZ) which has management capabilities. (all the clients connect to/through the capsule, so you only have to open the firewall once)
  • allow your environment to scale by offloading workload from your main Satellite.

Depending on your network bandwidth between sites, you might not need one. They aren't mandatory. However, with a large enough number of clients in a remote site (or wacky network topology), it may make sense to add one.

The target use-case is an environment of ~40 Red Hat 6 and 7 servers (and potentially 8 soon) that do not have internet access. The customer is looking to have only the Satellite server connected to the Red Hat CDN, and then the 40 Red Hat servers connect to it for package updates."

Also:

Does the satellite server easily serve the function of a YUM repository for the 40 servers in the environment to connect to it, or is there a more complex method required for this.

Is the Satellite server capable of caching packages updates periodically, so they are available during maintenance windows without the constraints of WAN bandwidth.

The target use-case is an environment of ~40 Red Hat 6 and 7 servers (and potentially 8 soon) that do not have internet access. The customer is looking to have only the Satellite server connected to the Red Hat CDN, and then the 40 Red Hat servers connect to it for package updates."

This is literally why Satellite was created. :) It is intended to be a Satellite of the Red Hat Content Delivery Network, but on-premise.

Does the satellite server easily serve the function of a YUM repository for the 40 servers in the environment to connect to it, or is there a more complex method required for this.

At its core, that is what is does. You can do much more advanced content management, provisioning, & life-cycling also, but the 'glorified yum repository, but on-premise' use-case works well.

Is the Satellite server capable of caching packages updates periodically, so they are available during maintenance windows without the constraints of WAN bandwidth.

Yes. You can have two primary models of content sync in Satellite. (Note: there are other models, but these are the major ones)

  • The immediate model - where Satellite will synchronize (on the schedule you define) all the repositories you care about. (So you'll have every RPM for that repo, on-disk, forever)
  • The on-demand model - where Satellite doesn't synchronize the repositories up-front, but will retrieve RPMs as needed. That is, if a client attempts to yum install bash and the Satellite doesn't have it locally, it will retrieve it at that time from the CDN, deliver it to the client, and store it (in perpetuity) on disk for other clients. On-demand is the default since Satellite 6.3

Thanks. One last question, (famous last words). From a licensing perspective, I only need to license the Satellite server, and not the remote servers?

Smart Management subscriptions will be needed for each machine you manage. That subscription will give you enouh subscriptions for the Satellite Server and Capsule Servers to cover your needs.