Hardware and software requirements

Recommended hardware

This section lists the hardware requirements for processing an incoming event stream in KUMA at various Events per Second (EPS) rates.

The table below lists the hardware and software requirements for installing the KUMA components, assuming that the ClickHouse cluster only accepts INSERT queries. Hardware requirements for SELECT queries are calculated separately for the particular database usage profile of the customer.

When designing the storage cluster, the EPS, the average event size, and the storage depth are not the only things you must take into account. You must also be mindful of special considerations that are presented in this article for your convenience in the following sections:

Disk subsystem
Network interface
RAM
Usage profile

Disk subsystem

Insert queries (write access) constitute the majority of the load that KUMA places on ClickHouse:

Events arrive in the database in an almost constant stream.
Inserts are small and frequent by ClickHouse standards.
ClickHouse has high write amplification because of the constant merging of parts of partitions in the background.
A partition part under 1 GB in size is stored as a single file. When the part reaches 1 GB, wide column format is applied, wherein each column of the table is represented by two files, .dat and .mrk. In this case, overwriting a part to merge it with another part requires writing to 384 files + fsync for each, which is a lot of IOPS.

Of course, ClickHouse handles search queries at the same time, but there are much fewer of those than write operations. Considering the load profile, we recommend organizing the disk subsystem in the following way:

Use DAS (Direct Attached Storage) with NVME or SAS/SATA interfaces, avoiding SAN/NAS solutions.
If the nodes of the ClickHouse cluster are deployed in a virtual environment, the disk array must be directly mounted to the /opt/kaspersky/kuma directory. Avoid virtual disks.
Ideally, SSD (SATA/NVME) should be used, if possible. Any server-grade SSDs will outperform HDDs (even 15k RPM). For SSDs, use RAID-10 or RAID-0; for RAID-0, make sure that replication in ClickHouse is used.
If SSDs cannot be used, use 15k-RPM SAS HDDs in RAID-10.
A hybrid option is possible: storing hot data (for example, for the last month) on SSDs, and cold data on HDDs. This arrangement makes sure the SSD arrays always handle the write operations.
A software RAID array (madm) will always outperform a hardware RAID controller and offer more flexibility. When using RAID-0 or RAID-10, it is important that the stripe size be 1 MB. In hardware RAID controllers, the default stripe size is often 64 KB, and the maximum supported value is 256–512 KB. For RAID-10, near-layout is optimal for writing, and far-layout is optimal for reading. You must keep this in mind when using a hybrid SSD + HDD configuration.
We recommend EXT4 as the file system. If, for any reason, this file system cannot be used, you may use the XFS file system instead. We recommend enabling the 'noatime' mount option for either of these file systems.

Network interface

On each node of the cluster, a network interface with a bandwidth of at least 10 Gbps must be installed and appropriately switched. Considering write amplification and replication, 25 Gbps is ideal.
If necessary, replication processes can use a separate network interface that does not handle insert and search traffic.

RAM

ClickHouse recommends keeping the RAM-to-stored-data ratio at 1:100.
But how much RAM is needed if each node is supposed to store 50 TB, given that the event storage depth is often dictated by regulatory requirements, while search queries are not performed to the full storage depth? Thus, the recommendation can be interpreted as follows: if the average query depth involves scanning partitions with a total volume of 10 TB, then you need 100 GB of RAM. This is a general recommendation for broad analytical queries.
In the general case, more free RAM on the server improves the performance of search queries for the most recent events because the contents of the partition files will stay in operating system's page cache, so file content will be read from RAM, and not from disk.

Usage profile

The hardware requirements are designed for the database to consume a stream of a certain EPS when the database is at rest (no search queries are being executed, only inserts). At the KUMA deployment stage, it is not always possible to accurately answer the following questions:

What search and analytic queries will be performed in the system?
What is the intensity, concurrency, and depth of search queries?
What is the actual performance of the cluster nodes?

Thus, it is perfectly normal for a KUMA ClickHouse cluster to evolve over time. If an increase of EPS or intensity/resource consumption of search queries makes the cluster unable to cope with the load, you can add more shards (horizontal scaling) or improve the disk subsystems/CPU/RAM on the cluster nodes.

The configuration of the equipment must be chosen based on the system load profile. You can use the "All-in-one" configuration for an event stream of under 10,000 EPS and when using graphical panels supplied with the system.

KUMA supports Intel and AMD CPUs with SSE 4.2 and AVX instruction set support.

	Up to 3,000 EPS	Up to 10,000 EPS	Up to 20,000 EPS	Up to 50,000 EPS

KUMA Core requirements	–	–	One device. Device characteristics: At least 10 threads or vCPUs. At least 24 GB of RAM. At least 500 GB in the /opt directory. Data storage type: SSD. Data transfer rate: at least 100 Mbps.	One device. Device characteristics: At least 10 threads or vCPUs. At least 24 GB of RAM. At least 500 GB in the /opt directory. Data storage type: SSD. Data transfer rate: at least 100 Mbps.
Collector requirements	–	–	One device. Device characteristics: At least 8 threads or vCPUs. At least 32 GB of RAM. At least 500 GB in the /opt directory. Data storage type: HDD allowed. Data transfer rate: at least 100 Mbps.	Two devices. Characteristics of each device: At least 24 threads or vCPUs. At least 32 GB of RAM. At least 500 GB in the /opt directory. Data storage type: HDD allowed. Data transfer rate: at least 100 Mbps.
Correlator requirements	–	–	One device. Device characteristics: At least 8 threads or vCPUs. At least 32 GB of RAM. At least 500 GB in the /opt directory. Data storage type: HDD allowed. Data transfer rate: at least 100 Mbps.	One device. Device characteristics: At least 8 threads or vCPUs. At least 32 GB of RAM. At least 500 GB in the /opt directory. Data storage type: HDD allowed. Data transfer rate: at least 100 Mbps.
Event router requirements	–	CPU: 3 cores RAM: 240 MB.	CPU: 5 cores RAM: 250 MB.	CPU: 5 cores RAM: 7000 MB.
Keeper requirements	–	–	Three devices. Characteristics of each device: At least 6 threads or vCPUs. At least 12 GB of RAM. At least 50 GB in the /opt directory. Data storage type: SSD. Data transfer rate: at least 100 Mbps.	Three devices. Characteristics of each device: At least 6 threads or vCPUs. At least 12 GB of RAM. At least 50 GB in the /opt directory. Data storage type: SSD. Data transfer rate: at least 100 Mbps.
Storage requirements	–	–	Two devices. Characteristics of each device: At least 24 threads or vCPUs. At least 64 GB of RAM. At least 500 GB in the /opt directory. Data storage type: SSD*. The recommended transfer rate between ClickHouse nodes is at least 10 Gbps if the data stream is equal to or exceeds 20,000 EPS.	Four devices. Characteristics of each device: At least 24 threads or vCPUs. At least 64 GB of RAM. At least 500 GB in the /opt directory. Data storage type: SSD*. The recommended transfer rate between ClickHouse nodes is at least 10 Gbps if the data stream is equal to or exceeds 20,000 EPS.
Operating systems	Ubuntu 22.04 LTS, 24.04 LTS. Oracle Linux 8.6, 8.7, 8.10, 9.2, 9.3, 9.4, 9.5. Astra Linux Special Edition RUSB.10015-01 (2021-1126SE17 update 1.7.1) Astra Linux Special Edition RUSB.10015-01 (2022-1011SE17MD update 1.7.2.UU.1) Astra Linux Special Edition RUSB.10015-01 (2022-1110SE17 update 1.7.3) Core version 5.15.0.33 or higher is required. Astra Linux Special Edition RUSB.10015-01 (2023-0630SE17MD, update 1.7.4.UU.1) Astra Linux Special Edition RUSB.10015-01 (2024-0212SE17MD, update 1.7.5.UU.1) Astra Linux Special Edition RUSB.10015-01 (2024-0830SE17, update 1.7.6) Astra Linux Special Edition RUSB.10015-01 (2025-0319SE17 update 1.7.7) Astra Linux Special Edition RUSB.10015-01 (2025-0114SE18MD, update 1.8.1.UU.2). RED OS 7.3.4, 8 MosOS 15.5.
TLS ciphersuites	TLS versions 1.2 and 1.3 are supported. Integration with a server that does not support the TLS versions and ciphersuites that KUMA requires is impossible. Supported TLS 1.2 ciphersuites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 Supported TLS 1.3 ciphersuites: TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256

Recommended configurations for different load levels

The table below describes the configurations and recommended resources for KUMA components depending on the EPS level, including storage requirements and sizing recommendations.

Recommended hardware configurations and resource consumption by KUMA depending on EPS

Setting	Up to 3,000 EPS	Up to 10,000 EPS	Up to 20,000 EPS	Up to 50,000 EPS
Installation type	Installation on a single server	Installation on a single server	Distributed installation on multiple servers	Distributed installation on multiple servers
Number of servers and their purpose	One server that hosts all system components.	One server that hosts all system components.	One server for the KUMA Core. One server for the collector One server for the correlator. Three dedicated servers with the keeper role. Two servers for the Storage.	One server for the KUMA Core. Two servers for the Collector. One server for the correlator. Three dedicated servers with the keeper role. Four servers for the storage.
Server hardware	At least 16 threads or 16 vCPUs. At least 32 GB of RAM. At least 500 GB in the /opt directory. Data storage type: SSD. Data transfer rate: at least 100 Mbps.	At least 24 threads or 24 vCPUs. At least 64 GB of RAM. At least 500 GB in the /opt directory. Data storage type: SSD. Data transfer rate: at least 100 Mbps.	The KUMA Core, collector, correlator and keeper require at least 16 threads or 16 vCPUs and at least 64 GB of RAM per server. The storage requires fast SSDs, high IOPS, at least 1 Gbps of network bandwidth.	Same specifications as for EPS 20,000, but with twice the number of collectors and storage servers. Higher requirements for network connectivity between all nodes: at least 1 Gbps of network bandwidth is recommended.
Storage configuration (ClickHouse)	One shard, one replica. Disk buffer enabled.	One shard, one replica. Disk buffer enabled.	Two shards, two replicas in each. If high availability is not required, one server with one replica per shard may be used.	Two shards, two replicas in each. If high availability is not required, two servers with one replica per shard may be used.

Additional recommendations for specifying and sizing the configuration:

For the KUMA Core component, at over 50,000 assets, we recommend provisioning more resources: for every additional 50,000 assets, add 2 threads (or 2 vCPUs) and 4 GB of RAM. If the system manages more than 100 services, you must consider the additional load: for every 100 services, we recommend also increasing the computational resources of the KUMA Core by 2 threads (or 2 vCPUs).
If users actively engage with the system, including frequent generation of reports, using dashboards, and running custom SQL queries, you need to adjust the sizing of both the KUMA Core and the storage because such activity substantially increases the load on both components.
When choosing the disk subsystem for the storage (ClickHouse), only SSD drives may be used. An exception is possible if you do not plan to run aggregation SQL queries with a depth of more than 24 hours. In this case, you may use HDDs with the following minimum specifications: 15,000 RPM, SAS interface, RAID-10.
When placing components in HDFS, you may use HDD regardless of the queries that you run.
Events are exported via temporary files that are saved in the /opt/kaspersky/kuma/core/tmp/ directory. These files are automatically deleted after 10 days. If you plan to export a large amount of events, you must allocate additional space.

Resource usage for a single-server installation at different EPS levels

The table below lists the total resource usage by a single-server installation (collector + KUMA Core + storage and other services) rather than the usage by individual components. A single-server installation allows processing streams of up to 500,000 EPS using multiple collectors (for example, 5 collectors at 100,000 EPS each) on one server, on which all services are deployed together. In distributed configurations, scaling can be achieved by adding collectors and servers with the storage role.

Resources required for a single-server installation depending on EPS

Event stream (EPS)	Threads or vCPUs	RAM, GB
1000	1	2
3000	2	2
5000	4	4
10,000	4	8
20,000	8	16
50,000	12	18
100,000	34	20
150,000	40	24
200,000	48	36
300,000	56	40
500,000	90	150

Working in virtual environments

The following virtual environments are supported for installing KUMA:

VMware 6.5 or later
Hyper-V for Windows Server 2012 R2 or later
QEMU-KVM 4.2 or later
"Brest" virtualization software RDTSP.10001-02

Working in cloud environments

KUMA can work in a cloud infrastructure. The system can be installed on virtual machines following the IaaS (infrastructure-as-a-service) model.

For a cloud infrastructure, we recommend using the single-server configuration for 3000 EPS and 10,000 EPS. Virtual machines must satisfy the hardware and software requirements of a regular installation.

When choosing the disk subsystem of the server, use the "number of input/output operations (IOPS)" parameter as the reference. The recommended minimum value is 1000 IOPS.

Resource recommendations for the Collector component

Consider that for event processing efficiency, the CPU core count is more important than the clock rate. For example, eight CPU cores with a medium clock rate can process events more efficiently than four CPU cores with a high clock rate.

Consider also that the amount of RAM utilized by the collector depends on configured enrichment methods (DNS, accounts, assets, enrichment with data from Kaspersky CyberTrace) and whether aggregation is used (RAM consumption is influenced by the data aggregation window setting, the number of fields used for aggregation of data, volume of data in fields being aggregated). The utilization of computation resources by KUMA depends on the type of events being parsed and the efficiency of the normalizer.

For example, with an event stream of 1000 EPS and event enrichment disabled (event enrichment is disabled, event aggregation is disabled, 5000 accounts, 5000 assets per tenant), one collector requires the following resources:

1 CPU core or 1 virtual CPU
512 MB of RAM
1 GB of disk space (not counting event cache)

For example, to support 5 collectors that do not perform event enrichment, you must allocate the following resources: 5 CPU cores, 2.5 GB of RAM, and 5 GB of free disk space.

Kaspersky recommendations for storage servers

You must use high-speed protocols, such as Fibre Channel or iSCSI 10G for the connection of the data storage system to storage servers. We do not recommend using application-level protocols such as NFS or SMB to connect data storage systems.

On ClickHouse cluster servers, we recommend using the ext4 file system.

If you are using RAID arrays, we recommend using RAID 0 for high performance, or RAID 10 for high performance and high availability.

To ensure high availability and performance of the data storage subsystem, we recommend making sure that all ClickHouse nodes are deployed strictly on different disk arrays.

If you are using a virtualized infrastructure to host system components, we recommend deploying ClickHouse cluster nodes on different hypervisors. You must prevent any two virtual machines with ClickHouse from running on the same hypervisor.

For high-load KUMA installations, we recommend installing ClickHouse on physical servers.

Requirements for agent devices

You must install agents on network infrastructure devices that will send data to the KUMA collector. Device requirements are listed in the following table.

	Windows devices	Linux devices
CPU	Single-core, 1.4 GHz or higher	Single-core, 1.4 GHz or higher
RAM	512 MB	512 MB
Free disk space	1 GB	1 GB
Operating systems	Microsoft® Windows® 2012 Microsoft Windows 2012 support is limited. Microsoft Windows Server 2012 R2 Microsoft Windows 2012 R2 support is limited. Microsoft Windows Server 2016 Microsoft Windows Server 2019 Microsoft Windows Server 2016 Microsoft Windows Server 2016 Microsoft Windows 11 Microsoft Windows 11	Oracle® Linux 8.6, 8.7, 9.2, 9.4, 9.5. Alma Linux 9.5 Astra Linux Special Edition RUSB.10015-01 (2021-1126SE17 update 1.7.1) Astra Linux Special Edition RUSB.10015-01 (2022-1011SE17MD update 1.7.2.UU.1) Astra Linux Special Edition RUSB.10015-01 (2022-1110SE17 update 1.7.3) Astra Linux Special Edition RUSB.10015-01 (2023-0630SE17MD, update 1.7.4.UU.1) Astra Linux Special Edition RUSB.10015-01 (2025-0319SE17 update 1.7.7) Astra Linux Special Edition RUSB.10015-01 (2025-0114SE18MD, update 1.8.1.UU.2). Astra Linux 1.8 x86-64 with glibc 2.36 (Debian GLIBC 2.36-9+deb12u7+ci202405171200+astra5). Astra Linux 1.7 x86-64 with glibc 2.28 (Debian GLIBC 2.28-10+deb10u4+ci202407161455+astra12). CentOS Linux release 8.2.2004 (Core) with glibc 2.28 (GNU libc). CentOS Linux release 7.7.1908 (Core) with glibc 2.17 (GNU libc). Debian 12 с with glibc 2.36 (Debian GLIBC 2.36-9+deb12u7). Red Hat Enterprise Linux 9.5 (Plow) with glibc 2.34 (GNU libc). Red OS 8. Rocky Linux 9.3 (Blue Onyx) with glibc 2.34 (GNU libc) Rocky Linux 9.5. SuSE 15.6. Ubuntu 24.04.2 LTS with glibc 2.39 (Ubuntu GLIBC 2.39-0ubuntu8.4) Ubuntu 22.04.4 LTS with glibc 2.35 (Ubuntu GLIBC 2.35-0ubuntu3.8) MosOS 15.5.

Hardware requirements for installing KUMA agents with WEC, ETW, and WMI transports

KUMA agents installed on Windows devices can use various types of transports to receive events: WEC (Windows Event Collector), ETW (Event Tracing for Windows), and WMI (Windows Management Instrumentation). The performance of the agents and their impact on the system depend on the limitations imposed by Windows and on the amount and type of events processed (see the table below).

Requirements for agents by transport type

Transport type	Maximum performance (EPS)	Limitations imposed by Windows	Limitations imposed by KUMA	Recommended agent configuration	CPU and RAM usage
WEC	Up to 2500 events per second	When writing to system logs (Application, System, Hardware Events), Windows limits the rate to approximately 2500 events per second. When writing to multiple logs at the same time, performance is further reduced: up to 1100 EPS with 2 logs, up to 800 EPS with 3 logs, and up to 500 EPS with 4 logs.	The agent can process events in the range of 1500–2500 EPS without lag.	CPU: 1 core with 2 threads or 2 vCPUs. RAM: 4 GB.	Average CPU load by the agent: up to 0.18 (equivalent to approximately 0.28% of the total system performance). RAM usage: up to 209 MB.
ETW	Up to 700 events per second	Only one system log is supported: Microsoft → Windows → DNS-Server. The Windows operating system does not allow writing more than 700 events per second to this log.	No limitations on the KUMA side have been identified, however, when EPS exceeds 700, the agent does not receive data due to Windows restrictions.	CPU: 1 core with 2 threads or 2 vCPUs. RAM: 4 GB.	Average CPU load by the agent: up to 0.267 (equivalent to approximately 0.42% of the total system performance). RAM usage: up to 186 MB.
WMI	Up to 5000 events per second	You can circumvent Windows restrictions by connecting multiple devices. Each additional device increases the total event volume that can be processed by 1000–1500 EPS.	Upon reaching 5000 EPS, the agent starts processing events with a lag.	CPU: 1 core with 2 threads or 2 vCPUs. RAM: 4 GB.	Average CPU load by the agent: up to 0.61 (equivalent to approximately 0.91% of the total system performance). RAM usage: up to 311 MB.

Transport type

Maximum performance (EPS)

Limitations imposed by Windows

Limitations imposed by KUMA

Recommended agent configuration

CPU and RAM usage

WEC

Up to 2500 events per second

When writing to system logs (Application, System, Hardware Events), Windows limits the rate to approximately 2500 events per second. When writing to multiple logs at the same time, performance is further reduced: up to 1100 EPS with 2 logs, up to 800 EPS with 3 logs, and up to 500 EPS with 4 logs.

The agent can process events in the range of 1500–2500 EPS without lag.

CPU: 1 core with 2 threads or 2 vCPUs.

RAM: 4 GB.

Average CPU load by the agent: up to 0.18 (equivalent to approximately 0.28% of the total system performance).

RAM usage: up to 209 MB.

ETW

Up to 700 events per second

Only one system log is supported: Microsoft → Windows → DNS-Server. The Windows operating system does not allow writing more than 700 events per second to this log.

No limitations on the KUMA side have been identified, however, when EPS exceeds 700, the agent does not receive data due to Windows restrictions.

CPU: 1 core with 2 threads or 2 vCPUs.

RAM: 4 GB.

Average CPU load by the agent: up to 0.267 (equivalent to approximately 0.42% of the total system performance).

RAM usage: up to 186 MB.

WMI

Up to 5000 events per second

You can circumvent Windows restrictions by connecting multiple devices. Each additional device increases the total event volume that can be processed by 1000–1500 EPS.

Upon reaching 5000 EPS, the agent starts processing events with a lag.

CPU: 1 core with 2 threads or 2 vCPUs.

RAM: 4 GB.

Average CPU load by the agent: up to 0.61 (equivalent to approximately 0.91% of the total system performance).

RAM usage: up to 311 MB.

Hardware requirements for KUMA agents on Linux devices depending on EPS

KUMA agents installed on Linux devices can use various types of transports. The hardware requirements for KUMA agents depend on the type of transport and the EPS (see the table below).

Requirements for KUMA agents on Linux devices depending on EPS

Transport type	10,000 EPS	20,000 EPS	60,000 EPS	100,000 EPS
HTTP	CPU: 3 cores RAM: 160 MB.	CPU: 5 cores RAM: 260 MB.	CPU: 5 cores RAM: 260 MB.	CPU: 5 cores RAM: 300 MB.

Transport type

10,000 EPS

20,000 EPS

60,000 EPS

100,000 EPS

HTTP

CPU: 3 cores

RAM: 160 MB.

CPU: 5 cores

RAM: 260 MB.

CPU: 5 cores

RAM: 260 MB.

CPU: 5 cores

RAM: 300 MB.

Hardware requirements for using the Score AI service and asset status

CPU: 2 cores, 2.7 GHz.

RAM: 8 GB

Storage: SSD or HDD.

Free disk space: 10 GB for the service itself and space for the OS.

Requirements for client devices for managing the KUMA web interface

CPU:

Intel® Core™ i3, 8th generation, 32-bit
AMD Ryzen 3, 32-bit

RAM: 8 GB

Supported browsers:

Google™ Chrome™ 110 or later
Mozilla™ Firefox™ 110 or later

Device requirements for installing KUMA on Kubernetes

Minimum configuration of a Kubernetes cluster for deployment of a high-availability KUMA configuration:

1 load balancer node (not part of the cluster)
3 controller nodes
2 worker nodes

The minimum hardware requirements for devices for installing KUMA on Kubernetes are listed in the table below.

Minimum hardware requirements for installing KUMA on Kubernetes

	Balancer	Controller	Worker node
CPU	1 core with 2 threads or 2 vCPUs.	1 core with 2 threads or 2 vCPUs.	12 threads or 12 vCPUs.
RAM	At least 2 GB	At least 2 GB	At least 24 GB
Free disk space	At least 30 GB	At least 30 GB	At least 1 TB in the /opt directory. At least 32 GB in the /var/lib directory.
Network bandwidth	10 Gbps	10 Gbps	10 Gbps

Page top