Optimale Shard-Größe: Balance zwischen Cluster-Leistung und Verwaltung

Die Shard-Größenbestimmung ist eine dieser Elasticsearch-Entscheidungen, die einfach erscheint, bis der Cluster einige Monate läuft. Ein Shard ist unter der Haube nur ein Lucene-Index, aber jeder Shard verursacht Overhead. Zu viele kleine Shards lassen den Cluster damit beschäftigt sein, Metadaten und winzige Suchziele zu verwalten. Zu wenige große Shards machen Verschiebung, Wiederherstellung und einige Suchvorgänge schmerzhaft langsam.

Es gibt keine universelle Shard-Größe, die für jeden Cluster funktioniert. Ein Logging-Cluster mit täglichem Rollover, ein Produktsuchindex und ein Sicherheitsanalyse-Cluster verhalten sich alle unterschiedlich. Der sinnvolle Ansatz ist, eine Ziel-Shard-Größe zu wählen, Rollover oder Indexerstellung darum herum zu entwerfen und dann basierend auf dem tatsächlichen Indizierungs- und Abfrageverhalten anzupassen.

Die Grundlagen von Elasticsearch-Shards

Bevor wir uns mit Größenbestimmungsstrategien befassen, ist es wichtig, die grundlegenden Konzepte zu verstehen:

• Index: Eine Sammlung von Dokumenten. In Elasticsearch wird ein Index in mehrere Shards unterteilt.
• Shard: Eine Verteilungseinheit. Jeder Shard ist ein eigenständiger Lucene-Index. Ein Index kann mehrere Shards enthalten, die auf verschiedene Knoten im Cluster verteilt sind.
• Primär-Shard: Wenn ein Index erstellt wird, wird ihm eine Anzahl von Primär-Shards zugewiesen. Diese Shards sind der Ort, an dem Ihre Daten indiziert werden. Sie können number_of_shards in einem vorhandenen Index nicht einfach bearbeiten, aber Elasticsearch bietet unter bestimmten Bedingungen Split- und Shrink-Operationen an. Viele Teams betrachten die Anzahl der Primär-Shards dennoch als eine Entscheidung zur Entwurfszeit, da eine spätere Änderung Planung erfordert.
• Replikat-Shard: Kopien Ihrer Primär-Shards. Sie bieten Redundanz und erhöhen den Lesedurchsatz. Wenn ein Primär-Shard ausfällt, kann ein Replikat zum Primär-Shard befördert werden. Die Anzahl der Replikat-Shards kann jederzeit geändert werden.

Wie Shards die Leistung beeinflussen

• Indizierungsleistung: Jeder Shard benötigt Ressourcen für die Indizierung. Mehr Shards bedeuten mehr Overhead für die koordinierenden Knoten, die Anfragen verwalten. Wenn Shards jedoch zu groß werden, kann die Indizierung in einen einzelnen Shard zu einem Engpass werden.
• Abfrageleistung: Suchanfragen werden an alle relevanten Primär-Shards verteilt. Eine höhere Anzahl von Shards kann die Anzahl der zu verarbeitenden Anfragen erhöhen und möglicherweise die Latenzzeit erhöhen. Umgekehrt können sehr große Shards zu längeren Suchzeiten führen, da Lucene innerhalb dieses Shards mehr Daten verarbeiten muss.
• Cluster-Verwaltung: Eine große Anzahl von Shards erhöht die Last auf dem Master-Knoten, der für die Verwaltung des Cluster-Zustands verantwortlich ist. Es wirkt sich auch auf den Overhead von Operationen wie Shard-Verschiebung, Snapshot-Erstellung und Wiederherstellung aus.
• Ressourcennutzung: Jeder Shard verbraucht Speicher und Festplatten-I/O. Zu viele Shards können die Knotenressourcen erschöpfen, was zu einer verschlechterten Leistung oder Knoteninstabilität führt.

Wichtige Überlegungen zur Shard-Größenbestimmung

Die „ideale“ Shard-Größe ist keine feste Zahl; sie hängt von Ihrer spezifischen Arbeitslast, den Datenmerkmalen und der Hardware ab. Mehrere Faktoren sollten jedoch Ihre Entscheidungen leiten:

1. Datenvolumen und Wachstumsrate

• Aktuelle Datengröße: Wie viele Daten haben Sie derzeit in Ihrem Index?
• Wachstumsrate: Wie schnell wachsen Ihre Daten? Dies hilft, zukünftige Shard-Größen vorherzusagen.
• Datenaufbewahrungsrichtlinie: Werden Sie alte Daten löschen? Dies wirkt sich auf die effektive Größe der aktiven Daten aus.

2. Indizierungslast

• Indizierungsrate: Wie viele Dokumente pro Sekunde indizieren Sie?
• Dokumentgröße: Wie groß sind einzelne Dokumente im Durchschnitt?
• Indizierungsdurchsatz: Können Ihre Knoten die Indizierungslast mit der aktuellen Shard-Konfiguration bewältigen?

3. Abfragemuster

• Abfragekomplexität: Sind Ihre Abfragen einfache Stichwortsuche oder komplexe Aggregationen?
• Abfragehäufigkeit: Wie oft werden Abfragen gegen Ihre Daten ausgeführt?
• Latenzanforderungen für Abfragen: Was sind Ihre akzeptablen Antwortzeiten?

4. Cluster-Topologie und Ressourcen

• Anzahl der Knoten: Wie viele Knoten sind in Ihrem Cluster?
• Knotenhardware: CPU, RAM und Festplatte (SSD wird für Elasticsearch dringend empfohlen).
• Shard-Limits: Elasticsearch enthält Sicherheitsgrenzen, die verhindern, dass ein Knoten eine übermäßige Anzahl offener Shards hält. Neuere Versionen verwenden üblicherweise cluster.max_shards_per_node als clusterweite Leitplanke für normale offene Indizes. cluster.routing.allocation.total_shards_per_node ist anders: Es begrenzt, wie viele Shards von einem einzelnen Index oder einem übereinstimmenden Zuordnungsbereich einem Knoten zugewiesen werden können. Überprüfen Sie Ihre Elasticsearch-Version, bevor Sie eine dieser Einstellungen ändern.

Best Practices für die Shard-Zuweisung

1. Zielen Sie auf eine Ziel-Shard-Größe ab

Obwohl es keine magische Zahl gibt, zielen viele Produktionscluster für gängige Log- und Such-Workloads auf Shards von etwa 10 GB bis 50 GB ab. Dieser Bereich ist ein Ausgangspunkt, keine Regel. Systeme mit sehr hohem Durchsatz oder langer Aufbewahrungsdauer können nach Tests größere Shards wählen; kleine Unternehmenssuchindizes funktionieren möglicherweise am besten mit einem einzigen kleinen Shard.

• Zu klein (< 10 GB): Kann zu übermäßigem Overhead führen. Jeder Shard hat einen Speicher-Fußabdruck und trägt zur Last des Master-Knotens bei. Die Verwaltung Tausender winziger Shards wird zu einer erheblichen betrieblichen Belastung.
• Zu groß (> 50 GB): Kann Leistungsprobleme verursachen. Segmentzusammenführung, Wiederherstellung und Neuausrichtungsvorgänge dauern länger. Wenn ein großer Shard ausfällt, kann die Wiederherstellung erhebliche Zeit in Anspruch nehmen.

2. Erwägen Sie zeitbasierte Indizes

Für Zeitreihendaten (Logs, Metriken, Ereignisse) ist die Verwendung zeitbasierter Indizes eine standardmäßige und äußerst effektive Praxis. Dabei werden neue Indizes für bestimmte Zeiträume (z. B. täglich, wöchentlich, monatlich) erstellt.

• Beispiel: Anstelle eines massiven Index könnten Sie logs-2023.10.26, logs-2023.10.27 usw. haben.
• Vorteile: Einfachere Datenverwaltung (Löschen alter Indizes über Index Lifecycle Management - ILM), bessere Leistung, da Abfragen oft auf aktuelle Daten abzielen, und kontrollierte Shard-Größen.

3. Implementieren Sie Index Lifecycle Management (ILM)

ILM-Richtlinien ermöglichen es Ihnen, die Indexverwaltung basierend auf Alter, Größe oder Dokumentanzahl zu automatisieren. Sie können Phasen für einen Index definieren (hot, warm, cold, delete) und Aktionen für jede Phase festlegen, einschließlich der Änderung der Anzahl der Replikate, des Verkleinerns von Indizes oder des Löschens.

• Hot-Phase: Der Index wird aktiv beschrieben und abgefragt. Maximieren Sie die Leistung.
• Warm-Phase: Der Index wird nicht mehr beschrieben, aber noch abgefragt. Kann auf weniger leistungsfähige Hardware verschoben werden, möglicherweise mit weniger Replikaten oder verkleinert.
• Cold-Phase: Selten abgefragt. Daten können je nach Elasticsearch-Lizenz, -Version und -Architektur auf günstigeren Speicher oder leistungsschwächere Knoten verschoben werden.
• Delete-Phase: Daten werden nicht mehr benötigt und gelöscht.

4. Vermeiden Sie Über-Sharding

Über-Sharding tritt auf, wenn Sie weitaus zu viele Shards für Ihre Clustergröße und Ihr Datenvolumen haben. Dies ist eine häufige Falle, die zu schlechter Leistung und Verwaltungsproblemen führt.

• Symptome: Hohe CPU-Auslastung auf Master-Knoten, langsame Cluster-Zustandsaktualisierungen, lange Wiederherstellungszeiten und allgemeine Trägheit.
• Abhilfe: Planen Sie Ihre Anzahl der Primär-Shards von Anfang an. Beginnen Sie bei zeitbasierten Indizes mit einer angemessenen Anzahl von Primär-Shards pro Index (z. B. 1 oder 3). Sie können später jederzeit Replikate hinzufügen.

5. Über-Indizieren Sie nicht

Vermeiden Sie ebenfalls die Erstellung einer übermäßigen Anzahl von Indizes, wenn dies nicht erforderlich ist. Jeder Index verursacht Overhead. Für Nicht-Zeitreihendaten, bei denen Sie keinen natürlichen Partitionierungsmechanismus haben, überlegen Sie, ob ein einzelner Index mit angemessener Shard-Anzahl ausreicht.

6. Berücksichtigen Sie die Einstellung number_of_shards

Beim Erstellen eines Index definiert der Parameter number_of_shards die Anzahl der Primär-Shards. Diese Einstellung ist nach der Indexerstellung unveränderlich.

PUT my-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,  // Beispiel: 3 Primär-Shards
      "number_of_replicas": 1   // Beispiel: 1 Replikat-Shard
    }
  }
}

• Tipp: Für kleinere Indizes oder solche mit sehr geringer Indizierungs-/Abfragelast kann ein einzelner Primär-Shard ausreichen. Für größere, aktivere Indizes können 3 oder 5 Primär-Shards eine bessere Verteilung und Ausfallsicherheit bieten, insbesondere wenn Sie planen, den Index später aufzuteilen (obwohl das Aufteilen komplex ist).

7. Neuausrichtung und Verschiebung

Elasticsearch gleicht Shards automatisch neu aus, um eine gleichmäßige Verteilung über die Knoten sicherzustellen. Wenn Shards jedoch zu groß sind, können diese Vorgänge ressourcenintensiv und langsam sein. Kleinere, zahlreichere Shards können manchmal schneller neu ausbalanciert werden, aber dies wird durch den Overhead der Verwaltung von mehr Shards ausgeglichen.

8. Abfrageleistungsoptimierung

Wenn Ihre Abfrageleistung leidet, bewerten Sie Ihre Shard-Strategie. Erwägen Sie:

• Anzahl der Shards: Zu viele Shards können den Koordinationsaufwand erhöhen.
• Shard-Größe: Sehr große Shards können die Segmentzusammenführung und die Suche innerhalb des Shards verlangsamen.
• Index-Design: Verwenden Sie geeignete Mappings und Analyzer?

Berechnung Ihrer optimalen Shard-Anzahl

Es gibt keine einzelne Formel, aber hier ist ein gängiger Ansatz:

1. Schätzen Sie Ihr gesamtes Datenvolumen pro Index über seinen Lebenszyklus.
2. Bestimmen Sie Ihre Ziel-Shard-Größe (z. B. 30 GB).
3. Berechnen Sie die Anzahl der benötigten Primär-Shards: Gesamtdatenvolumen / Ziel-Shard-Größe.
4. Runden Sie auf die nächste ganze Zahl auf. Dies ergibt Ihre number_of_shards für den Index.
   • Beispiel: Wenn Sie 90 GB Daten erwarten und auf 30 GB Shards abzielen, benötigen Sie 90 GB / 30 GB = 3 Primär-Shards.
5. Berücksichtigen Sie Ausfallsicherheit und Verteilung: Erwägen Sie für kritische Indizes die Verwendung von 3 oder 5 Primär-Shards, um eine bessere Verteilung und Wiederherstellungsoptionen zu ermöglichen, auch wenn Ihr anfängliches Datenvolumen dies nicht unbedingt erfordert. Der Kompromiss ist erhöhter Overhead.
6. Beginnen Sie konservativ: Es ist im Allgemeinen einfacher, Replikate hinzuzufügen, als die Anzahl der Primär-Shards zu ändern (was normalerweise eine Neuindizierung oder komplexe Workarounds erfordert). Wenn Sie unsicher sind, beginnen Sie mit weniger Primär-Shards und überwachen Sie die Leistung.

Beispielszenario: Log-Analyse

Angenommen, Sie indizieren Anwendungslogs:

• Datenvolumen: Sie erwarten 1 TB Logs pro Monat.

• Datenaufbewahrung: Sie behalten Logs für 30 Tage.

• Ziel-Shard-Größe: Sie zielen auf 20 GB ab.

• Tägliche Indizes: Sie erstellen tägliche Indizes (logstash-YYYY.MM.DD). Jeder tägliche Index enthält ungefähr 1 TB / 30 Tage ≈ 33 GB Daten.

• Primär-Shards pro Index: Angesichts des 20-GB-Ziels und des täglichen Volumens von 33 GB könnten Sie 2 Primär-Shards pro Index wählen (33 GB / 20 GB ≈ 1,65, aufgerundet auf 2). Dadurch wird sichergestellt, dass einzelne Shards innerhalb Ihrer Zielgröße bleiben.

• Replikate: Sie entscheiden sich für 1 Replikat für hohe Verfügbarkeit.

• Gesamtzahl der Shards: Über den 30-tägigen Aufbewahrungszeitraum haben Sie 30 Indizes, jeder mit 2 Primär- und 2 Replikat-Shards, insgesamt also 60 Primär- und 60 Replikat-Shards, die zu jedem Zeitpunkt aktiv sind.

Dieser Ansatz hält einzelne Shards handhabbar und ermöglicht eine effiziente Datenlöschung durch einfaches Löschen alter Indizes.

Was normalerweise schief geht

Das häufigste Problem ist das Über-Sharding aus Gewohnheit. Jemand erstellt tägliche Indizes mit fünf Primär-Shards und einem Replikat, weil ein altes Tutorial diese Einstellung verwendet hat. Es sieht zunächst harmlos aus. Dann hat der Cluster Hunderte kleiner Indizes, Tausende winziger Shards, und Master-Knoten verbringen zu viel Zeit mit Cluster-Zustandsaktualisierungen. Suchvorgänge verteilen sich auch auf viele Shards, was Koordinationsaufwand hinzufügt, bevor die eigentliche Abfragearbeit überhaupt beginnt.

Das gegenteilige Problem zeigt sich während der Wiederherstellung. Einige wenige riesige Shards können an einem normalen Tag akzeptabel abfragen, aber wenn ein Knoten ausfällt oder ein rollierender Neustart beginnt, dauert die Verschiebung lange. Snapshots und Wiederherstellungen können ebenfalls langsamer werden, da jeder Shard eine große Arbeitseinheit ist. Wenn Ihr Wiederherstellungsziel eng ist, ist die Shard-Größe wichtig, selbst wenn die Abfragelatenz in Ordnung aussieht.

Heiße Shards sind ein weiteres praktisches Problem. Wenn alle neuen Schreibvorgänge auf einen Primär-Shard gehen, wird das Hinzufügen weiterer Knoten diese Schreiblast nicht automatisch verteilen. Zeitbasierter Rollover hilft, weil neue Indizes für das aktuelle Verkehrsmuster dimensioniert werden können. Routing-Entscheidungen sind ebenfalls wichtig. Benutzerdefiniertes Routing kann leistungsstark sein, aber ein schlechter Routing-Schlüssel kann zu viele Daten an einen Shard senden.

Ein besseres Rollover-Muster

Für Zeitreihendaten ist ein Rollover basierend auf der Größe oft einfacher zu verwalten als feste tägliche Indizes. Anstatt unabhängig vom Volumen einen Index pro Tag zu erstellen, erstellen Sie einen Schreib-Alias und lassen ILM den Rollover durchführen, wenn der Index eine Zielgröße, ein Zielalter oder eine Ziel-Dokumentanzahl erreicht.

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "30gb",
            "max_age": "1d"
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Mit diesem Muster erzeugt ein ruhiges Wochenende möglicherweise weniger Indizes, während ein geschäftiger Vorfallstag früher umgeschaltet werden kann. Sie müssen dennoch die anfängliche Anzahl der Primär-Shards wählen, aber der Rollover verhindert, dass das Shard-Wachstum zu weit vom Ziel abweicht.

So überprüfen Sie Ihre aktuellen Shards

Bevor Sie etwas ändern, sehen Sie sich den Cluster an, den Sie haben:

GET _cat/shards?v&h=index,shard,prirep,state,docs,store,node&s=store:desc
GET _cat/indices?v&h=index,pri,rep,docs.count,store.size,pri.store.size&s=pri.store.size:desc
GET _cluster/health

Sie suchen nach Mustern: viele winzige Shards, einige wenige riesige Shards, nicht zugewiesene Shards, ungleiche Knotenplatzierung oder Indizes, deren primäre Speichergröße weit von Ihrem beabsichtigten Ziel entfernt ist. Wenn ein Index 100 GB Primärdaten und fünf Primär-Shards hat, hat jeder Primär-Shard vor Replikaten ungefähr 20 GB. Wenn derselbe Index 100 GB und 50 Primär-Shards hat, haben Sie wahrscheinlich unnötigen Overhead erzeugt.

Abschließende Bemerkungen

Eine gute Shard-Größenbestimmung dreht sich weniger um die Jagd nach einer perfekten Zahl, sondern mehr darum, den Cluster einfach zu betreiben. Beginnen Sie mit einem vernünftigen Ziel, verwenden Sie ILM oder Rollover, wo das Datenmuster passt, und beobachten Sie, was tatsächlich mit der Shard-Größe, dem Abfrage-Fan-Out, der Wiederherstellungszeit und dem Knotendruck passiert. Wenn Ihr Cluster bereits über-Sharded ist, beheben Sie es schrittweise mit neuen Indexvorlagen, Rollover, Shrink oder Neuindizierung, anstatt zu versuchen, jeden alten Index auf einmal in eine neue Form zu zwingen.