OpenSearch 3-Node Cluster – best practice

Um einen 3-Node OpenSearch Cluster aufzusetzen und zu betreiben ist nicht viel Knowhow notwendig, hin und wieder lohnt es sich aber mal die KI nach den best practice Umsetzungen zu befragen.

Prinzipiell decken sich diese mit meinen Erfahrungen im Betrieb mit Wazuh, aber es schadet sich nicht eine zweite Meinung von höherer Intelligenz einzuholen.

Frage: Was ist die empfohlene Menge an Nodes für einen Opensearchcluster?

OpenSearch (vormals bekannt als Elasticsearch) ist ein verteilter Such- und Analyse-Service, und die empfohlene Anzahl von Nodes für einen Cluster hängt von vielen Faktoren ab:

Datenmenge: Je mehr Daten Sie haben, desto mehr Nodes könnten Sie benötigen, um diese effizient zu speichern und abzufragen.
Anfragebelastung: Wenn Sie viele gleichzeitige Abfragen oder Indexierungsoperationen durchführen, könnten Sie mehr Nodes benötigen, um die Last zu verteilen.
Redundanz und Ausfallsicherheit: Für höhere Verfügbarkeit und Resilienz gegenüber Knotenausfällen sollten Sie mehrere Replikate Ihrer Daten haben, was bedeutet, dass Sie mehr Nodes benötigen.
Hardware-Ressourcen: Je nachdem, wie leistungsstark Ihre Server-Hardware ist, können Sie weniger oder mehr Nodes benötigen.

Einige allgemeine Empfehlungen:

Master-Nodes: Es wird oft empfohlen, 3 dedizierte Master-Nodes zu haben, um das Clustering und die Wahl des Hauptknotens zu verwalten. Dies sorgt für eine stabile Cluster-Topologie, auch wenn ein Master-Node ausfällt.
Data-Nodes: Die Anzahl der Data-Nodes hängt von der Datenmenge und der Anfragebelastung ab. Es ist oft sinnvoll, mit wenigen Data-Nodes zu beginnen und je nach Bedarf zu skaliieren.
Client- oder Koordinations-Nodes: Diese Nodes können dazu verwendet werden, Anfragen von Clients zu koordinieren und die Last von Data-Nodes zu nehmen.
Ingest-Nodes: Wenn Sie Datenverarbeitungspipelines verwenden, könnten Sie auch Ingest-Nodes benötigen.

Es ist wichtig zu beachten, dass es keine „Einheitsgröße“ für OpenSearch-Cluster gibt. Eine gute Methode ist es, mit einer kleineren Konfiguration zu beginnen und den Cluster zu überwachen, um Flaschenhälse oder Ressourcenengpässe zu identifizieren. Dann können Sie basierend auf den erfassten Metriken und Anforderungen skalieren.

Wenn Sie spezifische Details über Ihre Anwendung und Anforderungen haben, kann ich Ihnen eine genauere Empfehlung geben.

Frage: Sollte dann die Anzahl aufgrund von Quorum ungerade sein?

Ja, das Konzept des „Quorums“ ist wichtig, wenn es um die Wahl eines Master-Knotens in einem verteilten System wie OpenSearch (vormals Elasticsearch) geht. Der Grund dafür ist, dass Sie sicherstellen wollen, dass es bei einem Split-Brain-Problem (wenn der Cluster in zwei oder mehr Teile aufgeteilt wird) einen klaren Mechanismus gibt, um festzustellen, welcher Teil des Clusters die „wahre“ oder „autoritative“ Version des Clusters ist.

Das Quorum wird oft so beschrieben:

Quorum=Anzahl der Master-Node-kandidaten/2+1Quorum=2Anzahl der Master-Node-kandidaten+1

Betrachten wir ein paar Beispiele:

Bei 3 Master-Nodes benötigen Sie mindestens 2 (d.h., (3/2)+1) Master-Nodes, um einen Konsens zu erreichen. Dies bedeutet, dass selbst wenn eine Master-Node ausfällt, die verbleibenden zwei Nodes immer noch den Cluster funktionstüchtig halten können.
Bei 5 Master-Nodes benötigen Sie 3 (d.h., (5/2)+1) für ein Quorum. Hier könnten sogar zwei Nodes ausfallen und der Cluster wäre immer noch in der Lage, eine Wahl abzuhalten und einen neuen Master zu bestimmen.

Ein ungerader Wert von Master-Nodes ist deshalb empfehlenswert, weil er eine größere Fehlertoleranz bietet, ohne dass Sie mehr Nodes hinzufügen müssen, als technisch für ein Quorum erforderlich wäre. Zum Beispiel bieten sowohl 4 als auch 5 Master-Nodes eine Fehlertoleranz von 2, aber 5 bietet eine zusätzliche Redundanz ohne Veränderung des Quorums.

Daher ist es eine verbreitete Empfehlung, eine ungerade Anzahl von dedizierten Master-Nodes zu haben, wobei 3 ein gängiger Ausgangspunkt ist, um sowohl ein Quorum zu gewährleisten als auch eine gewisse Fehlertoleranz zu bieten.

Frage: Wenn bei 3 Master Nodes die zugleich auch Data Nodes sind, wie sollte das Replika und Shard setup für Opensearch am besten aussehen

Wenn Sie drei Nodes haben, die sowohl Master- als auch Data-Rollen übernehmen, gibt es einige spezifische Überlegungen, die Sie für die Konfiguration von Shards und Replikas berücksichtigen sollten:

Primärshards: Die Anzahl der Primärshards bestimmt, wie Sie Ihre Daten auf die Nodes verteilen können. Eine gute Regel ist, die Anzahl der Primärshards so zu wählen, dass sie sowohl den aktuellen als auch den zukünftigen Datenbedarf abdeckt, ohne jedoch zu viele Shards zu haben (was die Cluster-Leistung beeinträchtigen könnte).
Replikas: Für Ausfallsicherheit und Leseleistung sollten Sie mindestens eine Replika für jeden Primärshard haben. Da Sie drei Nodes haben, bedeutet eine Replika, dass bei Ausfall eines Nodes die Daten immer noch auf den anderen beiden Nodes verfügbar sind.

Hier ist ein einfaches Setup:

Primärshards: Die optimale Anzahl hängt von Ihrer Datenmenge ab. Betrachten Sie die Größe eines Shards, die Sie anstreben (oft zwischen 10 GB und 50 GB), und teilen Sie Ihre geschätzte Datenmenge durch diese Größe, um die Anzahl der Primärshards zu bestimmen.
Replikas: Setzen Sie mindestens 1 Replika für jeden Primärshard. Damit haben Sie insgesamt 2 Kopien Ihrer Daten (1 Primärshard + 1 Replikashard).

Beispielsweise:

Wenn Sie sich für 3 Primärshards entscheiden, könnten Sie diese Konfiguration haben:

Node 1: Primärshard A, Replikashard B, Replikashard C
Node 2: Primärshard B, Replikashard A, Replikashard C
Node 3: Primärshard C, Replikashard A, Replikashard B

Wenn einer der Nodes ausfällt, sind alle Daten immer noch auf den verbleibenden zwei Nodes verfügbar.

Wichtige Punkte:

Beachten Sie die Größe und Anzahl der Shards, um eine Über- oder Untersharding-Situation zu vermeiden. Zu viele kleine Shards können die Cluster-Performance beeinträchtigen, während zu wenige große Shards die Wiederherstellungszeiten verlängern und die Lastverteilung beeinträchtigen können.
Es ist auch wichtig zu bedenken, dass, während dieser Ansatz mit kombinierten Master- und Data-Nodes eine einfache und kostengünstige Lösung für kleinere Deployments darstellt, für größere, produktionsreife Setups dedizierte Master-Nodes und eine größere Anzahl von Data-Nodes empfohlen werden.

Frage: Wenn ein Index täglich erstellt wird und ca. 10GB groß ist, anhand des vorherigen Beispiels, wie würde die Konfiguration von opensearch.yml für die jeweiligen 3 Nodes aussehen?

Wenn Sie einen täglichen Index von ca. 10 GB erstellen und die vorherige 3-Node-Konfiguration verwenden möchten, sollten Sie einige spezifische Einstellungen in Ihrem opensearch.yml für jeden Node vornehmen. Bevor wir jedoch in die Konfiguration eintauchen, lassen Sie uns die Annahmen klären:

Jeder Node ist sowohl ein Master- als auch ein Data-Node.
Sie möchten eine Replika für jeden Primärshard, sodass bei Ausfall eines Nodes die Daten weiterhin auf den anderen Nodes verfügbar sind.

Für Ihren täglichen Index könnten Sie sich für einen Primärshard mit einer Replika entscheiden, was in diesem Fall ausreichend ist.

Hier ist ein einfacher Überblick über die Konfigurationen, die Sie für jeden der 3 Nodes in der opensearch.yml-Datei vornehmen sollten:

# Gemeinsame Einstellungen für alle Nodes

cluster.name: mein-cluster
node.name: node-X # Ersetzen Sie X durch die Nummer des jeweiligen Nodes (z.B. node-1, node-2, node-3)
network.host: [die IP-Adresse dieses Nodes]
http.port: 9200

# Jeder Node ist sowohl Master als auch Data
node.master: true
node.data: true

discovery.seed_hosts: ["IP-Adresse von Node-1", "IP-Adresse von Node-2", "IP-Adresse von Node-3"]
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]

Beachten Sie, dass Sie die node.name und network.host Werte entsprechend für jeden Node ändern müssen.

Beim Erstellen des täglichen Indexes können Sie die Anzahl der Primärshards und Replikas wie folgt festlegen:

PUT /mein-taeglicher-index-YYYY.MM.DD
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 2
  }
}

In diesem Fall würde jeder Node eine Kopie des Indexes enthalten (1 Primärshard und 2 Replikas verteilt über die 3 Nodes).

Abschließende Bemerkungen:

Überlegen Sie sich, ob Sie Monitoring- und Alarmierungsfunktionen (z.B. mit OpenSearch Dashboards) einrichten möchten, um den Gesundheitszustand Ihres Clusters zu überwachen.
Achten Sie auf die Hardware-Ressourcen und die JVM-Einstellungen, insbesondere den Heap-Speicher, um eine optimale Leistung und Stabilität des Clusters zu gewährleisten.

Frage: Aber würde denn nicht ein Replika ausreichen für die Ausfallsicherheit? So könnte Platz gespart werden?

Ja, Sie haben völlig recht. Ein Replikashard bietet bereits Ausfallsicherheit, da er eine exakte Kopie des Primärshards ist. Mit drei Nodes und einem Replikashard würden zwei Nodes jeweils eine Kopie der Daten haben (ein Primärshard auf einem Node und ein Replikashard auf einem anderen Node), und der dritte Node wäre bereit, im Falle eines Ausfalls einzuspringen.

Wenn Sie Speicherplatz sparen wollen und nur eine Kopie der Daten als Sicherung benötigen, dann ist eine Replika (also insgesamt zwei Kopien: der Primärshard und eine Replika) völlig ausreichend. Das Setup wäre dann wie folgt:

Beim Erstellen des täglichen Indexes:

PUT /mein-taeglicher-index-YYYY.MM.DD
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  }
}

Mit dieser Konfiguration:

Bei einem Node-Ausfall bleibt der Cluster funktionsfähig und verliert keine Daten.
Der Lese-Durchsatz kann durch die Abfrage von Primär- und Replikashards verbessert werden.
Sie sparen Speicherplatz im Vergleich zu zwei Replikas.

Zusammenfassend: Wenn Sie den Speicherplatz optimieren und dennoch eine gute Ausfallsicherheit gewährleisten möchten, ist eine Replika (plus der Primärshard) auf einem 3-Node-Cluster eine gute Wahl.

Frage: Und wie wird sichergestellt, dass bei 1 Primärshard und 1 Replika mit 3 Hosts die Replikas fair verteilt werden, dass nicht ein Node von den 3 Nodes der einilige Replikahalter ist?

OpenSearch (vormals Elasticsearch) hat eingebaute Mechanismen zur Verteilung von Shards über verschiedene Nodes, um das Risiko von Datenverlusten zu minimieren und die Lastverteilung zu optimieren. Das System wird versuchen, Primärshards und ihre zugehörigen Replikas auf verschiedene Nodes zu verteilen, um sicherzustellen, dass bei einem Node-Ausfall keine Daten verloren gehen.

Die folgenden Faktoren und Einstellungen beeinflussen die Verteilung der Shards:

Cluster-Routing-Allokation: OpenSearch versucht automatisch, eine gleichmäßige Verteilung von Shards über die verfügbaren Nodes sicherzustellen. Der Cluster-Routing-Mechanismus steuert, wo Shards platziert werden und wie sie bei Bedarf verschoben werden.
cluster.routing.allocation.same_shard.host: Diese Einstellung verhindert, dass der Primärshard und seine Replikas auf dem gleichen physischen Server oder virtuellen Host platziert werden, wenn die Nodes mehrere Instanzen auf dem gleichen physischen/virtuellen Host laufen lassen. Diese sollte auf true gesetzt werden, um dies zu verhindern.
Shard Rebalancing: OpenSearch führt kontinuierlich einen Rebalancing-Prozess durch, bei dem versucht wird, die Shards gleichmäßig über die Nodes zu verteilen.

In einem 3-Node-Setup mit einem Primärshard und einer Replika wird OpenSearch in der Regel den Primärshard auf einen Node und die Replika auf einen anderen Node legen. Der dritte Node bleibt dann für zukünftige Shards oder Rebalancing-Aktionen verfügbar.

Es ist jedoch möglich, dass aufgrund von Cluster-Ereignissen (wie dem Neustart von Nodes) temporäre Ungleichgewichte in der Shard-Verteilung auftreten. Im Laufe der Zeit sollte sich dies jedoch durch den eingebauten Rebalancing-Mechanismus wieder ausgleichen.

Wenn Sie feststellen, dass Ihre Shards über einen längeren Zeitraum nicht wie erwartet verteilt sind, können Sie spezifische Allokationsregeln und -einstellungen verwenden, um die Verteilung weiter zu steuern. Das ist jedoch in den meisten Standardsetups nicht erforderlich, da OpenSearch bereits darauf ausgelegt ist, die Datenverteilung zu optimieren und Ausfallsicherheit zu gewährleisten.