What Is an Elasticsearch Cluster?
An Elasticsearch cluster is a collection of one or more nodes (server processes) that share the same cluster.name, hold your data collectively, and provide unified search and indexing capability across all the data. Each node runs a copy of the Elasticsearch software, joins the cluster by discovering other nodes, and takes on one or more roles that determine what work it does. Even a single-node deployment is technically a cluster of size one, but production systems typically run three or more nodes so that data and workload can be distributed and the loss of one machine does not take the whole system down.
Cricket analogy: Just as an IPL franchise fields eleven players who each specialize (opener, spinner, keeper) but all wear the same team jersey and share one scoreboard, Elasticsearch nodes share one cluster.name and one cluster state while each specializing in a role.
Node Roles
Elasticsearch nodes are configured with roles in elasticsearch.yml or via node.roles: master-eligible nodes (master) participate in cluster-level decisions like creating indices and tracking which nodes are alive; data nodes (data, or the finer-grained data_hot, data_warm, data_cold, data_frozen) actually store shards and execute CRUD and search operations against them; ingest nodes run ingest pipelines to pre-process documents before indexing; and coordinating-only nodes (no special role) route requests, merge results from data nodes, and can act as a lightweight smart load balancer. A single node can hold multiple roles simultaneously, which is common in small clusters, while large production clusters deliberately separate roles onto dedicated hardware profiles.
Cricket analogy: Splitting master-eligible, data, and ingest roles across nodes is like a franchise separating its captain (decision-making), its all-rounders (heavy lifting), and its analyst who preps pitch reports before the match, rather than asking one player to do everything.
Master Node Election
Master-eligible nodes participate in a quorum-based election (built on a Raft-like consensus protocol since Elasticsearch 7.x) to choose exactly one active master, which is responsible for maintaining cluster state, creating or deleting indices, and tracking shard allocation. The cluster requires a majority of master-eligible nodes to be reachable to elect and retain a master; this is why production clusters use an odd number of master-eligible nodes (commonly 3) and rely on the cluster.initial_master_nodes setting during bootstrap. If fewer than a quorum of master-eligible nodes can communicate, the cluster refuses to elect a master rather than risk two masters disagreeing about state, a scenario known as split-brain that older versions were more vulnerable to.
Cricket analogy: Choosing a captain by a majority vote among senior players, and refusing to proceed with a match if quorum isn't present, mirrors master election requiring a majority of master-eligible nodes to agree.
# elasticsearch.yml on a dedicated master-eligible node
cluster.name: prod-search-cluster
node.name: es-master-01
node.roles: [ master ]
cluster.initial_master_nodes:
- es-master-01
- es-master-02
- es-master-03
discovery.seed_hosts:
- es-master-01.internal:9300
- es-master-02.internal:9300
- es-master-03.internal:9300
# elasticsearch.yml on a dedicated data node
cluster.name: prod-search-cluster
node.name: es-data-hot-01
node.roles: [ data_hot, data_content ]
discovery.seed_hosts:
- es-master-01.internal:9300
- es-master-02.internal:9300
- es-master-03.internal:9300Cluster State and Discovery
The cluster state is a data structure, held in memory and replicated to every node, that describes the cluster's metadata: which indices exist, their mappings and settings, which nodes are in the cluster, and where every shard is currently allocated. Only the elected master publishes updates to cluster state, and every node applies those updates locally so all nodes have a consistent view. Nodes find each other through discovery, seeded by discovery.seed_hosts (a static list) or a hosts provider like EC2 or Azure discovery plugins; once nodes can talk to each other, the cluster's overall health is reported as green (all primary and replica shards allocated), yellow (all primaries allocated but some replicas are not), or red (some primary shards are unallocated, meaning data is unavailable).
Cricket analogy: The scoreboard operator broadcasting the official score to every stand in the stadium so fans, commentators, and players all see the same numbers is like cluster state being published consistently to every node.
Cluster health color is a quick triage signal, not a full diagnosis: green means fully healthy, yellow means primaries are safe but you've lost redundancy (often fine to leave briefly, e.g., during a single node restart), and red means some primary shards are unassigned and those indices will return incomplete or failing search results until resolved.
Scaling and High Availability
Elasticsearch scales horizontally: to handle more data or query load, you add data nodes, and the cluster rebalances shards across them automatically. For resilience, production topologies typically dedicate three master-eligible nodes (small, stable, not serving heavy search traffic) separately from data nodes (which can be scaled up and down more freely), and often adopt a hot-warm-cold-frozen architecture where recently written, frequently queried data lives on fast hot nodes (NVMe SSD, more CPU) while older data ages onto cheaper warm and cold nodes with less powerful hardware, controlled by Index Lifecycle Management policies. This separation of concerns means a spike in search traffic or a noisy re-indexing job doesn't jeopardize the cluster's ability to make basic coordination decisions.
Cricket analogy: A T20 franchise keeps its core selection committee small and stable across seasons while rotating squad players in and out based on form, just as dedicated master nodes stay fixed while data nodes scale elastically.
In small or cost-constrained clusters it's tempting to let every node be master-eligible and hold data, but this couples cluster-decision latency to data-node load: a data node under heavy indexing pressure can delay heartbeat responses, risking spurious master re-elections. For anything beyond a dev/test environment, dedicate at least three master-eligible-only nodes.
- A cluster is a set of nodes sharing one cluster.name and one replicated cluster state.
- Node roles include master-eligible, data (hot/warm/cold/frozen), ingest, and coordinating-only.
- Exactly one master is active at a time, chosen via majority quorum election among master-eligible nodes.
- Use an odd number (typically 3) of dedicated master-eligible nodes in production to avoid split-brain and keep quorum stable.
- Cluster health is reported as green, yellow, or red based on primary and replica shard allocation.
- Horizontal scaling means adding data nodes; the cluster automatically rebalances shards across them.
- Hot-warm-cold-frozen architectures place data on hardware tiers matched to its access pattern and age.
Practice what you learned
1. Why do production Elasticsearch clusters typically use an odd number of master-eligible nodes such as three?
2. What does a yellow cluster health status indicate?
3. Which node role is responsible for storing shards and executing CRUD/search operations?
4. What is the main risk of combining master-eligible and heavily loaded data roles on the same small set of nodes?
5. What is the purpose of discovery.seed_hosts?
Was this page helpful?
You May Also Like
Shards and Replicas
How Elasticsearch splits indices into shards for scalability and duplicates them as replicas for resilience and read throughput.
Index Lifecycle Management
How Elasticsearch's ILM feature automates moving indices through hot, warm, cold, and delete phases as data ages.
Monitoring Elasticsearch
Which metrics, APIs, and alerting practices keep an Elasticsearch cluster healthy and catch problems before they cause outages.
Elasticsearch Performance Tuning
Practical techniques for tuning indexing throughput, query latency, and resource usage in Elasticsearch.