A cluster node is one running instance of Elasticsearch. Starting Elasticsearch on a machine creates a node, and that node forms or joins a cluster. A cluster with one running instance is a single-node cluster; additional correctly configured instances can join it to form a multi-node cluster. section 3.2.4 section 3.2.5
Nodes provide the machines on which an index’s shards and replicas live. Elasticsearch distributes data across nodes so the cluster can share storage and search work. A replica is kept on a different node from its primary shard: placing both on one node would lose both copies if that node failed. section 3.2.4 section 3.2.2
Table 3.2 Node roles and responsibilities (view table figure)
| Responsible for the transformation of data via pipeline ingestion before indexing. |
|
| This is the default role. It takes care of incoming client requests. |
A node can take on dedicated responsibilities. Data nodes persist and retrieve documents, master nodes manage the cluster, ingest nodes transform data before indexing, machine learning and transform nodes handle their respective requests, and coordination nodes receive client requests by default. section 3.2.5
Growing a chats cluster
Create the chats index with one primary shard and one replica. On a single node, Elasticsearch allocates the primary but does not place its replica beside it, leaving the cluster unhealthy. Start a second node with the same cluster name and it can join the cluster, allowing shard copies to be distributed across nodes. section 14.1.1 section 3.2.5
For local development, one node is useful for testing. It is not a production-grade arrangement: a production deployment typically uses a farm of data nodes, preferably on dedicated servers. Running multiple nodes on one server also fails to provide resilience, because one server failure removes every node hosted there. section 3.2.5 section 14.1.1
Configure and expand nodes with these operational rules:
- Give every node intended for the same cluster the same cluster.name; configure a unique cluster name rather than relying on the default. section 3.2.5
- Use distinct data and log paths when starting an additional node on a personal machine. section 3.2.5
- Scale out by booting additional machines as nodes; Elasticsearch distributes data to nodes that join the existing cluster. section 3.6.2
- Check cluster health when adding capacity, because its response reports state, unassigned shards, node counts, and data-node counts. section 14.1.1
Adding nodes is horizontal scaling: rather than increasing CPU or memory on an existing machine, add machines or VMs that join the cluster and share the load. Node count alone is not the whole production design; shard and replica sizing, internode communication, network settings, backups, and master-role decisions also matter. section 3.6.2 section 14.0
