Cluster-Architektur: Master- und Data-Nodes richtig verteilen

1. Warum Node-Rollen die Basis jeder Cluster-Architektur sind

Jeder Elasticsearch-Node startet standardmaessig mit allen Rollen gleichzeitig: er ist master-eligible, speichert Daten, verarbeitet Ingest-Pipelines und nimmt Suchanfragen entgegen. Fuer einen lokalen Test oder einen Zwei-Knoten-Cluster ist das praktisch. Sobald ein Cluster jedoch produktiv unter Last laeuft, wird genau diese Vermischung zum groessten Risiko fuer die Cluster-Architektur: ein Node, der gleichzeitig grosse Aggregationen berechnet, Shards hostet und an der Master-Wahl teilnimmt, kann unter Speicherdruck geraten und die Kontrollebene destabilisieren, obwohl das eigentliche Problem nur eine einzelne teure Suchanfrage war.

Eine durchdachte Cluster-Architektur trennt deshalb Rollen entlang klarer Verantwortlichkeiten: Master-eligible Nodes verwalten Metadaten und Cluster-State, Data-Nodes tragen die eigentliche Indexierungs- und Suchlast, Ingest-Nodes transformieren Dokumente vor dem Schreiben, und Coordinating-Nodes buendeln Anfragen aus vielen Shards. Diese Trennung ist kein Overengineering fuer kleine Setups, sondern eine Voraussetzung dafuer, dass ein Cluster mit wachsendem Datenvolumen vorhersehbar skaliert, statt bei Lastspitzen unkontrolliert zu degradieren.

Die Rollenkonfiguration erfolgt seit Elasticsearch 7.9 ueber node.roles in der elasticsearch.yml, als explizite Liste statt der alten Boolean-Flags. Diese Liste ist der zentrale Hebel jeder Cluster-Architektur-Entscheidung: sie legt fest, welche Aufgabe ein physischer oder virtueller Host im Cluster uebernimmt, und damit auch, wie er dimensioniert werden muss.

2. Master-eligible Nodes: Cluster-State und Wahl

Master-eligible Nodes (node.roles: [master]) sind fuer den Cluster-State verantwortlich: Index-Metadaten, Mappings, Einstellungen, Shard-Zuteilung und die Liste aller Cluster-Mitglieder. Genau ein Node im Cluster traegt zu jedem Zeitpunkt die aktive Master-Rolle, alle anderen master-eligible Nodes stehen als Kandidaten bereit. Faellt der aktive Master aus, waehlen die verbleibenden master-eligible Nodes ueber den Raft-aehnlichen Konsensalgorithmus einen Nachfolger, ohne dass Daten verloren gehen.

Wichtig fuer jede Cluster-Architektur ist, dass Master-Aufgaben CPU-leicht, aber latenzsensibel sind: die Cluster-State-Publikation muss schnell an alle Nodes propagiert werden, damit Shard-Zuteilungen konsistent bleiben. Ein Master-Node, der zusaetzlich schwere Aggregationsanfragen verarbeitet, kann durch Garbage-Collection-Pausen die State-Publikation verzoegern und damit im schlimmsten Fall ungewollte Master-Wechsel ausloesen. Das ist der Kernvorteil, den dedizierte Master-Nodes gegenueber gemischten Rollen bieten.

3. Data-Nodes: Speicherlast und Shard-Verteilung

Data-Nodes tragen die eigentliche Arbeitslast einer Elasticsearch-Installation: sie speichern Shards auf Disk, fuehren Indexierungsoperationen aus und beantworten Suchanfragen mit dem Lucene-Unterbau. In modernen Versionen werden Data-Nodes feiner unterteilt in data_content, data_hot, data_warm, data_cold und data_frozen, was eine gestaffelte Speicherarchitektur ueber unterschiedlich leistungsfaehige Hardware ermoeglicht, dazu mehr im dedizierten Hot-Warm-Cold-Artikel dieser Serie.

Fuer die grundlegende Cluster-Architektur zaehlt zunaechst: Data-Nodes brauchen ausreichend RAM fuer den JVM-Heap und den Betriebssystem-Dateicache, schnelle SSDs fuer Indexierungsdurchsatz und genug CPU-Kerne fuer parallele Segment-Merges. Jede Rolle, die zusaetzlich auf einem Data-Node aktiviert wird, etwa Master-Eligibility, konkurriert um dieselben Ressourcen wie die eigentliche Indexierungs- und Suchlast, weshalb in Produktionsclustern ab etwa sechs Nodes die Rollentrennung spuerbare Stabilitaetsvorteile bringt.

# elasticsearch.yml - dedicated data node
node.name: data-node-01
node.roles: [ data_hot, data_content ]

# Storage and memory tuning for a data-heavy node
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

# Discovery: point to the master-eligible nodes, not to other data nodes
discovery.seed_hosts:
  - master-node-01:9300
  - master-node-02:9300
  - master-node-03:9300

# Shard allocation awareness by availability zone
node.attr.zone: eu-central-1a
cluster.routing.allocation.awareness.attributes: zone

4. Ingest-Nodes: Pipelines vor der Indexierung

Ingest-Nodes (node.roles: [ingest]) fuehren Ingest-Pipelines aus, bevor ein Dokument tatsaechlich indexiert wird: Grok-Parsing von Logzeilen, GeoIP-Anreicherung, Feldumbenennungen, Skript-Prozessoren oder das Aufspalten von Dokumenten. In kleinen Clustern laeuft die Ingest-Rolle haeufig kombiniert mit der Data-Rolle mit, weil die zusaetzliche CPU-Last durch Pipelines moderat bleibt.

Bei Log- und Metrik-Pipelines mit hohem Dokumentendurchsatz und rechenintensiven Prozessoren, etwa komplexen Grok-Mustern oder Skript-Prozessoren mit Painless, lohnt sich dagegen eine dedizierte Ingest-Schicht. Sie entkoppelt die CPU-Last der Vorverarbeitung von der Indexierungslast auf den Data-Nodes und verhindert, dass ein aufwendiges Pipeline-Update ploetzlich die Schreiblatenz des gesamten Clusters erhoeht. Diese Entkopplung ist ein oft uebersehener Baustein einer belastbaren Cluster-Architektur.

5. Coordinating-Nodes: Lastverteilung fuer Suchanfragen

Ein Coordinating-Node hat keine der anderen Rollen aktiviert (node.roles: []) und dient ausschliesslich als Einstiegspunkt fuer Client-Anfragen. Er nimmt eine Suchanfrage entgegen, verteilt sie im Scatter-Gather-Verfahren an alle relevanten Shards auf den Data-Nodes und fasst die Teilergebnisse zusammen, bevor er die finale Antwort an den Client sendet. Diese Zusammenfuehrung, insbesondere bei grossen Aggregationen ueber viele Shards, kostet Heap-Speicher und CPU.

In Clustern mit vielen Shards oder komplexen Dashboards, etwa Kibana-Visualisierungen mit tiefen Aggregationen, verhindert eine dedizierte Coordinating-Schicht, dass diese Zusammenfuehrungsarbeit die Data-Nodes zusaetzlich belastet. Fuer kleinere Cluster ist diese Rolle optional: jeder Data-Node kann implizit als Koordinator fuer Anfragen agieren, die er selbst entgegennimmt. Eine reine Cluster-Architektur-Entscheidung fuer dedizierte Coordinating-Nodes lohnt sich meist erst ab etwa zehn Data-Nodes oder bei sehr heterogenem Suchtraffic.

6. Dedizierte Master-Nodes: warum sie Cluster-Stabilitaet sichern

Der wichtigste Grundsatz fuer eine produktionstaugliche Cluster-Architektur lautet: Master-eligible Nodes sollten in jedem Cluster ab mittlerer Groesse dediziert betrieben werden, also ohne Data-, Ingest- oder Coordinating-Rolle. Ein dedizierter Master-Node braucht dafuer vergleichsweise wenig Hardware, typischerweise vier virtuelle CPUs und acht bis sechzehn Gigabyte RAM reichen fuer die meisten Cluster aus, weil er keine Shards hostet und keine Suchlast verarbeitet.

Der Stabilitaetsgewinn entsteht dadurch, dass die Kontrollebene physisch von der Datenebene entkoppelt ist: ein voller Heap auf einem Data-Node durch eine unerwartet teure Aggregation kann die Master-Wahl nicht mehr beeinflussen, weil die Master-Prozesse auf komplett anderer Hardware laufen. In der Praxis zeigt sich dieser Effekt besonders bei Reindexierungs- oder Wiederherstellungsphasen, in denen die Data-Nodes ohnehin unter erhoehter Last stehen: mit dedizierten Master-Nodes bleibt die Cluster-State-Verwaltung davon unberuehrt, mit gemischten Rollen droht in solchen Phasen ein instabiler Cluster mit haeufigen Master-Wechseln.

GET _cat/master?v

// Confirms which node currently holds the active master role,
// useful to verify stability after a rolling restart of the cluster
id             host            ip           node
a1B2c3D4E5f    10.0.1.11       10.0.1.11    master-node-01

7. Minimum-Sizing fuer Produktionscluster

Fuer produktive Cluster gilt als Minimum-Sizing: drei dedizierte master-eligible Nodes, damit auch bei Ausfall eines Nodes noch ein Quorum aus zwei verbleibenden Nodes fuer die Master-Wahl erhalten bleibt. Die Anzahl der Data-Nodes richtet sich nach Datenvolumen, Replikationsfaktor und gewuenschtem Durchsatz, sollte aber aus Redundanzgruenden nie unter zwei liegen, besser sind mindestens drei, verteilt auf unterschiedliche Availability-Zones.

Fuer kleine Cluster mit begrenztem Budget ist ein Kompromiss ueblich: drei Nodes uebernehmen sowohl Master- als auch Data-Rolle gemeinsam. Das ist fuer Testumgebungen und kleine interne Anwendungen akzeptabel, sollte aber fuer geschaeftskritische Produktionslasten vermieden werden. Sobald das Datenvolumen oder die Anfragerate wachsen, ist die Migration zu dedizierten Rollen ohne Downtime moeglich, indem neue Master-only-Nodes dem Cluster hinzugefuegt und die bestehenden Nodes schrittweise auf reine Data-Rollen umgestellt werden.

8. Split-Brain vermeiden: Quorum und Discovery-Settings

Ein Split-Brain entsteht, wenn ein Netzwerkpartitionsfehler dazu fuehrt, dass zwei Teile eines Clusters gleichzeitig glauben, den aktiven Master zu stellen, und dadurch widerspruechliche Cluster-States entstehen. Seit dem Zen2-Discovery-Protokoll ab Elasticsearch 7 wird das strukturell verhindert: eine Master-Wahl ist nur gueltig, wenn eine echte Mehrheit, also ein Quorum, der master-eligible Nodes zustimmt. Mit drei master-eligible Nodes braucht eine gueltige Wahl mindestens zwei Stimmen, ein einzelner isolierter Node kann sich niemals selbst zum Master erklaeren.

Genau deshalb ist eine gerade Anzahl an Master-Nodes fuer jede Cluster-Architektur ein Antipattern: bei vier Nodes und einer Netzwerkpartition von zwei zu zwei existiert kein Teil mit echter Mehrheit, der Cluster wird handlungsunfaehig, statt weiterzuarbeiten. Die initiale Bootstrap-Konfiguration erfolgt einmalig ueber cluster.initial_master_nodes beim ersten Start eines neuen Clusters, danach uebernimmt die interne Cluster-State-Verwaltung die Nachverfolgung der Mitgliederliste automatisch.

# elasticsearch.yml - master-eligible node, bootstrap of a new cluster
node.name: master-node-01
node.roles: [ master ]

# Bootstrap only on first cluster startup, remove afterwards
cluster.initial_master_nodes:
  - master-node-01
  - master-node-02
  - master-node-03

discovery.seed_hosts:
  - master-node-01:9300
  - master-node-02:9300
  - master-node-03:9300

# Keep master nodes lean, no heavy JVM heap needed for control plane work

GET _cat/nodes?v&h=name,node.role,master,heap.percent,ram.percent,cpu

// Example response, "m" marks master-eligible, "d" marks data role
name             node.role   master heap.percent ram.percent cpu
master-node-01   m           *      12           35          2
master-node-02   m           -      9            33          1
master-node-03   m           -      10           34          1
data-node-01     d           -      68           81          45
data-node-02     d           -      71           79          52

9. Typische Fehler bei der Node-Rollen-Verteilung

Der haeufigste Fehler in gewachsenen Clustern ist eine gerade Anzahl an master-eligible Nodes, meist entstanden durch schrittweises Hinzufuegen von Hardware ohne Blick auf die Quorum-Mathematik. Ein zweiter verbreiteter Fehler: Master-Nodes werden gemeinsam mit der Data-Rolle betrieben, weil das anfangs Hardware spart, was sich aber bei wachsender Suchlast direkt in Cluster-Instabilitaet niederschlaegt.

Ein dritter Fehler betrifft die Netzwerktrennung: master-eligible Nodes sollten in unterschiedlichen Availability-Zones oder zumindest unterschiedlichen physischen Racks stehen, damit ein einzelner Hardware- oder Netzwerkausfall nicht gleich das Quorum gefaehrdet. Wer alle drei Master-Nodes in derselben Zone betreibt, hat rein formal die richtige Cluster-Architektur, verliert aber bei einem Zonenausfall trotzdem die Handlungsfaehigkeit des gesamten Clusters.

Ein vierter, oft uebersehener Fehler ist fehlendes Monitoring der Quorum-Situation selbst: Teams ueberwachen Heap-Auslastung und Shard-Zuteilung, vergessen aber ein Alerting fuer den Verlust eines master-eligible Nodes. Faellt in einem Drei-Knoten-Setup ein zweiter Master-Node aus, bevor der erste ersetzt wurde, verliert der Cluster sein Quorum vollstaendig und kann keine neuen Master-Entscheidungen mehr treffen, obwohl alle Data-Nodes weiterhin online sind. Ein einfacher Alert auf die Anzahl aktiver master-eligible Nodes in _cluster/health schliesst diese Luecke zuverlaessig.

// Verify zone awareness attributes are set consistently across nodes
GET _nodes?filter_path=nodes.*.attributes

{
  "nodes": {
    "abc123": { "attributes": { "zone": "eu-central-1a" } },
    "def456": { "attributes": { "zone": "eu-central-1b" } },
    "ghi789": { "attributes": { "zone": "eu-central-1c" } }
  }
}

10. Zusammenfassung

Eine belastbare Cluster-Architektur beruht auf sauberer Rollentrennung: master-eligible Nodes verwalten den Cluster-State, Data-Nodes tragen Indexierung und Suche, Ingest-Nodes verarbeiten Pipelines, Coordinating-Nodes buendeln grosse Suchanfragen. Dedizierte Master-Nodes entkoppeln die Kontrollebene physisch von der Datenebene und verhindern, dass Heap-Druck auf Data-Nodes die Master-Wahl beeinflusst. Drei master-eligible Nodes sind das Minimum fuer ein funktionierendes Quorum, eine gerade Anzahl ist immer ein Fehler.

Der groesste Stabilitaetsgewinn entsteht nicht durch mehr Hardware, sondern durch die richtige Verteilung vorhandener Ressourcen entlang klarer Rollen. Wer die Cluster-Architektur von Anfang an mit dedizierten Master-Nodes plant, spart sich spaeter eine riskante Migration unter Produktionslast und reduziert die Wahrscheinlichkeit von Split-Brain-Vorfaellen strukturell, statt nur reaktiv auf Symptome zu reagieren.

11. FAQ: Cluster-Architektur, Master- und Data-Nodes