Hardware Requirements
This table outlines hardware and software requirements for the Uyuni Server and Proxy on x86-64, and ARM architecture.
For Uyuni for Retail hardware requirements, see Retail Requirements.
1. Server Requirements
SLE Micro 5.5 is ths operation system of the container host and requires as free disk space:
-
Minimum for base installation 100 GB
-
Plus a minimum of 130 GB for repository data
By default the Uyuni Server container stores mirrored repository (packages or products), database, and other data in subdirectories of the /var/lib/containers/storage/volumes/ directory.
Repository synchronization fails if this directory runs out of disk space.
Estimate how much space the /var/lib/containers/storage/volumes/ directory requires based on the number and kind of clients and repositories you plan to mirror.
For more information about filesystem and partitioning details, see Persistent Storage and Permissions and the detailed installation instructions in the Installation and Deployment sections of this guide.
| Hardware | Details | Recommendation |
|---|---|---|
CPU |
x86-64, ARM, ppc64le or s390x |
Minimum 4 dedicated 64-bit CPU cores |
RAM |
Minimum |
16 GB |
Recommended |
32 GB |
|
Disk Space |
|
20 GB |
|
Minimum 150 GB (depending on the number of products) |
|
|
Minimum 50 GB |
The images by default have a 20 GB / partition.
The cloud image of SLE Micro 5.5 has just a 5 GB / partition. Both work flawlessly with Uyuni.
As long as external storage is mounted to /var/lib/containers/storage/volumes, Uyuni does not need or use storage on the / partition, but leaves that to the management of the container host itself.
|
Uyuni performance depends on hardware resources, network bandwidth, latency between clients and server, etc. Based on the experience and different deployments that are in use, the advice for optimal performance of Uyuni Server with an adequate number of proxies is to not exceed 10,000 clients per single server. It is highly recommended to move to the Hub setup and involve consultancy when you have more than 10,000 clients. Even with fine-tuning and an adequate number of proxies, such a large number of clients can lead to performance issues. For more information about managing a large number of clients, see Multiple Servers with Hub to Manage Large Scale Deployments. |
2. Proxy Requirements
| Hardware | Details | Recommendation |
|---|---|---|
CPU |
x86-64, ARM |
Minimum 2 dedicated 64-bit CPU cores |
RAM |
Minimum |
2 GB |
Recommended |
8 GB |
|
Disk Space |
|
Minimum 40 GB |
|
Minimum 150 GB |
By default the Uyuni Proxy container caches packages in the /var/lib/containers/storage/volumes/uyuni-proxy-squid-cache/ directory.
If there is not enough space available, the proxy will remove old, unused packages and replace them with newer packages.
As a result of this behavior:
-
The larger
/var/lib/containers/storage/volumes/var-cache/directory is on the proxy, the less traffic will be between the proxy and the Uyuni Server. -
By making the
/var/lib/containers/storage/volumes/var-cache/directory on the proxy the same size as/var/lib/containers/storage/volumes/var-spacewalk/on the Uyuni Server, you avoid a large amount of traffic after the first synchronization. -
The
/var/lib/containers/storage/volumes/var-cache/directory can be small on the Uyuni Server compared to the proxy. For a guide to size estimation, see the Server Requirements section.
3. Database Requirement
PostgreSQL is the only supported database. Using a remote PostgreSQL database or remote file systems (such as NFS) with the PostgreSQL database is not supported. In other words, PostgreSQL should be on the fastest available storage device for Uyuni.
|
Because of potential performance issues, running a PostgreSQL database remotely from Uyuni is discouraged. While such an environment is possible and even stable in many cases, there is always a risk of data loss if something goes wrong. |
4. Persistent Storage and Permissions
Persistent volumes are created by default when deploying the container.
However, it is recommended that the volumes are stored on one or more separate storage devices. Such a setup helps avoid data loss in production environments. This can be done after container deployment.
Storage devices best should be set up after first deploying the container. For more details, see Persistent Container Volumes.
We recommend you use XFS as the filesystem type for all volumes. The size of the disk for repositories storage is dependent on the number of distributions and channels you intend to manage with Uyuni. See the tables in this section for guides to estimate the size required.
On the Uyuni Server, use this command to find all available storage devices:
hwinfo --disk | grep -E "Device File:"
Use the lsblk command to see the name and size of each device.
Use the mgr-storage-server command with the device names to set up the external disks as the locations for the storage and, optionally on a disk of its own, for the database:
mgr-storage-server <storage-disk-device> [<database-disk-device>]
The external storage volumes are set up as XFS partitions mounted at /manager_storage and /pgsql_storage.
It is possible to use the same storage device for both channel data and the database.
This is not recommended, as growing channel repositories might fill up the storage, which poses a risk to database integrity.
Using separate storage devices may also increase performance.
If you want to use a single storage device, run mgr-storage-server with a single device name parameter.
If you are installing a proxy, the mgr-storage-proxy command takes only one device name parameter and will set up the external storage location as the Squid cache.
5. Logical Volume Management (LVM)
For all kind of virtual machines (VM), LVM is generally not needed and not recommended. The disk setup is virtual and separate disks for volumes are possible and recommended.
For other deployments, separate disks for volumes are also recommended.
On the Uyuni Server, the mgr-storage-server command moves the complete content of the /var/lib/containers/storage/volumes directory to a separate disk and remounts it to /var/lib/containers/storage/volumes.
Optionally, if a second device name is specified, mgr-storage-server moves the content of the /var/lib/containers/storage/volumes/var-pgsql database directory to a second separate disk and remounts it to /var/lib/containers/storage/volumes/var-pgsql.
Similarily on the Uyuni Proxy, the mgr-storage-proxy command moves the complete content of the /var/lib/containers/storage/volumes directory to a separate disk and remounts it to /var/lib/containers/storage/volumes.