Elasticsearch hat sich einen Namen damit gemacht, in ungeahnte Grössen zu skalieren, aber manchmal ist ein Cluster einfach nicht genug. Für diese Fälle wurde der Elasticsearch Tribe Node eingeführt, eine spezielle Elasticsearch Instanz, die selber keine Daten hält, sondern mehrere Cluster miteinander verbindet und so den Zugriff auf die Daten der einzelnen Cluster erlaubt, als wären alle Daten in einem einzigen grossen Cluster vorhanden.
Allerdings wird der Tribe Node nicht verwendet, um Grössenbeschränkungen von Elasticsearch Clustern zu umgehen, da die Anzahl von Knoten innerhalb eines Clusters nur durch die zur Verfügung stehenden Ressourcen beschränkt ist. Dabei ist der Bedarf eines einzelnen Knoten so wenig, dass hunderte bis tausende Knoten innerhalb eines Clusters möglich sind.
Übliche Anwendungen des Tribe Node sind:
- Organisatorische Einschränkungen: Verschiedene Teams sollen Zugriff auf ihren jeweils eigenen Cluster aber nicht auf die Cluster anderer Teams haben. Dennoch soll eine übergeordnete Instanz Zugriff auf alle Daten über eine gemeinsame Schnittstelle haben.
- Rechtliche Einschränkungen: Wenn Daten in einer bestimmten geographischen Position (z.B. ein bestimmtes Land) gespeichert werden müssen, die Daten jedoch zentral abgefragt werden sollen. (Achtung, ich bin kein Jurist. Ob dieses Konstrukt wirklich solche Einschränkungen erfüllt, ist in den einzelnen Fällen extra zu ermitteln!)
- Einschränken von Traffic: Besonders bei der Verwendung von Elasticsearch als Teil des ELK Stacks (also mit Logstash) werden oft sehr grosse Datenmengen in die Cluster geschrieben. Wird ein einzelner Cluster verwendet, um alle Daten aus Remote Offices oder verschiedenen Firewallzonen zu sammeln müssen entweder Daten vorgefiltert werden, wodurch auf Events verzichtet werden muss oder die grossen Datenmengen über Firewalls oder WAN Leitungen geschickt werden. Mit dem Tribe Node können die Daten lokal in eigenen Clustern gesammelt und zentral abgefragt werden, wobei nur die Anfrage und die aufbereitete Antwort übertragen werden müssen.
Die Konfiguration des Tribe Node ist denkbar einfach. Man gibt die Namen des Clusters in den folgenden Optionen in der /etc/elasticsearch/elasticsearch.yml
an und startet den Dienst. Dabei sollte der Tribe node selbst jedoch keine Daten enthalten.
tribe: es1: cluster.name: cluster1 discovery: zen: ping: multicast: enabled: false unicast: hosts: - 192.168.23.228:9300 es2: cluster.name: cluster2 discovery: zen: ping: multicast: enabled: false unicast: hosts: - 192.168.69.229:9300
Da sich die Cluster oft in verschiedenen Subnetzen befinden, wurde hier auch gleich multicast discovery deaktiviert und die Verbindungen zu Knoten aus den einzelnen Clustern per unicast hergestellt.
Wichtig ist, dass man am Tribe Node zwar lesen und schreiben, jedoch keine Indices anlegen kann. Will man also Kibana auf so einem Tribe Node nutzen, muss man den von Kibana zu nutzenden Index für eigene Daten (Dashboards, etc.) in einem der im Tribe Node zusammengefassten Cluster selbst anlegen bzw. Kibana erst mit einem der Cluster verbinden und den Index anlegen lassen, bevor man es auf den Tribe Node umleitet.
Mehr Info zum Tribe Node gibt’s in der Elasticsearch Dokumentation.
0 Kommentare