Resource and hardware requirements

Make sure that you meet the following resource and hardware requirements for your configuration size before installing ITRS Analytics.

The required size by ITRS Analytics depends mainly on the message rate it needs to handle.

For current Geneos customers, you can find the message rate generated by any Gateway (version 5.14.0 and later) by configuring ITRS Analytics publishing in statistics-only mode. To determine the total required message rate, add up the message rates from all Gateways that share an ITRS Analytics instance.

If you do not have these statistics, you can initially reference the sizing guidelines provided. The estimated range of the number of servers that ITRS Analytics can handle are based on certain assumptions (see below) and an analysis of existing customer Gateways.

You may use these estimates as a starting point, but validate it with actual statistics from your Gateways as soon as possible, since message rates can vary significantly between different plugins.

T-shirt sizing for HA-enabled Copied

Large Copied

Note

The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.

Medium Copied

Note

The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.

Small Copied

Note

The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.

T-shirt sizing for Non-HA Copied

Small Copied

Note

The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.

Micro Copied

Note

The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.

Storage considerations Copied

App installs Copied

Important

Before installing the FIX Monitor app, consider the potential storage impact and ensure that sufficient storage is provisioned. Large session volumes can lead to a significant increase in PVC size, especially in a single-node setup where PVCs share the same storage.

Embedded cluster installs Copied

The /var/lib/embedded-cluster directory, used for installation and data storage, should have at least three times the size of the airgap bundle or a minimum of 40Gi of free space for online installations. Additionally, it should not exceed 80% capacity.

Note that PVCs are stored in the /var/lib/embedded-cluster/openebs/local subdirectory, which does not reserve a specific amount of space upfront. The folder will initially use close to no space until files are actually added even when there is allocated storage space. Make sure that the total volume of your PVCs will fit within this subdirectory. For example, if you have PVCs for Timescale (100 GB) and Kafka (100 GB), the directory needs to be at least 200 GB.

When installing on an embedded cluster with limited space, you can relocate the data directory by passing the --data-dir flag with the install command. You need to specify the desired directory path using the --data-dir flag, since symlinks are currently not supported.

For example:

sudo ./[itrs-analytics] install --license license.yaml --data-dir /log/lib/obcerv-data

Once the cluster is installed, you cannot change the data directory anymore.

Additional preflight checks before Embedded Cluster installation Copied

To ensure a smooth and successful deployment of the ITRS Analytics Embedded Cluster, you can perform the following additional pre-flight checks before running the actual installation.

These checks help validate that your environment meets the required system and Kubernetes-level prerequisites.

1. Run the following command to perform a preflight validation:

   sudo ./itrs-analytics install run-preflights --license license.yaml
   

   This command validates system readiness such as network configuration, disk space, CPU/memory availability, and dependency checks.

   If you are installing in an air-gapped environment, append the --airgap-bundle flag:

   sudo ./itrs-analytics install run-preflights --license license.yaml --airgap-bundle itrs-analytics.airgap
   

2. After completing the preflight, you can generate a support bundle to collect diagnostic and environment information. Run the following command:

   sudo /var/lib/embedded-cluster/bin/kubectl-support_bundle /var/lib/embedded-cluster/support/host-support-bundle.yaml --v=5
   

   Note

   If you used the --data-dir flag during preflight checks, replace /var/lib/embedded-cluster with the custom path (--data-dir) you specified.

Expected errors during support bundle collection Copied

At this stage, the Embedded Cluster has not yet been installed, so some errors and warnings in the support bundle output are expected. These may include messages about missing Kubernetes resources, pods, or services.

Common expected messages:

• failed to connect to Kubernetes API
• namespace not found
• no cluster components detected

These messages simply indicate that the cluster components are not yet deployed and can be safely ignored during this stage.

Tip

It is recommended to document these expected messages internally or in your runbook so that operators are aware and do not misinterpret them as failures.

Preflight checks for Trident-based storage Copied

This ensures that the assigned storage class meets best practices and avoids potential issues that could impact stability and performance.

• Check the storage class associated with each workload. If the provisioner is csi.trident.netapp.io, validate the parameters for the presence of any of the identified issues.

• The backendType is set to ontap-nas-economy. According to Trident documentation, ontap-nas-economy is not recommended for production.

• The provisioningType is set to thin. When configured as thin, there is no strict guarantee that the requested storage will always be available.

• The snapshots parameter must be set to false. If set to true, this setting can lead to rapid disk utilization increases, potentially reaching 100% due to snapshot storage.

• Recommended actions:

  • If any of these issues are detected, update the storage class parameters accordingly.
  • Consult Trident documentation for best practices on configuring backend storage.
  • Monitor storage utilization closely, especially when enabling snapshots.