System requirements for a five-node deployment

Review the system requirements of Self-Hosted Standard Edition on a five-node cluster.

The following specifications represent minimum requirements for a functional deployment. If backend workload increases, you might need to add more resources to make sure optimal performance and system stability.

Each self hosted environment has upper limits for the load it can process. Your actual resource needs may vary based on factors such as:
  • The number of servers under observation.
  • The technologies that run on the observed servers, as some technologies are more metric intensive.
  • The load on an observed environment, from a request perspective, is determined by the trace load, which is directly proportional to both the incoming traffic to the observed system and its internal traffic.
  • Application architecture and traffic patterns, high-traffic microservices generate far more spans than monolithic applications.
  • Infrastructure complexity, a Kubernetes node with hundreds of pods can produce significantly more metrics than a single VM.
  • Enabled features, like End-User Monitoring (EUM), logging, and serverless monitoring can increase data ingestion and storage.
  • Traffic spikes and seasonal events, take into consideration peak periods like Black Friday or promotional campaigns.
Note: Contact your IBM representatives to identify whether your environment fits into the selected deployment approach. For larger workloads, you can increase resources beyond the minimum requirements to ensure optimal performance.

Hosts

For five-node environments, you need three hosts with the same operating system.

The five nodes in a five-node cluster have specific uses:

  • The first node (instana-0), which is labeled as node-role.instana.io: "backend" during installation, is used for running backend workloads that require persistent volumes. The node also runs the gateway, acceptors, and the UI backend.

  • The second node (instana-1), which is labeled as node-role.instana.io: "datastore" during installation, is used for running data stores.

  • The third node (instana-2), which is labeled as node-role.instana.io: "other" during installation, is used for running the rest of Instana workloads.

  • The forth node (instana-3), which is labeled as node-role.instana.io: "clickhouse" during installation, is used for running ClickHouse data store.
  • The fifth node (instana-4), which is labeled as node-role.instana.io: "agent-other" during installation, is used for running backend workloads and the rest of Instana workloads.

Supported platforms and operating systems

Make sure you have a host on which you can run the Self-Hosted Standard Edition installer.

Important: The host can be a virtual machine or a dedicated physical machine. The host must be new with a freshly installed operating system. If you want to use a host that was previously used for something else, you must reinstall the operating system. Self-Hosted Standard Edition must not co-exist with a Self-Hosted Classic Edition (Docker).

Instana supports the following platforms and operating systems for the host:

Table 1. Supported operating systems
Platform Operating system
Linux® x86_64 Red Hat® Enterprise Linux® (RHEL) 10, 9, and 8
Ubuntu 24.04 and 22.04
Debian 13 and 12
CentOS Stream 9
Amazon Linux 2023
Oracle Linux 9
SUSE Linux Enterprise Server (SLES) 15 SP6 SP7
Linux® arm64

Supported on AWS Graviton

Deployment on other operating systems on arm64 is not tested.

Hardware requirements

In five-node clusters, only the production installation type is supported.

CPU, memory, and storage

Each node requires CPU and memory as specified in the following table.

The nodes require, up to the specified CPU, memory, and storage across all VMs.

Table 2. Production - Small VMs (totals across all VMs)
Number of CPU cores Memory (GB) Storage
44 176 5050

Each node may require, up to the specified CPU, memory, and storage in the following table.

Table 3. Production - Small per node system requirements:
Node name CPU (cores) Memory (GB) Disk (GB) Minimum Disk Speed (IOPS) per second Minimum disk throughput (MiB) per second Purpose
instana-0 8 32 1270 3000 250 backend
instana-1 12 48 2470 3000 250 data store
instana-2 8 32 270 3000 250 other
instana-3 8 32 770 3000 250 clickhouse
instana-4 8 32 270 3000 250 agent-other

The nodes require, up to the specified CPU, memory, and storage across all VMs.

Table 4. Production - Large VMs (totals across all VMs)
Number of CPU cores Memory (GB) Storage
132 528 10100

Each node may require, up to the specified CPU, memory, and storage in the following table.

Table 5. Production - Large per node system requirements:
Node name CPU (cores) Memory (GB) Disk (GB) Minimum Disk Speed (IOPS) per second Minimum disk throughput (MiB) per second Purpose
instana-0 24 96 1270 3000 250 backend
instana-1 36 144 2470 3000 250 data store
instana-2 24 96 270 3000 250 other
instana-3 24 96 770 3000 250 clickhouse
instana-4 24 96 270 3000 250 agent-other

For each optional feature that you want to use, you need additional resources.

Provision the additional resources, such as CPU and memory capacity on node0 (instana-0), node2 (instana-2) and node4 (instana-4). Do not provision the resources on node1 (instana-1) and node3 (instana-3) as node1 and node3 are primarily used for the data stores. In addition, if you enable the logging feature, then you need more disk space to store the log data on node3 (instana-3).

CPU architecture requirements (x86‑64)

Instana supports installation on x86‑64 systems that provide x86‑64‑v2 CPU support. The x86‑64‑v2 instruction set is required by several Instana components (such as Cassandra and Kafka) and by the GNU C Library (glibc) used during installation. Most modern CPUs (introduced around 2008 or later) support x86‑64‑v2. However, in virtualized environments, the virtual machine configuration can mask or limit CPU capabilities, even when the underlying hardware supports them.

Required CPU instruction flags

The operating system must have the following CPU flags available:

  • sse3
  • ssse3
  • sse4_1
  • sse4_2
  • popcnt
  • cx16
  • lahf_lm
Note: Instana requires the CPU flags for customer environments. Depending on the operating system and glibc version, the system might require more flags.

Storage requirements

The four data storage directories are required on the following nodes. You must add additional disks on these nodes.

  • Objects directory on node0 (instana-0).
  • Data, metrics, and analytics directories on node1 (instana-1).

No additional disk is needed on node2 (instana-2).

The following table provides the storage volume requirements of each node:

Table 6. Cluster storage volume requirements for node0 instana-0
Description Default directory Min size (GB) Comments
Object directory /mnt/instana/stanctl/objects 1000 Override path with--volume-objects
Root directory / 100
$HOME directory (air-gapped) /root or the home directory of users 60 Override with $HOME environment variable. 40 for $HOME directory (air-gapped) and 20 GB for separate disk space.
$HOME directory (non-air-gapped) /root or the home directory of users 10 Override with $HOME environment variable
Cluster data directory /var/lib 100 Override with--cluster-data-dir
Table 7. Cluster storage volume requirements for node1 instana-1
Description Default directory Min size (GB) Comments
Data directory /mnt/instana/stanctl/data 500 Override path with--volume-data
Metrics directory /mnt/instana/stanctl/metrics 1000
Analytics directory /mnt/instana/stanctl/analytics 1200
Root directory / 100
$HOME directory (air-gapped) /root or the home directory of users 60 Override with $HOME environment variable. 40 for $HOME directory (air-gapped) and 20 GB for separate disk space.
$HOME directory (non-air-gapped) /root or the home directory of users 10 Override with $HOME environment
Cluster data directory /var/lib 100 Override with--cluster-data-dir
Table 8. Cluster storage volume requirements for node2 instana-2
Description Default directory Min size (GB) Comments
Root directory / 100
$HOME directory (air-gapped) /root or the home directory of users 60 Override with $HOME environment variable. 40 for $HOME directory (air-gapped) and 20 GB for separate disk space.
$HOME directory (non-air-gapped) /root or the home directory of users 10 Override with $HOME environment
Cluster data directory /var/lib 100 Override with-—cluster-data-dir
Table 9. Cluster storage volume requirements for node3 instana-3
Description Default directory Min size (GB) Comments
Analytics directory /mnt/instana/stanctl/analytics 1200 Override path with --volume-data
Root directory / 100
$HOME directory (air-gapped) /root or the home directory of users 60 Override with $HOME environment variable. 40 for $HOME directory (air-gapped) and 20 GB for separate disk space.
$HOME directory (non-air-gapped) /root or the home directory of users 10 Override with $HOME environment
Cluster data directory /var/lib 100 Override with-—cluster-data-dir
Table 10. Cluster storage volume requirements for node4 instana-4
Description Default directory Min size (GB) Comments
Root directory / 100
$HOME directory (air-gapped) /root or the home directory of users 60 Override with $HOME environment variable. 40 for $HOME directory (air-gapped) and 20 GB for separate disk space.
$HOME directory (non-air-gapped) /root or the home directory of users 10 Override with $HOME environment
Cluster data directory /var/lib 100 Override with-—cluster-data-dir
Note: In an air-gapped environment, you need 20 GB more disk space in the directory where you create the air-gapped package, both on the bastion host and the Instana host. For more information about the package, see Creating the air-gapped installation package.
Important: For about a month, you must monitor the storage volume that you initially assigned. You can then increase the capacity if necessary. Also, if you use more agents or enable more optional features, you must monitor the memory usage.

One dedicated device per directory

Each of Instana's four data directories (`data`, `metrics`, `analytics`, and `objects`) must be on its own dedicated storage.

You must set up a directory for every dedicated storage device.

Isolation must be maintained end-to-end down to the physical layer.

The directories must not share any of the following resources:

  • Disk
  • Volume group
  • SAN pool
  • RAID set
  • Any other layer that resolves to the same spindles, flash, cache, or controller

Host-level separation—such as separate mount points, logical volumes (LVs), or LUNs—is necessary but not sufficient. If lower-layer resources ultimately map to the same physical hardware, the directories will still contend for I/O capacity.

Isolation must hold across the entire storage stack, not just at the host layer. The only exception to this rule is NVMe, which is addressed separately.

Performance isolation

Instana data directories generate high-volume, bursty, and concurrent I/O. Each storage device has a finite I/O capacity that includes:

  • IOPS
  • Throughput (bandwidth)
  • Cache

When multiple directories share a device:

A workload spike in one directory can reduce available capacity for others. It results in unpredictable latency, which can manifest as:

  • Query timeouts
  • Dropped traces
  • Slow dashboards
  • Failed health checks

Use dedicated devices to ensure consistent and predictable performance.

Fault containment

Dedicated storage assigns each directory to its own failure domain. If a device becomes full, degraded, or unavailable, only the associated directory is affected.

With shared storage, the same issue impacts all directories sharing that device.

Although Instana data stores are interdependent and full service availability cannot be guaranteed during a failure, isolating storage limits the scope of impact and simplifies recovery operations.

Verifying storage isolation

You must verify that each directory is backed by independent physical resources and that no sharing exists at any layer.

The host can present multiple devices even when they are backed by shared storage. Host-level validation alone is not sufficient.

Validate at the host level, run the following commands to inspect device mappings.

To list block devices and mount points:
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

For LVM configurations (trace LV, VG, PV):

sudo pvssudo vgssudo lvdisplay -m

The configuration must meet the following conditions:

  • Each mount point uses a distinct block device
  • No block device is used by more than one directory
  • In LVM setups, each volume group uses only its own physical volumes and no physical volume is shared across volume groups.

Validate at the storage backend:

For SAN, NAS, or virtualised storage, additional validation is required because the host does not have visibility into backend resource sharing.

Confirm the following conditions with your storage provider or administrator:

  • The volumes do not originate from the same storage pool, RAID set, or data store.
  • Storage controller resources, such as cache, are not shared.
  • Fabric or connectivity paths are independent
  • I/O activity on one volume does not affect another volume.
Exception: NVMe storage

The isolation requirement is based on characteristics of traditional disks, such as seek latency and serialised I/O queues. NVMe storage significantly reduces these constraints. In NVMe environments, the requirement can be relaxed to a capacity-based model.

Capacity-based placement: Multiple directories can share a single NVMe device if the following conditions are met:

  • The device provides sufficient sustained IOPS and throughput.
  • Capacity exceeds the combined peak demand of all the directories.

Plan for peak usage, not average usage: The workloads burst, and simultaneous spikes can saturate a device that appears sufficient under steady conditions.

Reduced fault isolation: All directories on the same device share a single failure domain. If the device fails, all colocated directories are affected. Use shared NVMe configurations only if losing that isolation is acceptable.

Default directories

Instana uses the following directories for data storage.

  • Data directory: Used for Elasticsearch, PostgreSQL, and Kafka data stores. The default location is /mnt/instana/stanctl/data.
  • Metrics directory: Used for Cassandra and BeeInstana data stores. The default location is /mnt/instana/stanctl/metrics.
  • Analytics directory: Used for ClickHouse data store. The default location is /mnt/instana/stanctl/analytics.
  • Objects directory: Used for raw spans, Synthetic monitoring, and end user monitoring (EUM). The default location is /mnt/instana/stanctl/objects.
  • Cluster data directory: Used for cluster data.
  • $HOME directory: Home directory of the current root or non-root user.

Due to the high data throughput of various Instana features and to avoid performance issues, use fast, dedicated storage such as solid-state drives (SSDs). Use separate disks for each of the data, metrics, analytics, and objects directories.

You must mount the following directories onto the separate disks:

  • Cluster data directory: You can specify a custom directory if you don’t have enough disk space in /var. For example, /xyz/data. Make sure to specify this directory by using the --cluster-data-dir during installation. The --cluster-data-dir flag redirects only the /var/lib/rancher/k3s directory to the custom path. K3s and kubelet continue to write data to other /var locations, such as /var/lib/kubelet/pods, container runtime temporary data, and component logs. You must make sure that the /var disk has enough free space to support these directories. Low space on /var can lead to pod scheduling failures or kubelet disk‑pressure warnings. If such issues occur, you must check the available space in /var/lib/kubelet and other /var subdirectories.
  • $HOME directory: $HOME refers to the home directory of the current user. For example, if the user is a root user, $HOME would be /root; for a non-root user, $HOME would be /home/<username>.

Networking requirements

Make sure that you meet the following ports and IP addresses requirements. For more information about opening these ports, see Firewall rules.

Note: Make sure that you have a high-speed, low-latency, and stable connection on the backend server to pull the necessary packages.

Required ports

The following ports on all nodes must be open and accessible.

Table 11. five-node ports
Port number Direction Protocol Source Description
22 Inbound TCP External Port required for Secure Shell (SSH) connection (required only if you want to log in SSH)
22 Inbound TCP Internal SSH port required for access between backend nodes
80 Inbound TCP External HTTP protocol for Instana console UI
443 Inbound TCP External HTTPS protocol for Instana console UI, Instana console API, Instana EUM, OpenTelemetry, and Instana agent acceptor port
443 Outbound TCP External Required only in online environments. For more information, seeOutbound network access requirements for self-hosted Instana deployments.
53 Inbound TCP/UDP Internal (all nodes) DNS port required for resolving domain names
6443 Inbound TCP Internal (all nodes) Internal service port
8443 Inbound TCP External Instana agent acceptor port. This port is optional.
10250 Inbound TCP Internal (all nodes) Internal service port
2379 Inbound TCP Internal (all nodes) Internal service port
2380 Inbound TCP Internal (all nodes) Internal service port
5001 Inbound TCP Internal (all nodes) Internal service port
8472 Inbound UDP Internal (all nodes) Internal service port
9443 Inbound TCP Internal (all nodes) Internal service port
all Inbound TCP/UDP 10.42.0.0/16 and10.43.0.0/16 Subnets of the self-hosted Instana components
all Inbound TCP/UDP Loopback Open the ports to allow a VM to send and receive its own data packets.

See the following notes:

  • External source means that the port must be accessible from outside of the Instana self-hosted enterprise (private) network.
  • Internal source means that the port on one node must be accessible by the other two nodes of the five-node cluster.
  • IP addresses 10.42.0.0/16 and 10.43.0.0/16 must be able to access all ports (1 - 65535) internally.
  • The firewall must trust all traffic from the loopback address.
  • Port 443 outbound is needed for accessing certain repositories. For more information, see Outbound network access requirements.

IP addresses

The five nodes of your five-node cluster must meet the following IP address requirements:

  • All the five nodes need a private IP address on the same private VLAN to be able to communicate with each other.
  • node0 (instana-0) must also have a IP address for external communication. The IP address is also used to reach the hosts from outside the cluster.