Getting started with Trento Premium #

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 powered by event driven technology. Registered events are stored in a PostgreSQL database with a 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.

While the Trento Server supports various usage scenarios, depending on the existing infrastructure, it is designed to be cloud native and OS agnostic. It can be installed on the following services:

A proper, production ready installation of Trento Server requires Kubernetes knowledge. The Helm chart is meant to be used by customers lacking such knowledge or who want to get started quickly. However, Helm chart delivers a basic deployment of the Trento Server with all the components running on a single node of the cluster.

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.

Trento requires unique machine identifiers (ids) on the hosts to be registered. Therefore, if any host in your environment is built as a clone of another one, ensure that you change the machine identifier as part of the cloning process before starting the Trento Agent on it.

Trento Server consists of a few components which are delivered as container images and meant to be deployed on a Kubernetes cluster. A manual deployment of these components in a production ready fashion requires Kubernetes knowledge. Customers lacking such knowledge or who want to get started quickly with Trento, can use the Trento Helm chart. This approach automates the deployment of all the required components on a single Kubernetes cluster node. You can use the Trento Helm chart in order to install Trento Server on a existing Kubernetes cluster as follows:

If you do not have a Kubernetes cluster or have one but do not want to use it for Trento, SUSE Rancher's K3s provides you with an easy way to get started. All you need is a small server or VM (see Section 3.1, “Trento Server requirements” for minimum requirements) and follow steps in Procedure 1, “Manually installing Trento on a Trento Server host” to get Trento Server up and running.

Important: Deploying Trento on K3s

The following procedure deploys Trento Server on a single-node K3s cluster. Such set up is not recommended for production purposes.

If you choose to deploy K3s on a VM with a registered SUSE Linux Enterprise Server for SAP Applications 15 distro, you can install the package trento-server-installer and then execute script install-trento-server: it will run Step 2 to Step 5 in Procedure 1, “Manually installing Trento on a Trento Server host” for you automatically.

If you use a multi node Kubernetes cluster, it is possible to deploy Trento Server images on selected nodes by specifying the field nodeSelector in the helm upgrade command, with the following syntax:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set prometheus.server.nodeSelector.LABEL=VALUE \
   --set postgresql.primary.nodeSelector.LABEL=VALUE \
   --set trento-web.nodeSelector.LABEL=VALUE \
   --set trento-runner.nodeSelector.LABEL=VALUE \
   --set grafana.nodeSelector.LABEL=VALUE

Email alerting feature notifies the SAP administrator about important changes in the SAP Landscape being monitored/observed by Trento.

Some of the reported events are:

This feature is disabled by default. It can be enabled at installation time or anytime at a later stage. In both cases, the procedure is the same and uses the following placeholders:

The command to enable email alerting is the following:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set trento-web.alerting.enabled=true \
   --set trento-web.alerting.smtpServer=SMTP_SERVER \
   --set trento-web.alerting.smtpPort=SMTP_PORT \
   --set trento-web.alerting.smtpUser=SMTP_USER \
   --set trento-web.alerting.smtpPassword=SMTP_PASSWORD \
   --set trento-web.alerting.sender=ALERTING_SENDER \
   --set trento-web.alerting.recipient=ALERTING_RECIPIENT

Ingress may be used to provide SSL termination for the Web component of Trento Server. This would allow to encrypt the communication from the agent to the server, which is already secured by the corresponding API key. It would also allow HTTPS access to the Web console with trusted certificates.

Configuration must be done in the tls section of the values.yaml file of the chart of the Trento Server Web component.

For details on the required Ingress setup and configuration, refer to: https://kubernetes.io/docs/concepts/services-networking/ingress/. Particularly, refer to section https://kubernetes.io/docs/concepts/services-networking/ingress/#tls for details on the secret format in the YAML configuration file.

Additional steps are required on the Agent side.

The dashboard allows you to determine at a glance the health status of your SAP environment. It is the home page of the Trento Web console, and you can go back to it any time by clicking on Dashboard in the left sidebar.

The health status of a registered SAP system is the compound of its health status at three different layers representing the SAP architecture:

Complementing the operating system layer, you also have information about the health status of the HA components, whenever they exit:

The dashboard groups systems in three different health boxes (see Figure 6, “Dashboard with the global health state”):

Figure 6: Dashboard with the global health state #

  

The health boxes in the dashboard are clickable. By clicking on one particular box, you filter the dashboard by systems with the corresponding health status. In large SAP environments, this feature facilitates the SAP administrator knowing which systems are in a given status.

The icons representing the health summary of a particular layer contain links to the views in the Trento console that can help determine where an issue is coming from:

A grey status is returned when either a component does not exist, or it is stopped (as returned by sapcontrol), or its status is unknown (for instance, if a command to determine the status fails).

Grey statuses are not yet counted in the calculation of the global health status.

Getting to know the status of a system is an important task for every administrator. The status allows you to see if some of your systems need to be examined further.

The following subsection gives you an overview of specific parts of your SAP Landscape to show their state. Each status site shows you an overview of the health states (see details in The three different health states).

When the heartbeat of an agent fails, an option to clean-up the corresponding host will show up both in the Hosts overview and the corresponding Host details view.

Figure 15: Clean up button in Hosts overview #

  

Figure 16: Clean up button in Host details view #

  

When the user clicks on the cleanup button, a box will open asking for confirmation. If the user grants it, all the components discovered by the agent in that particular host, including the host itself and other components that might depend on the ones running on the host, will be removed from the console. For example, if the user cleans up the host where the primary application server of an SAP System is registered, the entire SAP System will be removed from the console.

Similarly, when a registered application or SAP HANA instance is no longer discovered, an option to clean it up will show up both in the corresponding overview and the corresponding details view.

Figure 17: Clean up button SAP systems overview #

  

Figure 18: Clean up button in SAP system details view #

  

When the user clicks the cleanup button, a box will open asking for confirmation. If the user grants it, the instance will be removed from the console along with any possible dependencies For example, if the user cleans up the ASCS instance of an SAP system, the entire SAP system will be removed from the console.

Tags are a means to label specific objects with a purpose, location, owner, or any other property you like. Such objects can be hosts, clusters, databases, or SAP systems. Tags make it easier to distinguish and show all these different objects, making your lists more readable and searchable. You can use any text you like to create your tags except blank spaces and special characters other than + - = . , _ : and @.

The following subsection shows how you can add, remove, and filter objects based on your tags.

To analyze issues within the application, we have two tools at our disposal. They both help us collect information/data that might be useful when troubleshooting/analyzing the issue.

The first source to analyze issues with the Trento Agent is the Trento Agent status, which can be retrieved as follows:

> sudo systemctl status trento-agent

If further analysis is required, it is convenient to activate debug log level for the agent. A detailed log can be then retrieved from the journal: