Installation guide

Chapter 3. Example Topologies
The RHN Satellite can be configured in multiple ways . Select one method depending on the following
factors:
The total number of client s ystems to be served by the RHN Satellite.
The maximum number of clients expected to connect concurrently to the RHN Satellite.
The number of custom packages and channels to be served by the RHN Satellite.
The number of RHN Satellites being used in the customer environment.
The number of RHN Proxy Servers being used in the customer environment.
The rest of this chapter describes possible configurations and explains their benefits.
3.1. Single Satellite Topology
The simplest configuration is to use a single RHN Satellite to serve your entire network. This
configuration is adequate to service a medium-size group of clients and network.
The disadvantage of using one RHN Satellite is that performance will be compromised as the number of
clients reques ting packages grows.
Figure 3.1. Single Sat ellit e T opology
3.2. Multiple Satellite Horizontally Tiered Topology
For very large networks, a more distributed method may be needed, such as having multiple RHN
Satellites in a horizontally tiered configuration and balancing the load of client requests .
It is possible to synchronize content between RHN Satellites using the rhn-satellite-exporter
and satellite-sync -m commands. This feature is discus sed in detail in Section 6.1.1, “rhn-
satellite-exporter”. Alternatively, the Inter-Satellite Sync 2 feature is designed for this purpos e.
Additional maintenance is the biggest disadvantage of this horizontal s tructure.
Figure 3.2. Mult iple Sat ellit e Horizontally T iere d T opology
3.3. Satellite-Proxy Vertically Tiered Topology
An alternative method to balance load is to install RHN Proxy Servers below a RHN Satellite. These
Proxies connect to the Satellite for RPMs from Red Hat Network and custom packages created locally. In
ess ence, the Proxies act as clients of the Satellite.
This vertically tiered configuration requires that channels and RPMs be created only on the RHN
Satellite. In this manner, the Proxies inherit and then serve packages from a central location. For details,
refer to the RHN Channel Management Guide.
Similarly, you should make the Proxies' SSL certificates clients of the Satellite while also setting them to
serve the client systems. This process is described in the RHN Client Configuration Guide.
Figure 3.3. Sa te llit e- Proxy Vert ically T iered T opology
Chapter 3. Example Topologies
13