Resource and hardware requirements

Estimating your deployment size Copied

When planning an ITRS Analytics deployment, it’s important to understand the resource and hardware requirements that your environment needs to meet to ensure a successful installation and stable operation. These requirements depend mainly on the expected message rate and workload the system must handle.

T-shirt sizing Message rate ITRS Analytics entities Indicative server range
Large 100,000 250,000 3,000-9,000
Medium 50,000 125,000 900-3,000
Small 10,000 25,000 300-900

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.

Indicative server range Computation
Lower estimate The following conservative assumptions were used:
  • 20-second sampling
  • 2 managed entities per server
  • 7 dataviews per managed entity
  • 10 columns and 10 rows per dataview
  • 50% of values changing every sample period
Upper estimate Actual message rates from various customer Gateways were used. Most of these Gateways use 20-second sampling and a wide range of plugins.

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.

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.

Determining your resource requirements Copied

To accurately size your ITRS Analytics deployment, follow these steps:

Use the sizing tool Copied

The ITRS Analytics Sizer tool provides an interactive way to estimate the resources needed for your specific deployment:

Review sample configuration files Copied

Once you have estimated your resource needs using the sizing tool, review the detailed sample configuration files provided by ITRS:

These files provide specific implementation details including:

T-shirt size node requirements Copied

This section explains the minimum number of nodes required for each T-shirt size configuration. It also describes how deactivating the Timescale (TS) node selectors affects the node count for medium and large sizes.

The base minimum number of nodes depends on the T-shirt size of your deployment. The following table summarizes the default minimum requirements:

Size Has TS Node Selectors? Minimum Node Count
small non-ha N/A 1
small N/A 3
medium No 3
medium Yes 6
large No 6
large Yes 9

Impact of Timescale node selectors Copied

When Timescale node selectors are activated, additional dedicated nodes are required to run Timescale workloads separately. This results in higher minimum node requirements for medium and large T-shirt sizes.

However, when Timescale node selectors are deactivated, the system reduces the minimum required nodes for these sizes by three nodes, since it no longer reserves separate nodes for Timescale.

Examples:

Understanding key terminology Copied

Before reviewing resource and hardware requirements, familiarize yourself with the following key terms:

Term Description
Message rate Volume of messages (metrics, telemetry, spans, and events) that ITRS Analytics processes per second. This is the primary factor determining the required cluster size.
CPU (Central Processing Unit) Number of processor cores allocated to run ITRS Analytics workloads. More cores allow the system to handle higher message rates and concurrent operations.
Memory (RAM) Amount of random access memory (measured in GiB) required to store and process data in real-time. Adequate memory ensures smooth operation and prevents performance issues.
Storage Disk space needed to persist data, including metrics, telemetry, and logs. ITRS Analytics requires SSD (Solid State Drive) storage for optimal performance, particularly for database operations.
IOPS (Input/Output Operations Per Second) Measure of disk performance indicating how many read/write operations the storage system can handle per second. Higher IOPS values ensure faster data processing.
Throughput Rate at which data can be transferred to and from storage, measured in Mbps (Megabits per second). This affects how quickly data can be written to and read from disk.
HA (High Availability) Deployment configuration that provides redundancy and failover capabilities to ensure continuous operation even if individual components fail. HA deployments require additional resources to maintain replicated services.
Non-HA Deployment configuration without built-in redundancy, suitable for development, testing, or environments where downtime is acceptable. Non-HA deployments require fewer resources.
T-shirt sizing Simplified categorization system (Micro, Small, Medium, Large) that groups resource requirements based on expected workload characteristics such as message rates and number of monitored entities.
ITRS Analytics entities Monitored objects within ITRS Analytics, such as servers, applications, or infrastructure components. The number of entities affects overall resource requirements.
Timescale Time-series database component of ITRS Analytics that stores historical metrics and telemetry data. Timescale has specific resource requirements separate from application workloads.
OpenTelemetry spans Distributed tracing data units that represent individual operations within a request flow. Processing spans requires additional resources.

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:

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.

Validating your environment with preflight checks Copied

After determining your resource requirements and preparing your infrastructure, it’s essential to validate that your environment meets all the necessary prerequisites before installing ITRS Analytics.

For detailed information about available preflight checks, how to run them manually, and how to interpret and resolve common issues, see Preflight checks.

["ITRS Analytics"] ["User Guide", "Technical Reference"]

Was this topic helpful?