Before we meet the individual roles, we need to be sure about two simple words: node and role.

Elasticsearch is a search and analytics engine. You can run it on a single computer, but in real life you run it on many computers working together. Each running copy of Elasticsearch is called a node. A group of nodes that work together and share the same cluster name is called a cluster. When you store data, the cluster splits it into small pieces called shards and spreads them over the nodes.

A node role is a label that tells a node which kind of work it is allowed to perform. Roles are set in the configuration file of each node. If you do not set any roles at all, the node takes almost every role by default. That is fine for learning or for a tiny cluster, but it becomes a problem when the cluster grows, because one machine is then trying to do many different jobs at once.

Why do roles exist?

Different jobs need different resources. Deciding where shards live needs stability and a small amount of memory. Searching billions of documents needs fast disks and lots of memory. Running machine learning needs strong processors. If all of these compete on the same machine, a heavy machine learning job can slow down the very node that keeps the cluster organized. Roles let you give each job its own home.

Let us look at a typical mature cluster from above, so every role has a place in your mind before we study it closely.

Applications and dashboards talk to the cluster through a small group of entry nodes. Behind them sit the nodes that hold data, split into groups based on how fresh and how valuable the data is. A trio of manager nodes keeps the whole cluster organized. Special helper nodes handle document preparation, machine learning, and scheduled transformations. Not every cluster needs every group, but the picture below shows the full set.

flowchart TD
  CL["Applications and Kibana"] --> CO["Coordinating Nodes"]
  CO --> HOT["Hot Data Nodes"]
  CO --> WARM["Warm Data Nodes"]
  CO --> COLD["Cold Data Nodes"]
  CO --> FRZ["Frozen Data Nodes"]
  CO --> CONT["Content Data Nodes"]
  IN["Ingest Nodes"] --> HOT
  MS["Dedicated Master Nodes"] -.->|"cluster state and shard decisions"| HOT
  MS -.-> WARM
  MS -.-> COLD
  MS -.-> FRZ
  MS -.-> CONT
  ML["Machine Learning Nodes"] --> HOT
  TR["Transform Nodes"] --> HOT
        

Notice the dotted lines from the master nodes. Master nodes do not handle your searches or your documents. They only send decisions and updates about the layout of the cluster. The solid lines show the real traffic of requests and data.

Here is the full list of roles you can assign, with the short letter that the cat nodes view uses to display each one.

You can see that the list is longer than the classic three that older tutorials mention: master, data, and ingest. Data roles split into tiers, and helper roles for machine learning, transforms, and remote clusters were added over time as the product grew.

In the next chapters we walk through each role in detail, starting with the most important one: the master.

The master role is the brain of coordination. It decides how the cluster is organized, but it does not do the everyday work of searching.

Every cluster has exactly one elected master at any moment. This elected master is chosen from the nodes that have the master role, which are called master-eligible nodes. The elected master is responsible for cluster-wide actions. It creates and deletes indices, tracks which nodes are part of the cluster, decides which shard is stored on which node, and keeps the official record of all this information, called the cluster state.

What is the cluster state?

The cluster state is a shared notebook that describes the cluster: the list of nodes, the list of indices and their settings and mappings, and the routing table that says where each shard lives. The elected master is the only node allowed to change this notebook. Whenever it changes, the master publishes the new version to all other nodes so everyone shares the same view.

What the master does not do

When you index a document or run a search, the request goes to data nodes, not through the master. The master is not on the path of normal traffic. This is exactly why a master node does not need much CPU or disk. What it needs is stability: steady memory, a steady network, and freedom from heavy competing workloads.

How does the cluster pick its master, and how does it avoid disaster when the network misbehaves?

Choosing a master is done by voting. The voting is not open to everyone. Elasticsearch maintains a voting configuration, which is the set of master-eligible nodes whose votes count. A decision, such as electing a master or accepting a change to the cluster state, needs agreement from more than half of the nodes in that set. This required majority is called a quorum.

Because more than half is needed, two groups can never both win. If a network problem cuts the master-eligible nodes into two groups, at most one group can hold the majority. The other group knows it does not have enough votes and stops trying to lead. This protection prevents the dangerous situation called split brain, where two parts of a cluster each believe they are in charge and accept conflicting changes.

flowchart LR
  subgraph A["Group with majority"]
    M1["Master-eligible 1"]
    M2["Master-eligible 2"]
  end
  subgraph B["Group without majority"]
    M3["Master-eligible 3"]
  end
  A -->|"2 of 3 votes: can elect and publish"| OK["Cluster continues"]
  B -->|"1 of 3 votes: cannot lead"| WAIT["Waits for network to heal"]
        

How many master-eligible nodes do you need?

The rule of thumb is three. With three, the cluster survives the loss of any one of them, because the remaining two are still a majority. With five, it survives the loss of two. With only two, there is no gain over one node, because losing either one leaves you without a majority. Elasticsearch is smart about this: if you have an even number of master-eligible nodes, it quietly leaves one out of the voting set so the count stays odd.

Sometimes you need an extra vote but not an extra manager. Voting-only nodes solve exactly this.

A voting-only node is a master-eligible node that takes part in elections but can never become the elected master itself. It is always paired with the master role in its configuration. It only says yes or no when votes are counted. Because it never leads, it does not need to be a powerful machine.

The classic use is a tie-breaker across zones. Suppose you have two data centers. If you put one master-eligible node in each, losing one data center leaves you with one out of two votes, which is not a majority. Adding a small voting-only node in a third location fixes this. Now any two of the three locations form a majority, and the cluster survives the loss of a whole data center.

flowchart TD
  Z1["Zone A: master-eligible node"]
  Z2["Zone B: master-eligible node"]
  Z3["Zone C: small voting-only node"]
  Z1 --- Z2
  Z2 --- Z3
  Z1 --- Z3
        

The cluster state is the heart of master work. Knowing what it holds explains many strange performance problems.

The cluster state is a single structure that every node keeps in memory. It contains the list of nodes and their roles, the metadata of every index including its settings and mappings, the templates and pipelines you have defined, and the routing table that maps each shard copy to a node. When you ask any node where a document lives, it answers from this shared structure, without asking the master.

Only the elected master may change the cluster state. Every change, such as a new index, a mapping update, or a shard moving, is put into a queue of tasks. The master batches related tasks, computes the new version of the state, and then publishes it in two steps. First it sends the new state, often only as a small set of differences, to all nodes. Once enough of the voting nodes confirm they have received it, the master tells everyone to commit it and start using it.

sequenceDiagram
  participant T as Change Request
  participant M as Elected Master
  participant V as Master-Eligible Voters
  participant N as All Other Nodes
  T->>M: Create index or change mapping
  M->>M: Compute new cluster state
  M->>V: Publish new state
  M->>N: Publish new state
  V->>M: Acknowledge receipt
  N->>M: Acknowledge receipt
  M->>V: Commit the new state
  M->>N: Commit the new state
        

Why the size of the state matters

Each update must reach every node, so a larger state takes longer to build, send, and apply. Cluster state grows with the number of indices, shards, fields, and templates. A common trap is mapping explosion, where documents with endless different field names create thousands of fields. Every one of them enlarges the state on every node. This is why Elasticsearch limits the number of fields per index by default, and why you should design mappings on purpose instead of letting anything in.

Where is it stored?

The cluster state is kept in memory, but a persistent copy is also written to disk. Master-eligible nodes keep the full cluster-level metadata, and data nodes keep the metadata of the indices they hold. This is what lets a cluster recover after a full restart, and it is also why the role of a node matters for the files that it leaves on disk.

Data nodes are the muscles of the cluster. They store shards and do the heavy lifting of indexing and searching.

A data node holds the actual shards that contain your documents. When you add, update, or delete a document, the work is done on the data node that holds the right shard. When you search, each data node searches the shards it holds and returns its part of the result. Because of this, data nodes are usually the most resource-hungry machines in the cluster, needing fast storage, plenty of memory, and good processors.

Data nodes are also where the cluster gets its ability to grow. If you need to store more data or answer more searches, you add data nodes and Elasticsearch spreads shards onto them. This is called horizontal scaling.

Generic data role versus tier roles

The plain data role is a generic role. A node with it can hold any kind of data and belongs to every data tier. It is the simplest choice and is what you get by default. When you need to treat fresh data and old data differently for cost or speed, you instead give nodes one of the specific tier roles that we cover in the next chapter.

Data has a life. It is exciting when it is fresh and mostly forgotten when it is old. Data tiers let the hardware match that life.

Think about logs from a website. In the first day, they are written constantly and searched all the time by people fixing problems. After a month, they are searched only sometimes. After a year, they are kept only for rules and audits. It would be wasteful to keep year-old logs on the same expensive fast machines as today’s logs. Data tiers let you place data on different kinds of nodes as it ages.

flowchart LR
  N["New time-based data"] --> H["Hot Tier: fast disks, constant writes"]
  H -->|"ages"| W["Warm Tier: cheaper disks, fewer searches"]
  W -->|"ages"| C["Cold Tier: rarely searched"]
  C -->|"ages"| F["Frozen Tier: cache over object storage"]
  F -->|"retention ends"| D["Deleted"]
        

Where does new data go?

New indices that belong to a data stream start in the hot tier. New indices that are not part of a data stream, including many system indices, start in the content tier. Each index carries a tier preference that lists which tiers it may live on, in order, and the cluster places it on the first tier that has nodes available.

Nobody wants to move indices by hand. Index Lifecycle Management does it for you, according to rules.

Index Lifecycle Management, usually shortened to ILM, lets you define phases for an index: hot, warm, cold, frozen, and delete. For each phase you set conditions such as the age of the index or its size, and the actions that should happen, such as rolling over to a fresh index, shrinking, merging segments, or moving to another tier.

When an index enters the warm phase, ILM changes its tier preference so the cluster moves its shards onto warm nodes. The same happens for cold and frozen. You do not tell the cluster which specific node to use. You only state which tier, and the allocation system finds the right nodes.

Raw data is often messy. Ingest nodes clean and enrich documents before they are stored.

An ingest node runs ingest pipelines. A pipeline is an ordered list of small steps called processors. Each processor changes the document in one way. Examples are splitting a log line into separate fields, converting text to numbers, renaming a field, adding the country that belongs to an IP address, or removing fields you do not want to store.

When you send documents with a pipeline named in the request, the receiving node passes them to an ingest node, which runs the steps and then forwards the finished documents to the data nodes that hold the shards. This means the cleaning work happens before the documents ever reach storage.

sequenceDiagram
  participant App as Application
  participant Co as Receiving Node
  participant In as Ingest Node
  participant Da as Data Node
  App->>Co: Send documents with pipeline name
  Co->>In: Forward documents to run the pipeline
  In->>In: Apply processors one by one
  In->>Da: Send cleaned documents to the right shard
  Da->>App: Confirm the write
        

Why use dedicated ingest nodes?

Simple pipelines cost very little. Heavy pipelines with pattern matching, scripts, and enrichment lookups use real processor time. If they run on the same nodes that hold shards, they compete with indexing and searching. Dedicated ingest nodes take that load away from data nodes, and you can add more of them when ingestion grows.

This is the most misunderstood role, because every node already plays it. Coordinating-only nodes simply do nothing else.

Whenever a request reaches a node, that node becomes the coordinating node for that request. A search, for example, is handled in two stages. First the coordinating node sends the query to every relevant shard, which is called scatter. Each shard returns its best results. Then the coordinating node merges those partial answers into one final sorted list, which is called gather, and sends it to the client.

A coordinating-only node is created by giving it an empty list of roles. It holds no data, cannot become master, and runs no pipelines. It only accepts requests, routes them, and combines results. It behaves like a smart load balancer that understands the layout of the cluster.

sequenceDiagram
  participant C as Client
  participant Co as Coordinating Node
  participant S1 as Data Node 1
  participant S2 as Data Node 2
  participant S3 as Data Node 3
  C->>Co: Search request
  Co->>S1: Search your shards
  Co->>S2: Search your shards
  Co->>S3: Search your shards
  S1->>Co: Top results
  S2->>Co: Top results
  S3->>Co: Top results
  Co->>C: Merged final answer
        

When are they worth it?

The gather step can be expensive for searches with big aggregations, many shards, or large result sets, because the merging uses memory. Dedicated coordinating nodes take this memory pressure off data nodes. They also make a good stable front door for Kibana and for applications, and they keep the internal nodes out of direct reach of clients.

Machine learning work is heavy, bursty, and different from search. It deserves its own home.

A node with the ml role can run machine learning jobs. These include anomaly detection, which learns what normal looks like for your data and flags unusual behavior, analytics jobs that classify or predict, and trained models used for language tasks such as understanding text. These features use a large part of the machine’s processor and also use memory outside of the normal Elasticsearch memory area.

Because of this, a machine learning job can easily starve a data node of memory or processing power if they share a machine. Dedicated machine learning nodes keep the impact away from indexing and searching, and they let you choose hardware that fits, for example machines with more memory or accelerators for model inference.

Transforms turn detailed data into useful summaries. The transform role is the worker that keeps them running.

A transform reads data from one or more source indices, groups or pivots it, and writes a new, smaller index. For example, you might turn millions of individual purchase events into one summary row per customer with totals and last purchase date. Transforms can run once, or continuously, updating the summary as new data arrives.

Nodes with the transform role run these jobs. A transform searches the source indices and indexes into the destination, so it uses both search and write resources. On a small cluster this is no problem. On a busy cluster, dedicated transform nodes prevent these background jobs from competing with user searches.

Sometimes one cluster needs to talk to another. This role gives a node permission to make that connection.

Elasticsearch supports two features that reach across clusters. Cross-cluster search lets you run one query that searches indices in several clusters and gives one merged answer. Cross-cluster replication lets one cluster copy indices from another, which helps with disaster recovery and with bringing data closer to users in other regions.

A node needs the remote_cluster_client role to open those connections to remote clusters. By default, nodes have it. But when you set roles by hand and list only the ones you want, you must remember to include it on the nodes that need it, or these features will fail with confusing errors.

Now let us put the roles together and follow a real request from start to finish.

Writing a document

An application sends a new document. The request lands on a coordinating node. If the request names an ingest pipeline, the document goes first to an ingest node. After that, the coordinating node works out which shard the document belongs to by using a formula on its identifier, and sends it to the data node that holds the primary copy of that shard. That node writes the document and forwards it to the nodes that hold the replica copies. When enough copies confirm, the client gets its answer.

Searching

The search reaches a coordinating node. It sends the query to one copy of every relevant shard, and those copies might be on hot, warm, cold, or frozen nodes. Each returns its best results. The coordinating node merges them and returns the final answer. During all of this, the master node is not involved.

Creating an index

This is a cluster-level change, so the request is forwarded to the elected master. It updates the cluster state, publishes the new state to everyone, and decides where the new shards should be placed. Data nodes then create the shards.

flowchart TD
  R["Client request"] --> CO["Coordinating role"]
  CO -->|"needs a pipeline"| IN["Ingest role"]
  IN --> DA["Data roles"]
  CO -->|"search or write"| DA
  CO -->|"index creation or settings change"| MA["Elected master"]
  MA -->|"new cluster state"| DA
  MA -->|"new cluster state"| CO
        

Roles only make sense if nodes can find each other. Here is how a node becomes part of a cluster.

There is one special step for a brand new cluster. The very first time, the initial master-eligible nodes must be told the names of the nodes allowed to form the first voting configuration. This is called bootstrapping. After the cluster has formed, this setting should be removed, and nodes that join later must not use it.

Roles are not permanent. But changing them on a live cluster needs care, especially for roles that hold state.

Adding a role to a node is usually simple: change the configuration and restart the node. Removing a role is trickier. A node that holds shards and loses its data role, or a node that has cluster metadata and loses its master role, is refusing to start in some cases, because Elasticsearch will not silently leave valuable data on the disk of a node that no longer manages it.

Older tutorials and older clusters describe roles in a different way. Knowing the old style helps you read them and migrate.

In early versions, each role was switched on or off by its own true or false setting, such as one for master, one for data, and one for ingest. There was no simple way to describe tiers, and adding a new kind of node meant adding yet another setting. Starting with version 7.9, Elasticsearch introduced a single list of roles for each node. The old separate settings were deprecated and are no longer accepted in modern versions.

Migrating tier layouts

Many older clusters built hot and warm layouts using custom node attributes and index settings that required indices to live on nodes with a matching attribute. Modern versions can move such indices to the built-in tiers. The usual approach is to give existing nodes the new tier roles, let lifecycle policies use the tier-based actions, and then remove the old attribute rules once all indices follow the new preference.

Because each role has a different appetite, each needs different hardware. Sizing by role is where cost savings appear.

Memory rules of thumb

Elasticsearch runs on the Java Virtual Machine, and it needs a memory area called the heap. A common rule is to give the heap no more than half of the machine memory, and to stay below the size at which Java loses a memory-saving trick, which is roughly thirty gigabytes. The rest of the memory should be left to the operating system, which uses it as a file cache. This cache is what makes searches fast.

The right role layout depends on the size and importance of your cluster.

flowchart LR
  S["Small: 3 nodes with all roles"] --> M["Medium: 3 dedicated masters plus data nodes"]
  M --> L["Large: tiers plus ingest, coordinating and ML"]
  L --> Z["Multi-zone: everything spread across 3 zones"]
        

The message is that role separation is a journey. Start simple and split roles only when measurements show a need.

Roles decide which nodes are allowed to hold shards. A set of rules called deciders then choose the exact node.

Shard allocation is the job of the elected master. For every shard copy it asks a simple question: which node should hold this? The answer comes in two parts. First, the allocator lists which nodes could hold the shard, and here roles matter: only nodes with a data role can hold shards, and an index with a tier preference can only use nodes that belong to the wanted tier. Second, a group of deciders each vote on whether a particular node is acceptable.

flowchart TD
  S["Shard needs a home"] --> R{"Does the node have a data role and the right tier?"}
  R -->|"No"| X["Node is not a candidate"]
  R -->|"Yes"| D{"Do all deciders agree?"}
  D -->|"No"| X
  D -->|"Yes"| B["Balancer picks the least loaded acceptable node"]
  B --> P["Shard is placed and recovers its data"]
        

When a node leaves

If a node disappears, the cluster does not immediately rebuild all its shards elsewhere. It waits for a short delay, by default one minute, in case the node was only restarting. This avoids a large and useless copying storm during quick restarts. If the node does not return in time, replicas are promoted and new replica copies are built.

Roles say what a node does. Attributes say where it lives. Together they build resilient clusters.

Every node can carry custom labels called node attributes. A very common one names the availability zone or rack where the node runs. You then tell the cluster that this attribute is an awareness attribute. From then on, the allocation system tries to place the copies of a shard in different zones.

With two copies of each shard, one primary and one replica, and nodes in three zones, the cluster makes sure the two copies never share a zone. If a whole zone goes dark, at least one copy of every shard survives elsewhere. Awareness is therefore the bridge between the role layout and the physical layout of your data center or cloud region.

Forced awareness and capacity

Normally, if a zone fails, the cluster tries to rebuild the missing copies in the remaining zones. That can overload them. With forced awareness you tell the cluster the full list of zones, and it will not crowd the surviving zones with extra copies. This protects the survivors, but it also means that you must have enough spare capacity in each zone to carry the load when one is missing.

Every node protects itself when it gets too busy. Understanding these protections tells you which role is struggling.

A node does not run every task at once. It has several thread pools, each a group of workers dedicated to one kind of work, such as searching, writing, getting single documents, or managing the cluster. Each pool has a fixed number of workers and a waiting line called a queue. When the queue is full, the node refuses new work of that kind and sends back an error that tells the client to slow down and try again. This refusal is called a rejection.

Which role feels which pool

Other guards

Besides thread pools, nodes use circuit breakers. These watch memory use and stop a request that would use too much, instead of letting the node run out of memory and crash. There is also an indexing pressure limit that caps how much memory in-flight writes may use, by default a small share of the heap. When it is reached, further writes are rejected until earlier ones finish.

These guards are good news. A rejection is a message that says this role is at its limit. If you see rejections rise on hot data nodes, you probably need more hot nodes or better bulk sizes. If you see breaker trips on coordinating nodes, you probably have giant aggregations that need redesign, or more memory for that role.

Good role design is useless if nodes are too few or too small. Here is a calm, step-by-step way to plan.

The order in which you touch nodes matters, and roles decide that order.

A rolling restart means restarting one node at a time so the cluster keeps working. Before each restart, you prepare the cluster so it does not begin copying shards around the moment a node disappears. You then stop the node, make your change, start it again, and wait for the cluster to be healthy before moving on.

A rolling upgrade is the same idea across versions, and the order follows the roles. Older nodes must be able to talk to newer nodes during the transition, but newer nodes cannot always send everything to older ones. That is why the guidance is to upgrade the parts that are least central first, and the master last.

Roles are your main tool for spending money only where it earns value.

The largest cost in most clusters is the data nodes, so most savings come from putting data on the cheapest tier that still meets its needs. Fresh data that people search all day belongs on hot nodes. Data that nobody has searched in weeks does not. Moving it to warm, cold, or frozen nodes can cut the cost of storage by a large factor.

Also remember the cost of people. A very complicated layout with many tiny role groups takes more time to run. A cost saving that produces a week of firefighting is not a saving. Optimize in steps, starting with tiers and retention, since these give the biggest reward for the smallest complexity.

When something goes wrong, first ask which role is really suffering. This table maps symptoms to the likely role and the first thing to check.

You do not always edit configuration files yourself. Managed platforms turn the same ideas into simpler choices.

On a managed service such as Elastic Cloud, you usually choose which groups of nodes your deployment needs from a menu: hot, warm, cold, frozen, master, coordinating, and machine learning. The platform sets the roles for you, keeps master-eligible nodes spread across zones, and can add or remove capacity in each group. You still make the same design choices, such as how many zones and how much of each tier, but you do not touch the individual role lists.

On Kubernetes, the Elastic operator lets you describe your cluster as a set of node groups. Each group has a name, a count, a list of roles, resource requests, and storage. One group might be three small master nodes, another a set of hot nodes with fast volumes, another a set of warm nodes with large cheaper volumes. The operator then creates and updates the pods in a safe order.

Roles are not only a performance tool. They also shrink the area an attacker can reach.

Nodes talk to each other over a transport connection and talk to clients over an HTTP connection. Modern Elasticsearch enables security features by default, including encrypted communication between nodes. Every node must present a valid certificate to join the cluster, so a stranger cannot simply start a node and join.

Each role has its own warning signs. Watching the right numbers on the right nodes prevents surprises.

Disk watermarks

Data nodes protect themselves as the disk fills up. At the low watermark, the cluster stops placing new shards on the node. At the high watermark, it starts moving shards away. At the flood stage, indices with shards on that node become read-only for writing so the disk cannot completely fill. By default these are around eighty-five, ninety, and ninety-five percent. Alert well before they trigger.

Useful views

The nodes view shows roles, heap use, and load per node. The cluster health view shows if shards are unassigned. The pending tasks view shows if the master has a backlog. The hot threads view shows what the busiest threads of a node are doing, which is a powerful way to find why a node is slow. Node stats show thread pool rejections and circuit breaker trips, which are early warnings of overload.

Understanding failures shows why roles are designed the way they are.

flowchart TD
  F["A node stops responding"] --> Q{"Which role?"}
  Q -->|"Master"| E["Election among remaining eligible nodes"]
  Q -->|"Data"| P["Promote replicas then rebuild copies"]
  Q -->|"Ingest or coordinating"| R["Clients retry on other nodes"]
  Q -->|"ML or transform"| A["Jobs reassigned to another such node"]
        

Teams running Elasticsearch at scale keep arriving at a few dependable habits.

These mistakes appear in real incidents over and over. Knowing them saves you from learning the hard way.

A short checklist to keep beside you when designing or reviewing a cluster.

Separating roles is powerful, but it is not free.

The best answer is neither extreme. A cluster of all-rounders wastes stability at scale. A cluster split into too many tiny specialized groups wastes money and attention. Let real measurements, such as heap pressure, rejections, and latency, tell you when the next split is justified.

These stories show how role choices play out in practice.

Some beliefs about roles spread widely and cause real problems. Let us correct the most common ones.

No. A small cluster with three nodes that share all roles works well. Dedicated masters become important as load and cluster size grow, because they protect the coordination of the cluster from heavy work.

An empty role list creates a coordinating-only node. It holds no data, cannot become master, and runs no pipelines. It only routes requests and merges results.

Yes, and in small clusters it is common. In larger clusters it is safer to separate them, so that heavy data work cannot make the master unstable.

No. Master-eligible nodes are those allowed to be elected. Only one of them is the elected master at any time. The others stand by and vote.

Three is the smallest number that tolerates one failure with a true majority. Two is no better than one, and an even number wastes a node in the voting set.

The plain data role is generic and belongs to all tiers. Tier roles such as hot, warm, cold, and frozen let you place data on nodes that match its age and importance.

By default they go to the content tier, which is meant for data such as catalogs and directories that does not age out on a schedule.

Not necessarily. If your data is already in its final shape, you can skip pipelines. Ingest nodes are useful when you want Elasticsearch itself to parse, clean, or enrich documents.

No. Kibana can connect to any suitable node. Many teams still choose dedicated coordinating nodes as a protected, stable entry point for large deployments.

Most likely the remote cluster client role was left out of the explicit list. Add it to the nodes that need to connect to remote clusters.

You can on small setups, but heavy jobs compete for processor and memory with searches and indexing. Dedicated machine learning nodes are the safer choice for serious workloads.

It adds a vote to elections without ever becoming master. It is most often a small tie-breaker in a third zone.

Use the cat nodes view. It shows a role column with letters for each role, and it marks which master-eligible node is currently elected.

Move all shards off the node using allocation filtering, wait until it is empty and the cluster is green, then change the role. If leftover data remains on disk, use the repurpose tool to clean it safely.

Not directly, because searches do not go through it. But an overloaded or unstable master can slow cluster changes and cause shard movement problems that indirectly affect performance.

Node roles are how an Elasticsearch cluster divides its work. Master-eligible nodes keep the cluster organized and agree on decisions by majority vote. Data nodes, split into content, hot, warm, cold, and frozen tiers, store shards and do the heavy searching, with each tier matching the value of data at a certain age. Ingest nodes prepare documents, coordinating nodes route requests and merge answers, and the machine learning, transform, and remote cluster client roles support special features. Like the hospital in our opening story, a cluster works best when every group has a clear job, enough resources to do it, and a backup ready if someone is missing.