Red Hat SummitChapter 10. Common deployment scenarios
This section provides a brief overview of common deployment scenarios for Red Hat Satellite. Note that many variations and combinations of the following layouts are possible.
10.1. Single location with segregated subnets
Your infrastructure might require multiple isolated subnets even if Red Hat Satellite is deployed in a single geographic location. This can be achieved for example by deploying multiple Capsule Servers with DHCP and DNS services, but the recommended way is to create segregated subnets using a single Capsule. This Capsule is then used to manage hosts and compute resources in those segregated networks to ensure they only have to access the Capsule for provisioning, configuration, errata, and general management. For more information on configuring subnets, see Managing hosts.
10.2. Multiple locations
Red Hat recommends to create at least one Capsule Server per geographic location. This practice can save bandwidth since hosts obtain content from a local Capsule Server. Synchronization of content from remote repositories is done only by the Capsule, not by each host in a location. In addition, this layout makes the provisioning infrastructure more reliable and easier to configure.
10.3. Content view scenarios
The following section provides general scenarios for deploying content views as well as lifecycle environments.
The default lifecycle environment called Library gathers content from all connected sources. It is not recommended to associate hosts directly with the Library as it prevents any testing of content before making it available to hosts. Instead, create a lifecycle environment path that suits your content workflow. The following scenarios are common:
A single lifecycle environment – content from Library is promoted directly to the production stage. This approach limits the complexity but still allows for testing the content within the Library before making it available to hosts.
A single lifecycle environment path – both operating system and applications content is promoted through the same path. The path can consist of several stages, which enables thorough testing but requires additional effort. For example, you can use the Development, QA, and Production stages.
Application specific lifecycle environment paths – each application has a separate path, which allows for individual application release cycles. You can associate specific compute resources with application lifecycle stages to facilitate testing. However, this scenario increases the maintenance complexity.
The following content view scenarios are common:
- All in one content view – a content view that contains all necessary content for the majority of your hosts. Reducing the number of content views is an advantage in deployments with constrained resources (time, storage space) or with uniform host types. However, this scenario limits the content view capabilities such as time based snapshots or intelligent filtering. Any change in content sources affects a proportion of hosts.
- Host specific content view – a dedicated content view for each host type. This approach can be useful in deployments with a small number of host types (up to 30). However, it prevents sharing content across host types as well as separation based on criteria other than the host type, for example, between operating system and applications. With critical updates every content view has to be updated, which increases maintenance efforts.
- Host specific composite content view – a dedicated combination of content views for each host type. This approach enables separating host specific and shared content, for example you can have dedicated content views for the operating system and application content. By using a composite, you can manage your operating system and applications separately and at different frequencies.
- Component based content view – a dedicated content view for a specific application. For example a database content view can be included into several composite content views. This approach allows for greater standardization but it leads to an increased number of content views.
The optimal solution depends on the nature of your host environment. Avoid creating a large number of content views, but keep in mind that the size of a content view affects the speed of related operations (publishing, promoting). Also make sure that when creating a subset of packages for the content view, all dependencies are included as well. Note that Kickstart repositories should not be added to content views, as they are used for host provisioning only.
10.4. Satellite Server with multiple manifests
If you plan to have more than one Red Hat Network account, or if you want to manage systems belonging to another entity that is also a Red Hat Network account holder, then you and the other account holder can assign subscriptions, as required, to manifests. A customer that does not have a Satellite subscription can create a Subscription Asset Manager manifest, which can be used with Satellite, if they have other valid subscriptions. You can then use the multiple manifests in one Satellite Server to manage multiple organizations.
If you must manage systems but do not have access to the subscriptions for the RPMs, you must use Red Hat Enterprise Linux Satellite Add-On. For more information, see Satellite Add-On.
The following diagram shows two Red Hat Network account holders, who want their systems to be managed by the same Satellite installation. In this scenario, Example Corporation 1 can allocate any subset of their 60 subscriptions, in this example they have allocated 30, to a manifest. This can be imported into the Satellite as a distinct Organization. This allows system administrators the ability to manage Example Corporation 1’s systems using Satellite completely independently of Example Corporation 2’s organizations (R&D, Operations, and Engineering).
Figure 10.1. Satellite Server with multiple manifests
When creating a Red Hat subscription manifest:
- Add the subscription for Satellite Server to the manifest if planning a disconnected or self-registered Satellite Server. This is not necessary for a connected Satellite Server that is subscribed using the Subscription Manager utility on the base system.
- Add subscriptions for all Capsule Servers you want to create.
- Add subscriptions for all Red Hat products you want to manage with Satellite.
- Note the date when the subscriptions are due to expire and plan for their renewal before the expiry date.
- Create one manifest per organization. You can use multiple manifests and they can be from different Red Hat subscriptions.
Red Hat Satellite allows the use of future-dated subscriptions in the manifest. This enables uninterrupted access to repositories when future-dated subscriptions are added to a manifest before the expiry date of existing subscriptions.
Note that the Red Hat subscription manifest can be modified and reloaded to Satellite Server in case of any changes in your infrastructure, or when adding more subscriptions. Manifests should not be deleted. If you delete the manifest from the Red Hat Customer Portal or in the Satellite web UI it will unregister all of your content hosts.
10.5. Host group structures
The fact that host groups can be nested to inherit parameters from each other allows for designing host group hierarchies that fit particular workflows. A well planned host group structure can help to simplify the maintenance of host settings. This section outlines four approaches to organizing host groups.
Figure 10.2. Host group structuring examples
- Flat structure
- The advantage of a flat structure is limited complexity, as inheritance is avoided. In a deployment with few host types, this scenario is the best option. However, without inheritance there is a risk of high duplication of settings between host groups.
- Lifecycle environment based structure
- In this hierarchy, the first host group level is reserved for parameters specific to a lifecycle environment. The second level contains operating system related definitions, and the third level contains application specific settings. Such structure is useful in scenarios where responsibilities are divided among lifecycle environments. For example, if there is a dedicated owner for the Development, QA, and Production lifecycle stages.
- Application based structure
- This hierarchy is based on roles of hosts in a specific application. For example, it enables defining network settings for groups of back-end and front-end servers. The selected characteristics of hosts are segregated, which supports Puppet-focused management of complex configurations. However, the content views can only be assigned to host groups at the bottom level of this hierarchy.
- Location based structure
- In this hierarchy, the distribution of locations is aligned with the host group structure. In a scenario where the location or Capsule Server topology determines many other attributes, this approach is the best option. However, this structure complicates sharing parameters across locations, therefore in complex environments with a large number of applications, the number of host group changes required for each configuration change increases significantly.
10.6. Inter-Satellite Synchronization scenarios
Red Hat Satellite uses Inter-Satellite Synchronization (ISS) to synchronize content between two Satellite Servers including those that are air gapped.
You can use ISS in cases such as:
- If you want to copy some but not all content from your Satellite Server to other Satellite Servers. For example, you have content views that your IT department consumes from Satellite Server, and you want to copy content from those content views to other Satellite Servers.
- If you want to copy all Library content from your Satellite Server to other Satellite Servers. For example, you have products and repositories that your IT department consumes from Satellite Server in the Library, and you want to copy all products and repositories in that organization to other Satellite Servers.
You cannot use ISS to synchronize content from Satellite Server to Capsule Server. Capsule Server supports synchronization natively. For more information, see Capsule Server Overview in Overview, concepts, and deployment considerations.
There are different ways of using ISS. The way you can use depends on your multi-server setup that can fall to one of the following scenarios.
10.6.1. ISS network sync in a disconnected scenario
In a disconnected scenario, there is the following setup:
- The upstream Satellite Server is connected to the Internet. This server consumes content from the Red Hat Content Delivery Network (CDN) or custom sources.
- The downstream Satellite Server is completely isolated from all external networks.
- The downstream Satellite Server can communicate with a connected upstream Satellite Server over an internal network.
Figure 10.3. Satellite ISS disconnected scenario
You can configure your downstream Satellite Server to synchronize content from the upstream Satellite Server over the network.
10.6.2. ISS export sync in an air-gapped scenario
In an air-gapped scenario, there is the following setup:
- The upstream Satellite Server is connected to the Internet. This server consumes content from the Red Hat CDN or custom sources.
- The downstream Satellite Server is completely isolated from all external networks.
- The downstream Satellite Server does not have a network connection to a connected upstream Satellite Server.
Figure 10.4. Satellite ISS air-gapped scenario
The only way for an air-gapped downstream Satellite Server to receive content updates is by exporting payload from the upstream Satellite Server, bringing it physically to the downstream Satellite Server, and importing the payload. For more information, see Synchronizing Content Between Satellite Servers in Managing content.
You can configure your downstream Satellite Server to synchronize content by using exports.
10.7. Deploying Satellite on AWS
You can run Satellite Server, Capsule Servers, and hosts in your Amazon Web Services (AWS) environment. You can deploy Satellite on Amazon Web Services (AWS) in several scenarios.
One-region setup
This is the least complex configuration of Satellite in AWS. Deploy both Satellite Server and the hosts residing within the same region and within the Virtual Private Cloud (VPC) You can also use a different availability zone.
Connecting on-premises and AWS region
Create a VPN connection between the on-premises location and the AWS region where your Capsule Server is located. It is also possible to use the external host name of Satellite Server when you register the instance that runs Capsule.
Site-to-site VPN connection between the AWS region and the on-premises data center
Direct connection using the external DNS host name
Connecting different regions
Create a site-to-site VPN connection between different regions so that you can use the internal DNS host name when you register the instance that runs Capsule to Satellite Server. If you do not establish a site-to-site VPN connection, use the external DNS host name when you register the instance that runs Capsule to Satellite Server.
Most public cloud providers do not charge for data being transferred into a region or between availability zones within a single region. However, they charge for data leaving the region to the Internet.
Site-to-site VPN connection between AWS regions
Direct connection using the external DNS host name
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}