Leitfaden zu Elasticsearch-Cluster-Skalierungsstrategien für Wachstum

Die Skalierung eines Elasticsearch-Clusters wird dringend, wenn Suchen langsamer werden, Indizierungswarteschlangen anwachsen oder Festplatten schneller als erwartet volllaufen. Wenn Datenmengen und Abfragelasten steigen, müssen Sie wissen, ob Sie Ressourcen zu bestehenden Knoten hinzufügen, weitere Knoten hinzufügen, die Shard-Strategie ändern oder heiße Indizes neu gestalten sollten.

Dieser Leitfaden behandelt vertikale und horizontale Skalierung, Knotenrollen, Shard-Größenbestimmung und praktische Schritte zum Wachsen eines Clusters ohne Rätselraten.

Grundlagen der Elasticsearch-Skalierung verstehen

Die Skalierung eines Elasticsearch-Clusters umfasst hauptsächlich zwei Strategien: Vertikale Skalierung (Scale-Up) und Horizontale Skalierung (Scale-Out). Die optimale Strategie beinhaltet oft eine sorgfältige Balance beider, bestimmt durch Ihre Arbeitslastcharakteristiken.

Vertikale Skalierung (Scale-Up)

Vertikale Skalierung bedeutet, die Ressourcen vorhandener Knoten zu erhöhen. Dies ist der einfachste Ansatz, stößt aber schnell an physische Grenzen.

Wann vertikale Skalierung verwenden:

• Wenn Latenz das Hauptproblem ist und Sie schnellere Abfrageantworten aus dem vorhandenen Datensatz benötigen.
• Bei kurzfristigem Druck, wenn das Hinzufügen und Neuausgleichen neuer Knoten länger dauern würde als die benötigte Entlastung.

Primäre Ressourcen-Upgrades:

1. RAM (Arbeitsspeicher): Elasticsearch benötigt JVM-Heap und einen großen OS-Dateisystem-Cache. Ein üblicher Ausgangspunkt ist, den Heap nahe 50% des System-RAMs zu setzen, während die komprimierte OOP-Grenze (Compressed Ordinary Object Pointer) unterschritten wird, oft etwa 26-32 GB, abhängig von der JVM.
2. CPU: Notwendig für komplexe Aggregationen, starke Indizierung und hohe Abfrageparallelität.
3. Speicher (Festplatten-I/O): Schnellere SSDs oder NVMe-Laufwerke verbessern den Indizierungsdurchsatz und die Suchgeschwindigkeit erheblich, besonders bei I/O-intensiven Arbeitslasten.

Warnung zur vertikalen Skalierung: Sehr große JVM-Heaps können die Vorteile komprimierter OOPs verlieren und unter längeren Garbage-Collection-Pausen leiden. Zusätzlicher RAM ist immer noch nützlich für den Dateisystem-Cache, aber die Heap-Größe nach oben zu treiben, ist kein langfristiger Skalierungsplan.

Horizontale Skalierung (Scale-Out)

Horizontale Skalierung bedeutet, weitere Knoten zum Cluster hinzuzufügen. Dies verteilt die Daten und die Abfragelast auf mehrere Maschinen und bietet nahezu lineare Skalierbarkeit und hohe Verfügbarkeit.

Wann horizontale Skalierung verwenden:

• Wenn das Datenvolumen die Kapazität vorhandener Knoten übersteigt.
• Wenn Sie den gesamten Indizierungsdurchsatz oder die Abfrageparallelität verbessern müssen.
• Als primäre Strategie für langfristiges, nachhaltiges Wachstum.

Horizontale Skalierung wird durch das Hinzufügen neuer Datenknoten erreicht. Koordinierungsknoten können ebenfalls hinzugefügt werden, aber typischerweise treibt die Erweiterung der Datenknoten das Kapazitätswachstum voran.

Architekturbest Practices für Skalierbarkeit

Skalierung bedeutet mehr als nur das Hinzufügen von Hardware; es erfordert eine gut strukturierte Index- und Knotentopologie.

Knotenrollen und Spezialisierung

Moderne Elasticsearch-Bereitstellungen profitieren erheblich von der Zuweisung dedizierter Rollen zu Knoten, besonders in größeren Clustern. Dies verhindert Ressourcenkonflikte zwischen schweren Aufgaben (wie Indizierung) und kritischen Aufgaben (wie Koordinierung von Suchen).

Knotenrolle	Hauptverantwortung	Best Practice Überlegung
Master-Knoten	Cluster-Zustandsverwaltung, Stabilität.	Dedizierter Satz von 3 oder 5 Knoten. Sollten keine Daten- oder Ingest-Anfragen bearbeiten.
Datenknoten	Speichern von Daten, Indizieren, Suchen.	Diese aggressiv basierend auf Datenvolumen und Last skalieren.
Ingest-Knoten	Vorverarbeitung von Dokumenten vor der Indizierung (mittels Ingest-Pipelines).	CPU-intensive Vorverarbeitung von Datenknoten auslagern.
Koordinierungsknoten	Bearbeitung großer Suchanfragen, Sammeln von Ergebnissen von Datenknoten.	Diese hinzufügen, wenn Suchanfragen komplex werden oder Datenknoten häufig mit Koordinierungsaufwand überlasten.

Shard-Allokationsstrategie

Shards sind die grundlegende Einheit der Verteilung und Parallelität in Elasticsearch. Schlechte Shard-Allokation ist die häufigste Ursache für Skalierungsprobleme.

1. Optimierung der Anzahl primärer Shards

Die Wahl der richtigen Anzahl primärer Shards (index.number_of_shards) ist kritisch und kann nach der Indexerstellung nicht einfach geändert werden (außer mit Index-Aliasen oder Reindexing).

• Zu wenige Shards: Begrenzt die Parallelität bei Suchen und verhindert effektive horizontale Skalierung.
• Zu viele Shards: Erhöht den Cluster-Zustands-Overhead, steigert die Speichernutzung und erzeugt das "Klein-Shard-Problem", bei dem Koordinierungskosten die nützliche Arbeit dominieren.

Best Practice: Für viele Zeitreihen- und Logging-Workloads zielen Sie auf Shard-Größen im zweistelligen Gigabyte-Bereich ab, oft etwa 10 GB bis 50 GB. Behandeln Sie dies als Ausgangsbereich und testen Sie dann mit Ihrer eigenen Indizierungsrate, Ihrem Aufbewahrungsfenster und Ihrem Abfragemuster.

2. Replikat-Shards für hohe Verfügbarkeit und Lesedurchsatz

Replikat-Shards (index.number_of_replicas) bieten Redundanz und erhöhen die Lesekapazität.

• Die Einstellung number_of_replicas: 1 bedeutet, dass jeder primäre Shard eine Kopie hat, was hohe Verfügbarkeit (HA) gewährleistet.
• Die Erhöhung von Replikaten kann die Lesekapazität verbessern, da Suchen von primären oder Replikat-Kopien bedient werden können, erhöht aber auch die Speichernutzung und den Indizierungsaufwand.

Beispiel für HA-Setup: Wenn Sie 10 primäre Shards haben und number_of_replicas: 1 setzen, benötigt der Cluster mindestens 20 Shard-Kopien insgesamt (10 primäre + 10 Replikate), die über die Knoten verteilt sind.

PUT /my_growing_index
{
  "settings": {
    "index.number_of_shards": 20,
    "index.number_of_replicas": 1 
  }
}

Hotspots mit Awareness verhindern

Stellen Sie beim Hinzufügen neuer Knoten sicher, dass Shards über Ausfalldomänen verteilt werden. Elasticsearch gleicht automatisch neu aus, aber Zone- oder Rack-Awareness funktioniert nur, wenn Sie Knotenattribute und Allokations-Awareness-Einstellungen konfigurieren.

Verwenden Sie die Cluster Allocation Explainer API, um zu diagnostizieren, warum Shards möglicherweise nicht zu neuen Knoten verschoben werden oder warum ein Knoten überlastet ist.

Praktische Skalierungsschritte: Umgang mit Wachstum

Wenn die Clusterleistung nachlässt (hoher JVM-Heap-Druck, langsame Abfragen, langsame Indizierung), führen Sie diese Schritte in der Reihenfolge durch:

Schritt 1: Überwachen und Diagnostizieren

Bevor Sie Änderungen vornehmen, diagnostizieren Sie den Engpass. Häufige Indikatoren:

• Hohe CPU/Niedriger freier Speicher: Deutet auf Rechen- oder Speicherhunger hin (potenzieller vertikaler Skalierungsbedarf).
• Übermäßige Festplatten-Warteschlangenlänge: Deutet auf I/O-Engpass hin (schnellere Festplatten oder Knotenhinzufügung erforderlich).
• Suchlatenzspitzen: Oft auf unzureichendes Caching oder zu wenige Shards/Replikate zurückzuführen (erfordert mehr Speicher oder horizontale Skalierung).

Schritt 2: Sofortige Ressourcenbedürfnisse angehen (Vertikale Anpassungen)

Wenn der Speicherdruck hoch ist, erhöhen Sie die JVM-Heap-Größe innerhalb sicherer Grenzen (max. 32 GB) und stellen Sie sicher, dass ausreichend RAM für den OS-Dateisystem-Cache verfügbar ist.

Schritt 3: Horizontal skalieren (Horizontale Erweiterung)

Wenn Sie Knoten hinzufügen, befolgen Sie dieses Verfahren:

1. Stellen Sie neue Datenknoten mit identischer oder überlegener Hardware bereit.
2. Konfigurieren Sie sie mit den richtigen Rollen. Für Kapazitätswachstum bedeutet dies normalerweise Datenrollen wie data_hot, data_content oder data, abhängig von Ihrer Bereitstellung.
3. Weisen Sie sie auf den bestehenden Cluster mit discovery.seed_hosts.
4. Sobald die neuen Knoten beigetreten sind, beginnt Elasticsearch automatisch mit dem Neuausgleich vorhandener Shards, um die neue Kapazität zu nutzen.

Schritt 4: Zukunftssichere Indizes (Reindexing)

Wenn vorhandene Indizes suboptimale Shard-Anzahlen haben, können sie die neuen Knoten nicht vollständig nutzen. Sie müssen sie neu aufbauen:

1. Erstellen Sie eine neue Indexvorlage oder verwenden Sie die Create Index API mit der gewünschten Anzahl von Shards und Replikaten.
2. Verwenden Sie die Reindex API, um Daten vom alten, schlecht dimensionierten Index zum neuen zu migrieren.
3. Sobald die Migration abgeschlossen ist, leiten Sie den Datenverkehr über einen Alias um.

Beispiel für einen Reindex-Befehl:

POST _reindex
{
  "source": {
    "index": "old_index_bad_shards"
  },
  "dest": {
    "index": "new_index_optimized_shards"
  }
}

Checkliste für Best Practices

Die Skalierung von Elasticsearch funktioniert am besten, wenn Sie zuerst überwachen, jeweils eine Variable ändern und das Shard-Layout an Ihr Wachstumsmuster anpassen.

Wichtige Erkenntnisse:

• Horizontale Skalierung priorisieren: Sie bietet den besten Weg für kontinuierliches Wachstum und Ausfallsicherheit.
• Dedizierte Master-Knoten: Halten Sie das Cluster-Management stabil, indem Sie Master-Rollen trennen.
• Shard-Größenbestimmung ist dauerhaft: Streben Sie bei der Indexerstellung eine primäre Shard-Größe von 10 GB bis 50 GB an.
• JVM-Heap überwachen: Halten Sie den Heap unterhalb der komprimierten Zeigerschwelle für Ihre JVM und lassen Sie genügend RAM für den OS-Cache.
• Reindexing verwenden: Bauen Sie kritische Indizes neu auf, wenn die horizontale Skalierung eine Änderung der Anzahl primärer Shards erfordert.