Press CTRL+K to open search

EDR Telemetry Store hardware specifications

  • Published on Aug 26, 2026
  • 4 minute(s) read
Prev Next

You deploy the EDR Telemetry Store with OpenSearch in one or more roles. Hardware requirements depend on the following factors:

  • Node function

  • Number of endpoints

  • Expected event retention

  • High availability requirements

EDR Telemetry Store node roles

The EDR Telemetry Store virtual appliance uses specific node roles to manage cluster operations. While a single-node configuration combines all roles onto one appliance, larger environments can distribute these roles across separate nodes.

Node role

Description

Recommended use

Cluster manager

Maintains cluster state and elections.

Deploy 1 or 3 nodes only.

Data node

Stores and searches telemetry indexes.

Required in multi-node deployments.

Ingest node

Processes telemetry before indexing.

Optional in medium or large deployments.

Common cluster configurations

Single-node cluster

A single appliance is assigned all three roles (Cluster-Manager, Data, and Ingest). The setup wizard defaults to this configuration and does not prompt the user to set the roles. This is suitable for small environments or initial evaluations.

Two-node cluster

A minimal viable solution that separates the critical cluster management task from the data workload.

  • Node 1: Cluster-Manager

  • Node 2: Data and Ingest

Robust and scalable cluster (Recommended for production)

For a production environment requiring high availability, a multi-node cluster is recommended. This configuration requires you to deploy 7 separate nodes.

A common configuration includes the following components, which you must deploy in the following order:

  • 3 Cluster-Manager nodes: Ensures that if one manager node fails, the remaining two can elect a new master and maintain cluster operations, preventing a split-brain scenario.

  • 2 Data nodes: Provides at least one replica of your data, ensuring no data loss if one data node fails.

  • 2 Ingest nodes: Offers fault tolerance and load balancing for incoming data.

Deployment workflow

  1. Initialize the cluster: On the first cluster-manager node, run the setup wizard to create the initial cluster configuration. This node serves as the anchor for the rest of the deployment. For more information, see Configure the node.

  2. Join subsequent nodes: For the remaining 6 nodes, do not run the setup wizard. Instead, use the Download from remote server (SSH/SCP) deployment option to fetch the configuration from the first node.

    • Log on to the node and run opensearch cluster deploy.

    • Type 5 to choose Download from remote server (SSH/SCP) and pressEnter .

    • Enter the IP address of the first cluster-manager node and the credentials for the config user.

      For more information about prerequisites and configuration steps, see Download from remote server (SSH/SCP).

    The wizard automatically looks up the opensearch.yml configuration, updates the local files, and establishes a secure TLS connection on port 9300 to join the node to the cluster.

Cluster formation

Use the OpenSearch Cluster Setup Wizard to assign node roles. You do not need to manually edit YAML configuration files.

To configure the nodes:

  1. Deploy the Open Virtual Appliance (OVA) to your hypervisor.

  2. Run the configuration command to launch the OpenSearch Cluster Setup Wizard.

  3. Deploy additional appliances.

Note

The additional nodes automatically detect the existing cluster manager node and join the cluster.

Node hardware requirements

OpenSearch node role

vCPU

RAM

Disk

Notes

Cluster Manager

4-16

8-64 GB

120-250 GB

Deploy one or three or more nodes. These nodes have minimal storage requirements.

Caution

Do not deploy two nodes since it significantly increases the risk of unstable cluster behavior due to difficulty establishing a quorum.

Data Node

4-16

8-64 GB

2-12 TB

Maximum 32 GB JVM

The data node serves as the primary EDR Telemetry Store. You must configure this node with a separate data volume.

Ingestion Node

4-32

8-64 GB

0.2-1 TB

The ingestion node supports up to 35,000 events per second (EPS), or approximately 500–600 Mbps. Consequently, this node experiences higher CPU utilization due to data processing overhead.

Coordinating Node

8-12

16-32 GB

250 GB

Deploy coordinating nodes only in very large implementations to handle networking, routing, and merging results from multiple data nodes. These nodes do not store data or maintain the cluster state, and therefore, their performance is restricted by CPU and network I/O capacity.



Note

To expand storage capacity, add a dedicated volume for telemetry indexes. However, increasing the root volume alone does not expand trace storage.

Deployment sizing

Use the following guidelines to determine the appropriate node count and storage based on your deployment size.

Recommended node counts

Deployment size

Endpoint count

Node count

Recommended layout

Small

up to 5000

1

Single node (all roles)

Medium

5000 - 25000

3

  • 1 Cluster manager

  • 2 Data nodes (ingest enabled)

Large

25000 - 50000+

3-5

  • 3 cluster manager nodes

  • 2 or more data nodes

  • Optional dedicated ingestion node



Recommended storage per Data Node

Deployment size

Data Nodes

Storage per Data Node

Estimated retention

Small

1

~2 TB SSD

7–15 days

Medium

2

~4–6 TB SSD

15–30 days

Large

2-3+

~8–12 TB SSD

> 30 days



Note

Retention varies depending on telemetry volume, ingest configuration, and search activity.

Management server requirements

Component

vCPU

RAM (GB)

Disk

Notes

HX Medium 2502v

4

16

1.2 TB

<15000 endpoints

HX Large 4600v

8

64

5 TB

<100000 endpoints

Trellix ePO

4

16

0.5 TB

<25000 Endpoints

SQL servers can co-locate.

Trellix ePO

8-16

16-64

0.5 TB

25-150000 endpoints

Dedicated SQL servers are required.

Trellix Agent Handler

4

8

0.2 TB

>50-75000 endpoints

Dedicated SQL Server

8-32

16-256

0.5-3 TB

Required for large deployments. High IOPS SSD is recommended.

DXL Broker

Linux Virtual Appliance

4

8

25 GB

Relays Trace Data from < 18000 endpoints

DXL Broker

Windows Virtual Appliance

4

12

20 GB

Relays Trace Data from < 18000 endpoints



Note

A single Trellix Data Exchange Layer (DXL) broker relays trace data for approximately 15,000–18,000 endpoints. To ensure high availability, configure DXL brokers in a hub topology with two brokers in each hub.

For more information about supported Endpoint Security (HX) On-prem appliance models, see Supported appliance models.

For more information about scaling your ePO - On-prem infrastructure, see Considerations for scalability.

Retention and capacity planning

Designing an on-premises environment requires balancing endpoint count, retention periods, and cost since EDRF endpoints generate an average of 50–80 MB of uncompressed engineering telemetry per day.

Network capacity

Traffic metric

Workstation

Server

Daily Data (Per endpoint)

20 – 40 MB

20 – 40 MB

Batching/Compression Notes

Data is compressed by 50% and batched every 30 seconds.

Data is compressed by 50% and batched every 30 seconds.

Load Distribution Window

10 hours (business hours)

Spread across 24 hours

Average Rate (Single endpoint)

5 – 10 Kbps

2–5 Kbps (Due to 24-hour spread)

Total Load (1000 endpoints)

5 – 10 Mbps

2 – 5 Mbps

Retention policy

Data retention is not based on a fixed time period; it is determined by the storage you allocate:

  • Higher performance and retention: Add more EDR nodes (Horizontal Scaling).

  • Lower cost: Deploy fewer nodes, resulting in shorter data retention windows.

To calculate retention, use the following formula:

Retention (Days) = (Total usable disk space)\ (Daily usage volume)

Related articles