Planning for Installation¶
Operating System¶
Altair SLC Hub is supported on Linux and Microsoft Windows operating systems.
Altair SLC Hub software is currently only supported on RPM based RedHat family Linux distributions equivalent to RHEL version 8 or later. Support for other Linux distributions may be added in future releases. Contact Altair support if you have a requirement for alternative platforms.
Altair SLC Hub software is supported on Windows.
Reference Architectures¶
The Altair SLC Hub can run in corporate networks and with cloud providers.
The following image displays the structure of an Altair SLC Hub:
The Altair SLC Hub consists of a Server machine and a number of Worker machines (Worker Nodes). There is a PostgreSQL Database backing the Altair SLC Hub and an Object Store to preserve the results from Jobs and Pipelines. There is a Shared File System between the Server and all the Workers.
Authentication and identity management is handled by Keycloak, which is bundled with Altair SLC Hub and does not require a separate installation. Keycloak can connect to your organisation's LDAP or Active Directory server to federate users, and supports external identity providers via SAML and OIDC. The Altair SLC Hub may be connected to an E-mail Server to allow the sending of e-mails. Email is configured through Keycloak.
The Altair SLC Hub server coordinates all activity in the system and communicates with each Worker node to distribute and manage workloads. Worker nodes execute jobs and report their status back to the Altair SLC Hub. In addition, the Altair SLC Hub connects to supporting services such as the database, object store, and Keycloak as required.
Examples of reference configurations in cloud providers are given below:
Examples of Terraform and Ansible scripts to setup a Altair SLC Hub in different cloud providers are available from github.
Note
This section describes the storage services that must be prepared before installation. For a conceptual overview of how Altair SLC Hub uses PostgreSQL, object storage, and the shared filesystem, see Storage Architecture.
Altair SLC¶
The Worker Nodes require an installation of Altair SLC. The minimum required version is 2023.1. See Altair SLC Compatibility for more information about compatible versions of Altair SLC.
Host permissions¶
Ensure that you have Administrator (root) privileges on the host for installation.
None of the post-installation configuration steps will require Administrator privileges.
Ensure that you have local Administrator privileges on the host. Only machine level installation is supported, not user level installation.
Most of the post-installation configuration steps will also require Administrator privileges.
Web Browser¶
The main user interface for the Altair SLC Hub software is provided as a web application. Supported browsers are:
- Google Chrome
- Mozilla Firefox
- Microsoft Edge
In all cases, the currently supported released versions of the browser are supported by Altair SLC Hub.
Ingress¶
Altair SLC Hub allows different network configurations in a variety of platforms.
It is important to understand the concept of the ingress address of the Altair SLC Hub, and the internal ingress address. The ingress address is the address that browsers and other client will use to access the Altair SLC Hub. The internal ingress address is the address that workers will use to access the Altair SLC Hub.
These internal and external ingress addresses may be the same, as is often the case in corporate networks. The diagram below is an example of machines in a corporate network where the Altair SLC Hub ingress address is the same as the internal ingress address, and the Altair SLC Hub is accessed directly by the hub.company.com address.
In different configurations, such as cloud providers, the ingress address of the Altair SLC Hub may be different from the internal ingress address. The diagram shows an example where the Altair SLC Hub ingress address is hub.external.com, but each machine within the internal network communicates with a .company.internal address.
Note
It is important to understand how the machines will communicate with each other so that the addresses can be configured correctly during the installation. Different ingress addresses, or non-default internal ingress addresses will need to be configured manually as these cannot be detected automatically.
HTTPS¶
Altair SLC Hub requires HTTPS to be configured. Keycloak, which handles authentication, requires a secure browser context. This means HTTPS is mandatory and cannot be skipped.
You will need a valid TLS certificate for your Altair SLC Hub ingress address. Plan for this before installation, as obtaining a signed certificate from your organisation's IT department may take time.
There are two ways to obtain a certificate:
Recommended — use your organisation's certificate authority¶
Generate a Certificate Signing Request (CSR) using hubctl generate externalcsr, have it signed by
your organisation's certificate authority, and provide the resulting certificate during
installation. See Get A Certificate for more details.
For temporary use only — generate a self-signed certificate¶
Use hubctl generate externalcert to generate a local certificate authority and issue a
certificate from it. Browsers will not trust this certificate by default and users will see
a security warning. This is only appropriate while waiting for a certificate from your IT
department and must not be used in production. See Generating external certificates for testing for more details.
Warning
Do not use a self-signed certificate in a production environment. Plan to obtain a certificate signed by a trusted certificate authority before go-live.
Database¶
Altair SLC Hub requires a PostgreSQL database for storing application data. PostgreSQL 13 or later is supported.
PostgreSQL stores structured application data such as users, pipeline definitions, job metadata, job status, application state, access control logs, and references to files stored in object storage. It stores metadata and system state, not the file contents produced by jobs.
Altair SLC Hub provides a database that can be used with no further configuration. However, we recommend providing your own database for production deployments.
When installing Altair SLC Hub in a cloud environment, we recommend using the cloud provider's native PostgreSQL offering. This typically provides better availability, simpler backup and restore procedures, and reduced operational overhead.
In a production environment, you may use an external database on separate infrastructure to support replication, integration with existing servers, and similar operational requirements. You may also run an external database on the Altair SLC Hub server to enable more sophisticated setups.
For simpler setups, you can use the internal database provided with Altair SLC Hub.
Note
In all cases, backup procedures should be considered carefully. Backups should be taken regularly and stored externally in line with standard best practices.
Altair SLC Hub requires a dedicated logon user in the database instance. The credentials for this user are supplied to Altair SLC Hub in the configuration files.
Warning
Storing database credentials in HashiCorp Vault is no longer supported. This feature has been removed because Keycloak, which now handles authentication, cannot retrieve its database password from Vault. If your deployment previously used Vault-managed database credentials, you will need to supply static credentials in the configuration files instead.
The Altair SLC Hub database user must have full permissions on the database instance, including CREATE permission.
During the installation or upgrade process the Altair SLC Hub bootstrap utility is run to ensure that the correct database schemas exist in the database.
When planning database deployment, consider:
- backup and disaster recovery requirements
- replication and availability requirements
- integration with existing database infrastructure
- network connectivity between Altair SLC Hub components and the database
- database sizing, growth, and performance requirements
- expected growth in access control logs and job metadata
Object Store¶
Altair SLC Hub requires object storage in addition to a PostgreSQL database.
Object storage is used for file-based data managed by Altair SLC Hub, including job results, job logs, uploaded artefacts, and outputs passed between pipeline steps using results. It stores file content, while PostgreSQL stores metadata and system state.
For cloud deployments, use the cloud provider's managed object storage service where possible. This typically provides better availability, simpler backup and restore procedures, and reduced operational overhead.
In a production environment, you may use an external object store on separate infrastructure to support replication and similar operational requirements. You may also run an external object store on the Altair SLC Hub server to support more sophisticated deployment scenarios.
For simpler setups, you can use the internal object store provided with Altair SLC Hub.
Note
In all cases, backup procedures should be considered carefully. Backups should be taken regularly and stored externally in line with standard best practices.
Altair SLC Hub officially supports S3-compatible object stores. Compatibility has been tested with:
- Amazon S3 in AWS
- MinIO
- SeaweedFS
Contact Altair support if you have a requirement for an alternative object store.
Altair SLC Hub requires a dedicated logon user in the object store and a dedicated bucket for its use.
When planning object storage, consider:
- expected volume of job results and logs
- uploaded artefact storage
- retention and cleanup policies
- backup and disaster recovery requirements
- replication and availability requirements
- network connectivity between Altair SLC Hub components and the object store
Instructions on installing and configuring MinIO locally for use by Altair SLC Hub are available in the Altair Community.
Shared Filesystem¶
Certain features of Altair SLC Hub require a shared filesystem that is mounted on both the Altair SLC Hub server node and all worker nodes.
Altair SLC Hub allows workloads to run on a pool of worker nodes. These workloads may need access to file-based resources such as data files or program source files. Because the workload can be run on any of the worker nodes in the pool, those file resources need to be accessed in a consistent way regardless of the worker on which the workload is run. File resources therefore need to be on a shared filesystem that was mounted into each worker node in the same way.
The Altair SLC Hub server node also requires access to the same shared filesystem. The Altair SLC Hub server provides access to these shared filesystem locations through a WebDAV interface, so those locations must also be available to the Altair SLC Hub server node. Therefore, even in a Altair SLC Hub environment with only one worker node, a shared filesystem must still be available to both the worker node and the server node.
Authentication and Users¶
Altair SLC Hub uses Keycloak to handle authentication. Keycloak is bundled with Altair SLC Hub and does not need to be installed separately. Before installation, you should decide how your users will authenticate, as this affects what you need to have ready.
Authentication sources¶
Altair SLC Hub supports the following sources of users:
| Source | Description |
|---|---|
| LDAP / Active Directory | Keycloak connects to your directory server and federates users into Altair SLC Hub. This is the most common setup for organisations with an existing directory. See LDAP Configuration. |
| SAML identity provider | Users authenticate via your organisation's SAML IdP — for example, Azure AD, Okta, or ADFS. Keycloak acts as the service provider. See SAML Configuration. |
| OIDC identity provider | Users authenticate via an OIDC-compliant provider. Keycloak brokers the identity into Altair SLC Hub. See OIDC Configuration. |
These sources can be used in combination. Authentication sources are configured in the Keycloak admin console after installation. For details, see Keycloak Overview.
Note
User and group management in the Altair SLC Hub portal is unchanged. Altair SLC Hub continues to manage which users and groups have access to which resources. Keycloak handles how those users authenticate.
OS user mapping — plan this before installation¶
All workloads in Altair SLC Hub run as OS users. Security relies on OS-level permissions. It is therefore important that every Altair SLC Hub user maps correctly to an OS user on the Altair SLC Hub server and all worker nodes.
Regardless of which authentication source you use, the following attributes must be available for each user and correctly mapped through Keycloak:
| Attribute | Description |
|---|---|
| Unix username | The OS-level username Altair SLC Hub uses to run jobs |
| UPN (User Principal Name) | Used for user identification and authentication |
| Unix user home path | The home directory Altair SLC Hub uses when running jobs |
If these attributes are missing or incorrectly mapped, Altair SLC Hub cannot run jobs as the correct user. This is the most common source of problems when setting up user federation or identity providers.
The most reliable way to ensure consistent OS user mapping across the Altair SLC Hub server and all worker nodes is to have all machines joined to the same domain, with Keycloak federating users from that domain's LDAP or Active Directory server.
If you are using a SAML or OIDC identity provider, your IdP must be configured to release these attributes in the assertion or token, and they must be mapped in Keycloak before users can run jobs.
Network Communication Requirements¶
The Altair SLC Hub deployment consists of an Altair SLC Hub server and one or more Worker nodes. For the system to function correctly:
- The Altair SLC Hub server must be able to communicate with all Worker nodes
- Worker nodes must be able to communicate with the Altair SLC Hub server
If this communication is blocked by firewall rules or network restrictions, workloads may fail or remain in a pending state.
Ports and Firewalls¶
Communication between the Altair SLC Hub server and Worker nodes, and access from client machines, is performed over TCP, routed through the Altair SLC Hub ingress server.
Therefore, the only port that needs to be available to client machines (machines outside of the Altair SLC Hub cluster) is the
ingress port on the Altair SLC Hub server machine. By default this is port 9090, but can be changed if required (see Verify Ingress for details).
Within the Altair SLC Hub cluster, various ports need to be available.
Ports 4647, 9091 and 9093 need to be available for communication between the Altair SLC Hub server and workers. In addition, Altair SLC Hub will allocate dynamic ports on Altair SLC Hub worker machines in a range 20000-32000. This range can be changed if required (see Dynamic Port Range Configuration for details). However, the whole range of ports must be visible to the Altair SLC Hub server.
When Altair SLC Hub is installed on a Windows server, the installer ensures that appropriate firewall rules are added to the operating system for the processes that need to expose ports.
Verify Communication¶
To verify communication between the Altair SLC Hub server and Worker nodes, including TLS communication, see the hubctl portcheck documentation.
Summary¶
| Machine type | Port range | Visibility |
|---|---|---|
| Altair SLC Hub Server | 9090 (default) | Altair SLC Hub clients outside cluster |
| Altair SLC Hub Server | 9091, 9093 | Altair SLC Hub workers |
| Altair SLC Hub Server | 4647 | Altair SLC Hub workers |
| Altair SLC Hub Worker | 4647 | Altair SLC Hub server (not other workers) |
| Altair SLC Hub Worker | 20000-32000 | Altair SLC Hub server (not other workers) |
Hardware requirements¶
Memory¶
16GB of RAM is recommended.
Installation hard drive space¶
The initial Altair SLC Hub software installation requires up to 2GB of hard drive space.
Operational hard drive space¶
Log files for the Altair SLC Hub services are captured by systemd and in a default Linux installation are stored by journald. The disk space taken up by the log files is therefore managed by journald and limits can be configured using the standard mechanisms of journald. It is recommended that 50MB of log file space be allowed for Altair SLC Hub log files.
The log files are written to a log directory. Each of the services maintains its own log file. The log files are managed using a rolling strategy, with each service maintaining a maximum of 8 files, each of which can be up to 10MB in size.
The amount of disk space used by the database and the object store will depend on use.
The amount of disk space required by running jobs will depend on use.
It is recommended to have at least twice the amount of fast disk space available as memory on high load clusters as some services will store snapshots of their state to disk.
This particularly applies to the [var directory]/nomad directory.
CPU¶
Main server¶
The suggested starting point for evaluation and small workloads is four virtual CPUs. In an AWS environment one m5a.xlarge (or m5.xlarge) would be appropriate.
The number of virtual CPUs can be scaled up as necessary when traffic increases.
Worker nodes¶
In an AWS environment a small number of larger servers is recommended to support memory intensive workloads. The use of burst CPU is not recommended.
The suggested starting point is 16 virtual CPUs.
One m5ad.4xlarge would support datasets up to a maximum size of 600 GiB.
If larger datasets must be supported then an i3.4xlarge has 3.8 TB of storage.
Note
When running the Altair SLC Hub for test purposes these requirements can be greatly reduced. A single virtual CPU and 8 GiB of storage is usually sufficient.