Cross-Cluster Search: verteilte Abfragen über mehrere Elasticsearch-Cluster

1. Was Cross-Cluster Search ist und wofür es gedacht ist

Cross-Cluster Search, kurz CCS, erlaubt es einem koordinierenden Cluster, eine Suchanfrage nicht nur gegen die eigenen, lokalen Indizes auszuführen, sondern gleichzeitig auch gegen Indizes auf einem oder mehreren als remote registrierten Clustern. Aus Sicht des anfragenden Clients sieht das Ergebnis wie eine einzige, zusammengeführte Antwort aus, obwohl die zugrunde liegenden Daten physisch auf komplett getrennten Cluster-Installationen liegen, die unabhängig voneinander Master-Wahlen, Shard-Verteilung und Versionsupdates verwalten.

Der zentrale Anwendungsfall ist eine föderierte Suche über organisatorisch oder geografisch getrennte Datenbestände, ohne diese in einem einzigen, gemeinsamen Cluster konsolidieren zu müssen. Das ist besonders relevant, wenn regulatorische Vorgaben eine physische Datentrennung nach Region verlangen, gleichzeitig aber eine konzernweite Übersicht gewünscht ist.

2. Remote-Cluster-Konfiguration: Sniff- und Proxy-Modus

Ein Remote-Cluster wird über die Cluster-Settings-API oder direkt in der elasticsearch.yml registriert, wobei zwei Verbindungsmodi zur Auswahl stehen. Im Sniff-Modus verbindet sich der koordinierende Cluster zunächst mit einem oder mehreren angegebenen Seed-Nodes und ermittelt darüber automatisch weitere, für Cross-Cluster-Anfragen geeignete Nodes im entfernten Cluster.

Im Proxy-Modus dagegen läuft die gesamte Kommunikation über eine einzelne, konfigurierte Adresse, typischerweise einen Load Balancer oder Reverse Proxy vor dem entfernten Cluster, wodurch keine direkte Netzwerksicht auf einzelne Node-Adressen des entfernten Clusters notwendig ist. Für Setups mit strikter Netzwerksegmentierung zwischen Regionen ist der Proxy-Modus meist die praktikablere Wahl.

PUT _cluster/settings
{
  "persistent": {
    "cluster.remote": {
      "us_cluster": {
        "mode": "proxy",
        "proxy_address": "us-es-proxy.internal:9443"
      },
      "eu_cluster": {
        "mode": "sniff",
        "seeds": [ "eu-es-node-01.internal:9300" ]
      }
    }
  }
}

3. Ausführung einer Cross-Cluster-Query: Aufbau und Syntax

Eine Cross-Cluster-Anfrage unterscheidet sich syntaktisch kaum von einer gewöhnlichen Suchanfrage, der Indexname wird lediglich um den Cluster-Alias und einen Doppelpunkt ergänzt, etwa eu_cluster:produkte oder us_cluster:produkte. Mehrere Cluster und lokale Indizes lassen sich in derselben Anfrage kombinieren, sodass ein einzelner Suchaufruf sowohl lokale als auch entfernte Daten gleichzeitig durchsucht.

Intern zerlegt der koordinierende Cluster die Anfrage in Teilanfragen pro Cluster, sendet diese parallel an die jeweiligen Remote-Cluster und führt die zurückkommenden Teilergebnisse anschließend zu einer gemeinsamen, nach Relevanz sortierten Ergebnisliste zusammen, genau wie bei der Zusammenführung von Shard-Ergebnissen innerhalb eines einzelnen Clusters.

GET eu_cluster:produkte,us_cluster:produkte,produkte/_search
{
  "query": {
    "match": { "name": "wanderschuhe" }
  },
  "size": 20
}

4. Latenz-Trade-offs bei verteilten Abfragen

Jede Cross-Cluster-Anfrage ist grundsätzlich so langsam wie der langsamste beteiligte Remote-Cluster, da der koordinierende Cluster auf die Antworten aller angefragten Cluster warten muss, bevor er das Gesamtergebnis zurückgeben kann. Bei geografisch weit entfernten Clustern, etwa zwischen Europa und den USA, addiert sich allein die Netzwerklaufzeit spürbar zur eigentlichen Suchzeit hinzu.

Der Minimize-Roundtrips-Parameter reduziert die Anzahl der Netzwerk-Roundtrips, indem er mehr Verarbeitung auf den entfernten Clustern selbst ausführen lässt, verringert die Latenz bei weit entfernten Clustern aber nur begrenzt. Für latenzkritische, konzernweite Suchanfragen sollte deshalb realistisch mit einer spürbar höheren Antwortzeit gerechnet werden als bei einer rein lokalen Suche.

5. Konsistenz-Grenzen: kein globales Read-Consistency-Modell

Cross-Cluster Search bietet keine globale, clusterübergreifende Konsistenzgarantie. Jeder beteiligte Cluster liefert sein Ergebnis basierend auf seinem eigenen, lokalen Zustand zum Zeitpunkt der Anfrage, ohne dass eine übergreifende Synchronisation zwischen den Clustern stattfindet. Ändert sich ein Dokument in einem Remote-Cluster genau während eine Cross-Cluster-Anfrage läuft, kann das in einer inkonsistenten Momentaufnahme resultieren.

Für die meisten Suchanwendungsfälle ist dieses Verhalten unkritisch, weil Suche ohnehin selten transaktionale Konsistenz erfordert. Bei Anwendungsfällen, die auf exakte, sofort konsistente Zahlen angewiesen sind, etwa Bestandsabfragen in Echtzeit, sollte Cross-Cluster Search dagegen nicht als alleinige Datenquelle dienen.

6. Sicherheit: Cross-Cluster-API-Keys und Berechtigungen

Für produktive Setups empfiehlt sich statt der klassischen zertifikatsbasierten Remote-Cluster-Verbindung ein Cross-Cluster-API-Key, der gezielt auf einzelne Indizes und Berechtigungen des entfernten Clusters eingeschränkt werden kann. Damit erhält der koordinierende Cluster nur Zugriff auf genau die Indizes, die für die föderierte Suche tatsächlich freigegeben werden sollen, nicht auf den gesamten entfernten Cluster.

Diese granulare Rechtevergabe ist besonders wichtig, wenn getrennte Teams die beteiligten Cluster jeweils eigenständig betreiben, etwa unterschiedliche regionale Magento-Instanzen mit eigenen Betriebsverantwortlichen. Ein sauber eingeschränkter API-Key verhindert, dass eine zentrale Suchintegration versehentlich Zugriff auf Indizes erhält, die eigentlich nicht für die konzernweite Suche vorgesehen sind.

POST /_security/cross_cluster/api_key
{
  "name": "zentrale-suche-eu-cluster",
  "access": {
    "search": [
      { "names": [ "produkte*" ], "allow_restricted_indices": false }
    ]
  }
}

7. Praktischer Anwendungsfall: regional getrennte Shop-Cluster mit zentraler Suche

Ein Handelsunternehmen betreibt jeweils einen eigenständigen Elasticsearch-Cluster für die Magento-Instanzen in Deutschland, Frankreich und den USA, unter anderem aus Latenzgründen, aber auch wegen regulatorischer Vorgaben zur Datenhaltung. Für ein internes Team, das eine konzernweite Sicht auf Produktverfügbarkeit und Suchtrends benötigt, wäre eine vollständige Datenkonsolidierung in einem gemeinsamen Cluster unverhältnismäßig aufwändig und würde die bestehende regionale Trennung unterlaufen.

Cross-Cluster Search löst genau dieses Problem: Ein zentrales, internes Analyse-Tool registriert alle drei regionalen Cluster als Remote-Cluster und kann darüber eine gemeinsame Suche über alle drei Produktkataloge ausführen, während jede regionale Magento-Instanz selbst weiterhin ausschließlich gegen ihren eigenen, lokalen Cluster sucht und von der zusätzlichen Cross-Cluster-Last unberührt bleibt.

8. Skip-Unavailable und Fehlerbehandlung bei nicht erreichbaren Clustern

Ist ein registrierter Remote-Cluster zum Zeitpunkt einer Anfrage nicht erreichbar, entscheidet die Einstellung skip_unavailable pro Cluster darüber, wie sich die Gesamtanfrage verhält. Ist sie auf true gesetzt, liefert die Anfrage weiterhin ein Ergebnis aus den erreichbaren Clustern, ergänzt um einen Hinweis auf den übersprungenen Cluster, statt komplett fehlzuschlagen.

Ist skip_unavailable dagegen auf false gesetzt, dem Standardwert, schlägt die gesamte Anfrage fehl, sobald auch nur ein beteiligter Cluster nicht erreichbar ist. Für eine konzernweite Suche, bei der ein einzelner, temporär nicht erreichbarer Regional-Cluster nicht die gesamte Funktion lahmlegen soll, ist die Konfiguration auf true in den meisten Fällen die robustere Wahl.

9. Grenzen und wann sich Cross-Cluster Search nicht lohnt

Cross-Cluster Search ersetzt keine Datenkonsolidierung, wenn tatsächlich eine gemeinsame, konsistente Datenbasis mit einheitlichem Relevanz-Scoring über alle Regionen hinweg benötigt wird, etwa weil unterschiedliche Cluster leicht unterschiedliche Mapping- oder Analyzer-Konfigurationen verwenden und dadurch Scores nicht direkt vergleichbar sind.

Auch bei sehr latenzkritischen, häufig wiederholten Anfragen, etwa der Live-Suche direkt im Storefront, ist Cross-Cluster Search selten die richtige Wahl, weil die zusätzliche Netzwerklaufzeit zwischen den Clustern spürbar wird. Für interne, seltener ausgeführte, konzernweite Auswertungen und Reports ist der Ansatz dagegen gut geeignet, ohne die operative Trennung der regionalen Cluster aufzugeben.

10. Zusammenfassung

11. FAQ: Cross-Cluster Search: Das Wichtigste auf einen Blick