Running all the Trento Server components requires a minimum of 4 GB of RAM, two CPU cores and 64 GB of storage. When using K3s, such storage should be provided under /var/lib/rancher/k3s.

Trento is based on event-driven technology. Registered events are stored in a PostgreSQL database with a default retention period of 10 days. For each host registered with Trento, you need to allocate at least 1.5GB of space in the PostgreSQL database.

Trento Server supports different deployment scenarios: Kubernetes, systemd, and containers. A Kubernetes-based deployment of Trento Server is cloud-native and OS-agnostic. It can be performed on the following services:

A production-ready Kubernetes-based deployment of Trento Server requires Kubernetes knowledge. The Helm chart is intended to be used by customers without in-house Kubernetes expertise, or as a way to try Trento with a minimum of effort. However, Helm chart delivers a basic deployment of the Trento Server with all the components running on a single node of the cluster.

An SAP system must run on a HANA database to be discovered by Trento. In addition, the parameter dbs/hdb/dbname must be set in the DEFAULT profile of the SAP system to the correct database (tenant) name.

The resource footprint of the Trento Agent is designed to not impact the performance of the host it runs on.

The Trento Agent component needs to interact with several low-level system components that are part of the SUSE Linux Enterprise Server for SAP applications distribution.

The hosts must have unique machine identifiers (ids) in order to be registered in Trento. This means that if a host in your environment is built as a clone of another one, make sure to change the machine’s identifier as part of the cloning process before starting the Trento Agent on it.

Similarly, the clusters must have unique authkeys in order to be registered in Trento.