OpenSearch Node Types Explained: Roles, Sizing, and Cluster Architecture

Every node in an OpenSearch cluster can serve one or more roles. Small clusters often run all roles on every node. Larger clusters benefit from dedicated node roles — separating concerns so that cluster management, data storage, ingestion processing, and query coordination don't compete for the same resources.

Understanding node types is essential for designing a cluster that scales predictably.

Node Roles Overview

Role	Purpose	Key Resource	Dedicated When
`cluster_manager`	Cluster state, shard allocation, index creation	CPU, low memory	3+ data nodes
`data`	Stores data, executes searches and aggregations	Disk, memory, CPU	Always (most nodes)
`ingest`	Runs ingest pipelines (parsing, enrichment)	CPU	Heavy pipeline processing
`coordinating` (no roles)	Routes requests, merges results	Memory, CPU	High query throughput
`ml`	Runs ML models (anomaly detection, neural search)	CPU, GPU, memory	Using ML features
`remote_store`	Manages remote-backed storage	Network, memory	Remote store setups

Cluster Manager Nodes

Cluster manager nodes (called "master" nodes in Elasticsearch) maintain the cluster state — the metadata that tracks which indices exist, their mappings, shard assignments, and node membership.

Responsibilities

Deciding where shards are allocated and rebalanced
Processing index creation, deletion, and mapping changes
Managing cluster-wide settings
Electing a leader among manager-eligible nodes

Configuration

# opensearch.yml
node.roles: [cluster_manager]

Sizing and Best Practices

Always run 3 dedicated cluster manager nodes for production. This provides fault tolerance (quorum requires 2 of 3) without wasting resources on more.
Never run 2 manager nodes — losing one breaks quorum and halts the cluster.
Moderate resources: 4–8 vCPUs, 8–16 GB RAM. Manager nodes don't store data or process queries, so they don't need large disks or high memory. But they do need consistent, low-latency network connectivity to all nodes.
Don't co-locate data and manager roles on clusters with 5+ data nodes. A data node under heavy I/O can delay cluster state updates, causing cascading issues like delayed shard recovery.

Data Nodes

Data nodes store index data (shards) and handle search queries, aggregations, and indexing operations. They do the bulk of the work.

Configuration

node.roles: [data]

Sizing

Memory: Allocate 50% of available RAM to the JVM heap (up to 32 GB max for compressed OOPs). The other 50% is used by the OS for filesystem caching, which is critical for search performance.
Disk: SSDs for hot data. Target 10–50 GB per shard, with total disk capacity for the number of shards assigned to the node. Leave 20% disk free for merges and translog.
CPU: More cores = more concurrent search and indexing threads. 8–32 vCPUs is typical.

Hot-Warm-Cold Architecture

Use node attributes to implement tiered storage:

# Hot node (fast SSDs, more CPU)
node.roles: [data]
node.attr.temp: hot

# Warm node (larger, cheaper storage)
node.roles: [data]
node.attr.temp: warm

# Cold node (high-capacity, slow storage)
node.roles: [data]
node.attr.temp: cold

Use Index State Management (ISM) policies to automatically move indices between tiers based on age.

Ingest Nodes

Ingest nodes run ingest pipelines — a series of processors that transform documents before indexing (parsing, enrichment, GeoIP lookup, script execution).

Configuration

node.roles: [ingest]

When to Use Dedicated Ingest Nodes

Your ingest pipelines do heavy processing (GeoIP lookups, Grok parsing, script execution)
High ingestion rates where pipeline processing competes with search on data nodes
Using the ML inference processor for embedding generation

Sizing

CPU-intensive: Ingest processing is CPU-bound. 8–16 vCPUs.
Moderate memory: 16–32 GB RAM. Pipelines don't need large heaps unless processing very large documents.
Minimal disk: Ingest nodes don't store data.

If your ingest pipeline is simple (rename fields, set timestamps), dedicated ingest nodes aren't necessary — data nodes handle lightweight pipelines well.

Coordinating-Only Nodes

A coordinating-only node has no roles assigned. It acts as a smart load balancer — receiving client requests, routing them to the appropriate data nodes, and merging the results.

Configuration

node.roles: []

When to Use Dedicated Coordinating Nodes

Heavy aggregation queries: Aggregation result merging is memory-intensive. Offloading this to coordinating nodes protects data nodes from OOM.
High query throughput: Coordinating nodes handle the scatter-gather overhead, freeing data nodes for data operations.
Large fan-out: Queries that hit many shards produce many partial results that need merging.

Sizing

Memory-focused: 16–64 GB RAM. The JVM heap needs to hold aggregation results being merged.
Moderate CPU: 4–16 vCPUs for result merging and serialization.
Minimal disk: No data storage needed.

When NOT to Use Coordinating Nodes

For small clusters (3–5 nodes), dedicated coordinating nodes add complexity without meaningful benefit. Every node already acts as a coordinator for requests it receives directly.

ML Nodes

ML nodes run machine learning workloads — anomaly detection jobs, neural search model inference, and data frame analytics.

Configuration

node.roles: [ml]

# Optionally configure memory for ML
plugins.ml_commons.native_memory_threshold: 90
plugins.ml_commons.only_run_on_ml_node: true

When to Use Dedicated ML Nodes

Running neural search with server-side embedding models
Anomaly detection jobs that consume significant CPU
Any ML workload where inference latency must be predictable

Sizing

CPU/GPU: ML inference is compute-intensive. Use GPU-enabled instances for large embedding models.
Memory: 32–64 GB RAM. ML models load into memory.
Minimal disk: Models are cached but don't require large storage.

Example Cluster Architectures

Small (Development/Low-Traffic Production)

3 nodes, all roles:

# All 3 nodes
node.roles: [cluster_manager, data, ingest]

Simple, but cluster manager stability depends on data node health.

Medium (Production, 10–50 TB)

3 × Cluster Manager nodes (4 vCPU, 16 GB RAM)
6 × Hot Data nodes (16 vCPU, 64 GB RAM, NVMe SSD)
3 × Warm Data nodes (8 vCPU, 64 GB RAM, HDD/standard SSD)

Large (High-Traffic Production, 50+ TB)

3 × Cluster Manager nodes (8 vCPU, 16 GB RAM)
12 × Hot Data nodes (32 vCPU, 128 GB RAM, NVMe SSD)
6 × Warm Data nodes (16 vCPU, 128 GB RAM, standard SSD)
3 × Coordinating nodes (16 vCPU, 64 GB RAM)
2 × Ingest nodes (16 vCPU, 32 GB RAM)
2 × ML nodes (GPU-enabled, 32 GB RAM)

Configuring Node Roles

Set roles in opensearch.yml:

# Single role
node.roles: [data]

# Multiple roles
node.roles: [data, ingest]

# Coordinating-only (no roles)
node.roles: []

Restart the node after changing roles. Adding or removing roles from a data node may trigger shard rebalancing.

Frequently Asked Questions

Q: Can I change node roles without rebuilding the cluster?

Yes. Update opensearch.yml and restart the node. If you remove the data role from a node that holds shards, OpenSearch will migrate shards to other data nodes (ensure sufficient capacity). If you remove cluster_manager, the node leaves the manager-eligible pool.

Q: How many cluster manager nodes should I have?

Three for almost all clusters. This provides quorum (2 of 3) and tolerates one node failure. Five is only justified for very large clusters (50+ nodes) where you want to tolerate two simultaneous manager failures. Never use an even number.

Q: Do I need dedicated coordinating nodes?

Only if you have high query concurrency or heavy aggregation workloads where result merging competes with data operations. For most clusters under 10 data nodes, every node handles coordination fine.

Q: What happens if I lose a cluster manager node?

If you have 3 manager nodes and lose 1, the remaining 2 maintain quorum and elect a new leader. The cluster continues operating normally. If you lose 2, the cluster goes read-only (no index creation, shard allocation, or writes) until a manager node recovers.

Q: How does Amazon OpenSearch Service handle node types?

AWS OpenSearch Service manages cluster manager nodes automatically for managed clusters. You configure data nodes (instance type and count), optional UltraWarm nodes (warm tier), and optional cold storage. Dedicated master nodes are a checkbox option with selectable instance types.