Node-Rollen jenseits von Master und Data: Ingest, ML, Coordinating und Transform verstehen

1. Warum die einfache Master-plus-Data-Aufteilung an Grenzen stößt

In einem kleinen Cluster mit drei bis fünf Nodes übernimmt praktisch jeder Node alle Rollen gleichzeitig: Master-eligible, Data und implizit auch Ingest und Coordinating. Das funktioniert, solange die Gesamtlast überschaubar bleibt und ein einzelner Node genug Kapazität für alle Aufgaben mitbringt. Sobald jedoch zusätzliche Arbeitslasten wie aufwändige Ingest-Pipelines mit vielen Prozessoren oder rechenintensive Machine-Learning-Jobs hinzukommen, konkurrieren diese Aufgaben direkt mit der eigentlichen Suchanfrage um CPU, Heap und Netzwerkbandbreite auf denselben Nodes.

Das Ergebnis ist häufig eine schwer nachvollziehbare Performance-Degradation: Suchanfragen werden langsamer, obwohl sich am eigentlichen Suchindex nichts geändert hat, weil im Hintergrund ein Ingest-Pipeline-Lauf oder ein Machine-Learning-Job denselben Node auslastet. Eine gezielte Rollentrennung löst dieses Problem, indem sie unterschiedliche Arbeitslasten auf unterschiedliche, dedizierte Nodes verteilt, sodass ein überlasteter Ingest-Node niemals die Antwortzeit einer Produktsuche beeinflusst.

2. Ingest-Nodes: Pipelines direkt im Cluster verarbeiten

Ingest-Nodes führen Ingest-Pipelines aus, bevor ein Dokument tatsächlich indexiert wird: Sie können Felder umbenennen, Werte per Grok-Pattern aus unstrukturiertem Text extrahieren, Geodaten anreichern oder ganze Dokumente anhand von Bedingungen verwerfen. Diese Verarbeitung findet vollständig innerhalb des Clusters statt und ersetzt damit häufig eine externe Logstash- oder ETL-Schicht, die andernfalls vor der eigentlichen Indexierung notwendig wäre.

Bei einfachen Pipelines mit wenigen Prozessoren reicht es meist aus, dass jeder Data-Node implizit auch die Ingest-Rolle übernimmt. Sobald jedoch Pipelines mit vielen Prozessoren, aufwändigen Skript-Prozessoren oder hoher Dokumentenrate zum Einsatz kommen, lohnt sich die Auslagerung auf dedizierte Ingest-Nodes, damit die eigentliche Indexierung und Suche auf den Data-Nodes von dieser zusätzlichen CPU-Last verschont bleibt.

# elasticsearch.yml eines dedizierten Ingest-Nodes
node.name: es-ingest-01
node.roles: [ ingest ]

# Beispiel-Pipeline zur Attribut-Normalisierung vor der Indexierung
PUT _ingest/pipeline/produkt-attribute-normalisieren
{
  "processors": [
    { "lowercase": { "field": "farbe" } },
    { "trim": { "field": "hersteller" } },
    {
      "remove": {
        "field": "temp_import_flag",
        "ignore_missing": true
      }
    }
  ]
}

3. Coordinating-Only-Nodes: Anfragen bündeln ohne eigene Datenhaltung

Ein Coordinating-Only-Node hat keine der anderen Rollen aktiviert: kein Master, kein Data, kein Ingest. Seine einzige Aufgabe besteht darin, eingehende Suchanfragen entgegenzunehmen, sie an die zuständigen Data-Nodes weiterzuleiten, die Teilergebnisse der einzelnen Shards zusammenzuführen und das fertige Ergebnis an den Client zurückzugeben. Weil er selbst keine Shards hält, benötigt er keinen großen Heap für Datenhaltung, sondern vor allem ausreichend Speicher für das Zusammenführen und Sortieren vieler Teilergebnisse.

In der Praxis übernehmen bei kleinen Clustern die Data-Nodes diese Koordinationsaufgabe zusätzlich mit. Bei sehr breiten Fan-out-Queries, etwa Suchanfragen über sehr viele Shards oder Indizes gleichzeitig, kann ein dedizierter Coordinating-Only-Node jedoch als stabiler, vorhersagbarer Einstiegspunkt dienen, hinter dem sich die eigentliche Cluster-Topologie verbirgt, ähnlich einem Lastverteiler direkt innerhalb des Elasticsearch-Clusters.

4. Machine-Learning-Nodes: Ressourcenisolierung für ML-Jobs

Machine-Learning-Jobs, etwa zur Anomalieerkennung in Bestellzahlen oder zur automatischen Kategorisierung von Suchanfragen, sind speicher- und CPU-intensiv und laufen zeitlich unabhängig von normalen Suchanfragen. Ohne dedizierte Machine-Learning-Nodes konkurrieren diese Jobs mit der regulären Suchlast um denselben Heap, was bei einem plötzlichen Anstieg der Job-Aktivität zu spürbaren Verzögerungen bei ganz normalen Produktsuchen führen kann.

Die Machine-Learning-Rolle sorgt dafür, dass entsprechende Jobs ausschließlich auf Nodes mit dieser Rolle geplant werden, während Data- und Coordinating-Nodes davon vollständig unberührt bleiben. Für einen Magento-Betrieb mit klassischer Produktsuche ohne eigene Machine-Learning-Auswertungen ist diese Rolle meist nicht relevant, gewinnt aber an Bedeutung, sobald etwa Suchverhalten oder Traffic-Anomalien automatisiert ausgewertet werden sollen.

5. Transform-Nodes: kontinuierliche Aggregationen als eigene Rolle

Transforms erzeugen aus einem bestehenden Quellindex fortlaufend einen zweiten, bereits aggregierten Zielindex, etwa eine tägliche Zusammenfassung von Bestellungen pro Kategorie oder eine kontinuierlich aktualisierte Kennzahl zu den meistgesuchten Begriffen. Die Berechnung dieser Aggregationen läuft periodisch im Hintergrund und kann bei großen Quellindizes durchaus rechenintensiv sein.

Die Transform-Rolle bündelt diese Hintergrundlast auf eigenen Nodes, sodass ein aufwändiger Transform-Lauf niemals die Latenz einer regulären Suchanfrage beeinflusst. Gerade bei Reporting- oder Analytics-Anwendungsfällen rund um einen Magento-Shop, etwa einer eigenen internen Auswertung des Suchverhaltens, lohnt sich diese Trennung, sobald die Transform-Jobs regelmäßig und mit spürbarer Rechenlast laufen.

6. Ab welcher Cluster-Größe sich dedizierte Rollentrennung lohnt

Bei Clustern mit bis zu etwa fünf Nodes und moderater Last überwiegt meist der Verwaltungsaufwand einer strikten Rollentrennung den tatsächlichen Nutzen. Alle Nodes teilen sich Master-, Data- und implizite Ingest-Aufgaben, und die zusätzliche Betriebskomplexität separater Node-Typen steht in keinem sinnvollen Verhältnis zur gewonnenen Isolation.

Ab etwa sechs bis acht Nodes oder sobald erkennbare Ressourcenkonflikte zwischen unterschiedlichen Arbeitslasten auftreten, etwa spürbare Latenzspitzen während eines Ingest-Laufs, wird eine dedizierte Trennung sinnvoll. Als grobe Faustregel gilt: Zunächst dedizierte Master-Nodes einführen, sobald Cluster-Stabilität kritisch wird, danach bei Bedarf Coordinating-Only- oder Ingest-Nodes, und Machine-Learning- sowie Transform-Nodes erst, wenn die entsprechenden Funktionen tatsächlich aktiv und regelmäßig genutzt werden.

7. Praktische Topologie-Beispiele für Shops unterschiedlicher Größe

Ein kleiner Magento-Shop mit überschaubarem Katalog kommt oft mit drei Nodes aus, die jeweils alle Rollen kombinieren, ergänzt um eine einfache Ingest-Pipeline zur Attribut-Normalisierung direkt auf den Data-Nodes. Diese Topologie ist einfach zu betreiben und bietet für den erwarteten Traffic ausreichend Reserve.

Ein mittlerer bis großer Shop mit hohem Suchtraffic und zusätzlichen Auswertungen profitiert dagegen von einer klar getrennten Topologie: drei dedizierte Master-Nodes für Stabilität, mehrere reine Data-Nodes für Indexierung und Speicherung, zwei Coordinating-Only-Nodes als stabiler Suchzugang und ein separater Node mit Ingest- und Transform-Rolle für Attribut-Anreicherung und periodische Reports, ohne dass diese Hintergrundlast jemals die eigentliche Produktsuche beeinträchtigt.

# Beispiel-Topologie für einen mittleren bis großen Shop

# node.roles: [ master ]        -> drei dedizierte Master-Nodes
# node.roles: [ data, data_hot ] -> mehrere reine Data-Nodes
# node.roles: []                 -> zwei Coordinating-Only-Nodes
# node.roles: [ ingest, transform ] -> ein Node für Anreicherung und Reports

node.name: es-data-03
node.roles: [ data, data_hot ]
node.attr.zone: eu-central-1a

8. Rollen-Konfiguration in elasticsearch.yml und Node-Attribute

Die Rollenzuweisung erfolgt über die Einstellung node.roles in der elasticsearch.yml jedes einzelnen Nodes, als Liste der aktivierten Rollen wie master, data, ingest, ml oder transform. Ein Coordinating-Only-Node erhält bewusst eine leere Liste, wodurch keine der spezialisierten Rollen aktiv ist.

Zusätzlich lassen sich über benutzerdefinierte Node-Attribute, etwa eine Zone- oder Hardware-Kennzeichnung, gezielte Shard-Zuweisungen und Ausschlüsse steuern, sodass sich Rollentrennung und physische oder virtuelle Verteilung auf Racks, Availability-Zones oder Hardware-Klassen kombinieren lassen. Diese Kombination ist besonders relevant, wenn Ingest- oder Machine-Learning-Nodes bewusst auf Instanzen mit anderem CPU-zu-Speicher-Verhältnis laufen sollen als die eigentlichen Data-Nodes.

9. Monitoring und Fallstricke bei gemischten Rollen

Ein häufiger Fallstrick ist die versehentliche Vermischung von Rollen auf Nodes mit begrenztem Heap, etwa wenn ein kleiner Data-Node zusätzlich die Machine-Learning-Rolle erhält und dadurch regelmäßig an seine Speichergrenze stößt. Die Node-Stats-API zeigt pro Node auf, wie stark Heap, CPU und Thread-Pools durch die jeweiligen Rollen ausgelastet sind, und liefert damit die Grundlage für fundierte Trennungsentscheidungen.

Ebenso wichtig ist die Beobachtung der Thread-Pools write, search und der Ingest-spezifischen Pools getrennt voneinander: Steigen die Warteschlangen eines bestimmten Pools kontinuierlich an, während andere Pools ruhig bleiben, ist das ein klares Signal dafür, dass genau diese Arbeitslast von den übrigen Rollen isoliert werden sollte, statt pauschal die gesamte Cluster-Kapazität zu erhöhen.

10. Zusammenfassung

11. FAQ: Node-Rollen in Elasticsearch: Das Wichtigste auf einen Blick