Words and Phrases
SA Satellites
A Satellite installation can be a solution for remote sites that do not have a large enough number of potentially Managed Servers to justify a full SA Core installation. A Satellite installation allows you to install only the minimum necessary Core Components on the Satellite host which then accesses the Primary Core’s database and other services through an SA Gateway connection.
A Satellite installation can also relieve bandwidth problems for remote sites that may be connected to a primary facility through a limited network connection. You can cap a Satellite’s use of network bandwidth to a specified bit rate limit. This allows you to ensure that Satellite network traffic will not interfere with your other critical systems network bandwidth requirements on the same pipe.
A Satellite installation typically consists of, at minimum, a Satellite Gateway and a Software Repository Cache and still allows you to fully manage servers at a remote facility. The Software Repository Cache contains local copies of software packages to be installed on Managed Servers in the Satellite while the Satellite Gateway handles communication with the Primary Core.
You can optionally install the SA Provisioning Boot Server and Media Server on the Satellite host to support remote SA Provisioning. Installing other components on the Satellite host is not supported.
Satellite Topology examples
A simple Single-Core-to-Satellite link
The following figure shows a single Satellite linked to a Single Core. In this example, the main facility is in San Francisco, and a smaller remote facility is in San Jose.
The San Francisco Single Core consists of several components, including the Software Repository, the Model Repository, an Agent gateway, and a Management Gateway. For simplicity, this figure does not show all required Core Components, such as the Command Engine.
The San Jose Satellite consists of a Software Repository Cache, an Satellite Gateway, and an optional SA Provisioning Boot server and Media Server.
The San Jose Satellite’s Software Repository Cache contains local copies of software packages to be installed on Managed Servers in that facility.
The Server Agents installed on managed servers at the San Jose facility connect to the San Francisco core through the San Jose Satellite Gateway, which communicates with the San Francisco Management Gateway, then through the San Francisco Core gateway, ultimately, with the required Core Components.
Return communication reverses that path. The Server Agents installed on managed servers in the San Francisco facility communicate with the Core Components through the San Francisco facility’s Agent and Core Gateways.
A two-Satellite-to-single-Core link
The following figure shows two Satellites linked to a Single Core. In this example, San Francisco is the main facility, and Sunnyvale and San Jose are Satellite facilities.
The following figure shows cascading Satellites, a topology in which Satellite Gateways are connected in a chain. This topology enables you to create a hierarchy of Software Repository Caches. Note that the Satellite Gateways in this topology must belong to different SA Realms.
When tasked to install a package on a managed server in the Los Angeles facility, SA first checks to see if the package resides in the Software Repository Cache in Los Angeles. If the package is not in Los Angeles, then SA checks the Software Repository Cache in San Jose. Finally, if the package is not in San Jose, SA goes to the Software Repository in the San Francisco core. For more information, see the SA
Satellites in a Multimaster Mesh
The following figure shows the San Jose Satellite connected to two SA Cores in a Multimaster Mesh.
Even when communication is possible to both Los Angeles and San Francisco, the Management Gateway chooses the route with the lowest cost (in this figure, it is the San Francisco route). You control cost evaluation using a parameter specified during Gateway installation. System designers can specify rules governing which SA Gateway routes to use to minimize network connectivity costs.
Using the same example environment in a failover scenario, during normal operations, the servers in the San Jose Satellite are managed by the San Francisco Core. Note, however, that the San Francisco and the Los Angeles Cores are directly connected through their Management Gateways.
If the connection between the San Jose Satellite and the San Francisco Core fails, the San Jose Satellite Gateway can move communications immediately from San Francisco to the Los Angeles core, allowing that core to maintain management of the San Jose servers. The Los Angeles Core will have up-to-date information about the San Jose site, because the San Francisco Core’s Model Repository data will have been replicated to the Los Angeles Model Repository as a part of normal SA operations.
Satellite With multiple gateways in a Multimaster Mesh
The following figure shows a topology that provides failover capability in two ways. First, the San Jose Satellites 1 and 2 have Gateway connections to both the San Francisco and Los Angeles Management Gateways. If the Los Angeles core becomes unavailable, the San Francisco core can still manage the servers in the San Jose Satellite.
Second, the Agents installed on the Managed Servers in the San Jose Facility point to both of the Satellite’s Agent Gateways. SA Agents automatically load balance over the available Agent Gateways and therefore can communicate directly with either the San Francisco or Los Angeles cores.
If one Gateway becomes unavailable, the Agents that are using the unavailable gateway as their primary gateway will automatically failover to using the secondary gateway. During routine agent-to-core communication, SA Agents will discover new gateways added to (or removed from) the Satellite.