Understanding Management Stations

A system assigned the role of management station mirrors and distributes software sources to instances on premises or in supported third-party clouds. A station also acts as network proxy for instances to communicate with OS Management Hub in Oracle Cloud Infrastructure.

Note

Management stations aren't used by OCI instances.

What is a management station?

A management station is an instance that mirrors and distributes software sources to other on-premises or third-party cloud instances. The station also acts as network proxy for non-OCI instances to communicate with OS Management Hub in Oracle Cloud Infrastructure. The system acting as the station has specific requirements to efficiently serve client instances.

Do I need a station?

If managing on-premises or third-party cloud instances, you must have at least one station to serve software source content to those instances. Stations aren't used for OCI instances.

You must create and register a station before registering on-premises or third-party cloud instances. The number of instances a station can support depends on the station's memory and processing power, and the speed of the data center network.

You can deploy multiple stations within a customer data center or third-party cloud. You can also configure multiple management stations in a highly-available configuration.

How do I maintain the station instance?

By default, only Oracle Linux 8 BaseOS and Appstream software sources are attached to the management station instance. To update the station instance, you need to first attach any additional software sources and then create an update job. The software sources that you attach to the station are different and separate from the sources mirrored and distributed to other instances by the station.

What data is stored in OCI for stations?

Capacity (percentage free) of mirror storage
reposync command output

Note

If the management station is also being managed and updated using OS Management Hub, its instance information is also collected.

System Requirements

A management station has several requirements to efficiently serve client instances in a data center.

Oracle Linux requirements

A management station requires Oracle Linux 8 (minimum 8.7, Oracle Linux 9 isn't supported) on an x86_64 bare metal server or virtual machine in the data center or supported third-party cloud. Don't register a station with the Unbreakable Linux Network (ULN) or other content delivery systems. After the station registers, OS Management Hub provides the station instance with updates. See How do I maintain the station instance?.

CPU and memory requirements

A management station system requires a minimum of four CPU cores and 16 GB of RAM.

Networking requirements

Management stations must have connectivity to OS Management Hub in OCI on port tcp/443. If the station requires a forwarding proxy to reach OCI, you provide that information when creating the station.

Management stations require connectivity to client instances on the local network. When you create a station, you specify a proxy listening port and two mirror listening ports. These TCP ports must be open on the network between the station and its clients. We also recommend a 10 Gigabit network between the station and client instances.

Storage requirements

A management station mirrors Oracle Linux software sources to serve content locally to on-premises or third-party cloud instances. Storage space for a station can be significant. It depends on the number, size, and scope of the mirrored software sources. Stations that serve multiple versions of Oracle Linux can require several hundred gigabytes to several terabytes of disk space. Ensure /var/cache/dnf has enough storage for repository metadata.

We recommend you:

Allocate the mirror storage separate from the root file system.
Use a network volume for the mirror using NFS or iSCSI to make disaster recovery easier (or use shared storage in a highly-available configuration).
Use the Size listed in the software source list to plan volume size. In general:
- Ksplice software sources can require 1 TB to 5 TB of storage per repository.
- Large software sources can require 100 MB to 200 MB of storage per repository.

Important

Packages are never removed from Oracle Linux repositories. Thus, the space required for each software source always increases. Actively monitor the mirror storage capacity on the station.

Station Health Status

You can view station health when Listing Management Stations or Viewing Management Station Details.

Possible health status's includes:

Healthy: The management station is operating normally and checking in with the service.
Unhealthy: The management station has lost connection with the service (either inactive, offline, or unregistered). Review the agent log on the management station instance to help with troubleshooting.
Unavailable: This is the initial health state of the management station after you first create it. The station remains in this state until you register the station instance.

Mirror Syncing

What is the station mirror?

The management station mirror is a copy of the software sources needed to provide content to on-premises or third-party cloud instances that use the station. It allows on-premises or third-party cloud instances to receive software content from the management station, instead of directly from OS Management Hub. The contents of the mirrored software sources update each time a mirror sync occurs.

Important

The list of mirrored software sources will be empty until you create a profile that uses the station. See Which software sources are mirrored?.

When do mirror syncs occur?

When a station registers with OS Management Hub, the service also creates a recurring scheduled mirror sync job for the station. You can modify the execution time and frequency of the mirror sync job, but you can't delete the sync job.

A mirror sync occurs:

When the recurring scheduled mirror sync job for a management station runs.
When you trigger an immediate mirror sync for specific software sources.
When you update a custom software source that's already mirrored.

What happens during a mirror sync?

When the mirror sync job runs, the station checks if it needs to update the mirrored software sources. The sync job updates the local mirror with the any changes in the software sources. The station also checks for new software sources to add to the local mirror.

Which software sources are mirrored?

After registering a management station, initially the list of mirrored software sources is empty. OS Management Hub updates the mirror list dynamically based on the profiles and instances that use the station.

To initialize and sync a station before registering instances, you can create the registration profiles needed for instances that will use the station. The service identifies the software sources used by the profiles and adds them to the station mirror list. As you create new profiles or attach new software sources to instances, the station mirror list updates automatically. If you delete profiles or detach software sources from instances, mirror list entries are only removed if no instances or profiles reference the software source.

When mirroring custom software sources, the management station also mirrors any vendor software sources that the custom software source relies on. When a station no longer needs to mirror a software source, it's immediately deleted from the mirror volume.

If using a high availability (HA) configuration, the mirror list is unified across all stations. A profile or instance referencing one of the stations also updates the mirrored software sources on all other stations in the HA configuration. When using shared mirror storage with HA, the software source mirror sync status on a management station might incorrectly show as 'Unsynced'. See Known Issue: 'Unsynced' status on stations using shared storage.

Are third-party and private software sources mirrored?

When adding a third-party or private source you select whether the source will be mirrored to management stations. If mirroring is enabled, the third-party or private source is mirrored to stations when an instance or profile associated with the station references the source. See Which software sources are mirrored?

Example mirrored software source list

Consider a case where you've created a profile that uses the station, but haven't registered instances yet. The following table lists the software sources associated with the profile and the resulting mirror list.


Profile 1	List of Mirrored Software Sources
`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_addons-x86_64`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_addons-x86_64`

Next let's look at what happens when you:

The software sources defined in the profile are attached to each instance. The mirror list remains the same as no new sources have been added or removed.


Profile 1	Instance 1	Instance 2	List of Mirrored Software Sources
`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_addons-x86_64`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_addons-x86_64`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_addons-x86_64`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_addons-x86_64`

Next, let's look at what happens if:

Instance 1 attaches a software source (ol8_custom_source which is based on ol8_developer-x86_64).
Instance 1 and 2 each detach a software source (ol8_addons-x86_64).

The list of software sources on the management station updates to reflect the change. The service adds ol8_custom_source and ol8_developer-x86_64 to the list because Instance 1 is using ol8_custom_source which depends on ol8_developer-x86_64. The source ol8_addons-x86_64 remains on the station because Profile 1 is still referencing it.


Profile 1	Instance 1	Instance 2	List of Mirrored Software Sources
`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_addons-x86_64`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` Detach:`ol8_addons-x86_64` Attach: `ol8_custom_source`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` Detach: `ol8_addons-x86_64`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_addons-x86_64` (not removed because Profile 1 uses this source) Added: `ol8_custom_source` Added: `ol8_developer-x86_64`

Finally, let's look at what happens when you delete Profile 1.

Software source ol8_addons-x86_64 is removed from the list because it's no longer used by a profile or instance.


Profile 1	Instance 1	Instance 2	List of Mirrored Software Sources
Deleted	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` `ol8_custom_source`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64`	`ol8_baseos_latest-x86_64` `ol8_appstream-x86_64` Removed:`ol8_addons-x86_64` `ol8_custom_source` `ol8_developer-x86_64`

Oracle Cloud Infrastructure Documentation