Elasticsearch Cluster Deployment and Management Guide (Mac/Windows)

Why Use a Cluster

Running a single Elasticsearch node quickly reaches its load limit, leading to performance degradation or unavailability; clustering provides higher capacity, fault tolerance, and better concurrency.

Limited storage per machine

Single‑point failure risk

Limited concurrent processing

Cluster Concept

A cluster consists of two or more nodes that share data and provide indexing and search together. Each cluster has a unique name (default "elasticsearch") that nodes use to join.

Mac/Windows Cluster Deployment

Note: The tutorial uses macOS, but the same steps work on Windows; the only difference is the startup script bin/elasticsearch.bat .

Copy the Elasticsearch distribution three times (node‑8001, node‑8002, node‑8003) and edit each config/elasticsearch.yml as follows:

cluster.name: my-application
node.name: node-8001
node.master: true
node.data: true
network.host: localhost
http.port: 8001
transport.tcp.port: 9301
http.cors.enabled: true
http.cors.allow-origin: "*"

cluster.name: my-application
node.name: node-8002
node.master: true
node.data: true
network.host: localhost
http.port: 8002
transport.tcp.port: 9302
discovery.seed_hosts: ["localhost:9301"]
discovery.zen.fd.ping_timeout: 1m
discovery.zen.fd.ping_retries: 5
http.cors.enabled: true
http.cors.allow-origin: "*"

cluster.name: my-application
node.name: node-8003
node.master: true
node.data: true
network.host: localhost
http.port: 8003
transport.tcp.port: 9303
discovery.seed_hosts: ["localhost:9301","localhost:9302"]
discovery.zen.fd.ping_timeout: 1m
discovery.zen.fd.ping_retries: 5
http.cors.enabled: true
http.cors.allow-origin: "*"

Start each node with bin/elasticsearch and verify cluster health via http://localhost:8001/_cluster/health.

Operational Demonstrations

1. Single‑Node Cluster

Only node‑8001 is running; three primary shards with one replica each are unassigned because there are no other nodes to hold replicas.

2. Failover

Starting a second node eliminates the single‑point‑failure; the new node automatically discovers the cluster using the same cluster.name.

3. Horizontal Scaling

After index creation, increase the replica count (e.g., to 2) to improve read throughput; the cluster redistributes shards accordingly.

4. Handling Node Failure

If the master node (node‑8001) stops, the cluster remains yellow but continues serving requests; restarting the node and adding it back to the discovery.seed_hosts list restores full health.

Routing Calculation & Shard Control

1. Routing

Routing defaults to the document _id; a hash of the routing value modulo number_of_primary_shards determines the target primary shard.

2. Shard Control

Any node can forward a request to the appropriate shard because each node knows the location of every document; load can be balanced by round‑robin across nodes.

Read/Write Workflow in a Cluster

1. Write Operations

Index, create, and delete requests are executed on the primary shard and then replicated to replicas; consistency can be tuned (e.g., quorum by default).

2. Read Operations

Reads can be served from the primary or any replica shard, improving query throughput.