Größengerechte Planung Ihrer Elasticsearch-Datenspeicherarchitektur
Mit Elasticsearch können Sie große Mengen an strukturierten und unstrukturierten Daten speichern, durchsuchen und analysieren. Der Elastic Stack mit seiner Geschwindigkeit, Skalierbarkeit und Flexibilität ist eine leistungsstarke Lösung für eine Vielzahl von Anwendungsfällen, wie etwa System-Observability, Sicherheit (Erkennung und Vermeidung von Bedrohungen), Enterprise Search und vieles mehr. Durch diese Flexibilität ist es besonders wichtig, dass Sie den Datenspeicher für Ihr Deployment unter Berücksichtigung der Größe effektiv planen.
Es leuchtet ein, dass jeder Elasticsearch-Anwendungsfall seine Eigenheiten hat. Für Ihren Anwendungsfall, Ihr Deployment oder Ihre geschäftliche Situation gelten bestimmte Toleranzen und Schwellenwerte, etwa für Betriebskosten, Ingestions- und Abfrageleistung, Anzahl und Größe der Backups, mittlere Wiederherstellungsfrist usw.
Wenn Sie sich also mit diesen Faktoren befassen, sollten Sie sich drei Fragen stellen, um eine andernfalls ziemlich komplexe Entscheidungsmatrix zu vereinfachen:
- Wie viel Datenverlust kann Ihr Anwendungsfall / Deployment verkraften?
- Wie wichtig ist die Leistung für Ihre Geschäftsziele?
- Wie viel Ausfallzeit kann Ihr Projekt verkraften?
In diesem Blogeintrag besprechen wir verschiedene Datenspeicheroptionen, die Sie verwenden können, jeweils mit Vor- und Nachteilen. Am Ende dieses Blogeintrags haben Sie ein besseres Verständnis davon, wie Sie den Datenspeicher Ihres eigenen (einzigartigen) Elasticsearch-Deployments größengerecht planen können.
Sie möchten sich darüber keine Gedanken machen? Dann habe ich gute Nachrichten für Sie: Wenn Sie den Elasticsearch Service in der Elastic Cloud verwenden, nehmen wir Ihnen die Größenplanung ab.
Optionen auf einen Blick
Hier finden Sie eine Kurzübersicht über die Optionen für die Planung Ihres Datenspeichers mit Elasticsearch, die wir in diesem Blogeintrag behandeln werden. Weiter unten gehen wir ausführlich auf die Vor- und Nachteile sowie die jeweiligen Eigenheiten in Bezug auf Datenverlust, Leistung und Ausfallzeiten ein.
| RAID 0 | RAID 1 | RAID 5 | RAID 6 | Mehrere Datenpfade | |
| Schutz der Daten | Kein Schutz | 1 Datenträgerausfall | 1 Datenträgerausfall | 2 Datenträgerausfälle | Kein Schutz |
| Leistung* | NX | X/2 | (N - 1)X | (N - 2)X | 1X bis NX |
| Kapazität | 100 % | 50 % | 67 % - 94 % | 50 % - 88 % | 100 % |
| Vorteile |
• Einfache Einrichtung • Hohe Leistung • Hohe Kapazität • Elasticsearch sieht nur 1 Datenträger |
• Guter Schutz der Daten • Einfache Wiederherstellung • Elasticsearch sieht nur 1 Datenträger |
• Mittlerer Schutz der Daten • Einfache Wiederherstellung • Mittlere bis hohe Kapazität • Mittlere bis hohe Leistungsgewinne • Elasticsearch sieht nur 1 Datenträger |
• Guter Schutz der Daten • Einfache Wiederherstellung • Mittlere bis hohe Kapazität • Mittlere bis hohe Leistungsgewinne • Elasticsearch sieht nur 1 Datenträger |
• Einfache Einrichtung • Datenträger hinzufügen • Hohe Kapazität |
| Nachteile |
• Keine Fehlertoleranz • Langsame Wiederherstellung • Ohne Replikat-Shards sind permanente Datenverluste möglich |
• Niedrige Kapazität • Keine Leistungsgewinne für Schreibvorgänge • Kann nur zwei Datenträger verwenden |
• Gewisser Kapazitätsverlust • Nur ein Datenträger kann ausfallen, bevor das Array ausfällt • Potenziell langsame Wiederherstellung • Datenverluste möglich, wenn mehr als ein Datenträger ausfällt • Reduzierte Array-Leistung während der Wiederherstellung |
• Kleiner bis mittelgroßer Kapazitätsverlust • Potenziell langsame Wiederherstellung • Reduzierte Array-Leistung während der Wiederherstellung |
• Kein Balancing der Shards zwischen verschiedenen Pfaden • Grenzwerte auf einzelnem Datenträger wirken sich auf gesamten Knoten aus • Leistung ist nicht einheitlich • Kein Hot-Swapping der Datenträger möglich • Beim Hinzufügen von Datenträgern kann Hot-Spotting auftreten |
Wenn Sie Ihre Datenträgerkapazität skalieren möchten, haben Sie verschiedene gute Optionen zur Auswahl. Wir werden uns nun einige dieser Optionen zusammen mit den Vor- und Nachteilen ansehen. Da jede Situation einzigartig ist, gibt es keine allgemein gültige Lösung.
RAID 0
RAID ist eine seit Jahrzehnten etablierte Lösung für kombinierte Datenträger. RAID hat drei Komponenten: Spiegelung, Striping und Parität. Jede Zahl in einer RAID-Konfiguration steht für eine eindeutige Kombination dieser drei Komponenten.
Die Zahl 0 steht für Striping in RAID. Beim Striping werden die Daten in Blöcke aufgeteilt und die Blöcke anschließend auf alle Datenträger im Volume geschrieben.
Leistung und Kapazität
Striping verbessert die Lese- und Schreibleistung, da alle Datenträger parallel arbeiten können. In der Praxis multipliziert diese Konfiguration Ihre Lese- und Schreibvorgänge mit der Anzahl der Datenträger pro Array. Mit sechs Datenträgern in einem RAID 0-Array erhalten Sie also etwa eine sechsfache Lese- und Schreibgeschwindigkeit.
Wiederherstellung
RAID 0 bietet keine Wiederherstellung, daher muss Elasticsearch die Wiederherstellung mit Snapshots oder Replikaten selbst übernehmen. Je nach Größe der Datenträger und dem verwendeten Transportmechanismus beim Kopieren der Daten in das Array kann dieser Vorgang sehr zeitraubend sein. Während der Wiederherstellung wird der Netzwerkdatenverkehr und die Leistung der anderen Knoten beeinträchtigt.
Nachteile
Elasticsearch-Indizes bestehen aus vielen Shards. Daher können Indizes mit Shards auf einem RAID 0-Volume beschädigt werden, wenn ein Datenträger ausfällt und keine anderen Replikate existieren. Dabei können permanente Datenverluste auftreten, wenn Sie Ihre Backups nicht per Snapshot-Lifecycle-Management (SLM) verwalten oder Elasticsearch mit Replikaten konfiguriert haben.
Vor- und Nachteile
| Vorteile (+) | Nachteile (-) |
|
|
RAID 1
Leistung und Kapazität
Die Zahl 1 steht für die Spiegelung in RAID-Konfigurationen. Bei der Spiegelung werden dieselben Daten auf mehrere Datenträger geschrieben. Dabei wird eine Kopie der Daten erstellt. Obwohl die Daten auf beide Datenträger geschrieben werden, lesen die meisten RAID-Implementierungen nicht von beiden Datenträgern. Daher wird die Lese- und Schreibleistung in der Praxis halbiert. Da dieselben Daten auf beide Datenträger geschrieben werden, verlieren Sie außerdem die Hälfte der Kapazität.
Wiederherstellung
RAID 1 besteht nur aus zwei Datenträgern. Wenn ein Datenträger ausfällt, sind die Daten also weiterhin auf dem anderen Datenträger vorhanden. Das Ergebnis ist eine hohe Datenredundanz auf Kosten von Leistung und Kapazität. Wenn ein Datenträger ausfällt, können Sie ihn einfach ersetzen, und die Daten werden auf den neuen Datenträger kopiert.
Nachteile
RAID 1 wird in den meisten Fällen mit RAID 0 kombiniert, da RAID 1 nur zwei Datenträger unterstützt. In diesem Fall kombinieren Sie also mehrere RAID 1-Volumes mit einem RAID 0 mit Striping. Diese Kombination heißt RAID 10 und wird verwendet, wenn vier oder mehr Datenträger vorhanden sind.
Auf diese Weise erhalten Sie einen Teil der Leistungsvorteile von RAID 0 zusammen mit der Redundanz von RAID 1. Die Leistung von RAID 10 hängt von der Anzahl der Datenträger im Array ab. RAID 10 hat die Leistung Nx/2.
Vor- und Nachteile
| Vorteile (+) | Nachteile (-) |
|
|
RAID 5, 6
Leistung und Kapazität
Die Parität wird in RAID mit verschiedenen Ziffern angegeben: 2, 3, 4, 5, 6. Wir besprechen die Versionen 5 und 6, da 2, 4 und 3 größtenteils durch andere RAID-Konfigurationen ersetzt werden. Parität ist ein Mechanismus, mit dem Daten, die durch einen Datenträgerausfall verloren gegangen sind, korrigiert oder berechnet werden. Die Parität schützt Ihre Daten in Kombination mit der Leistung von Striping. Die Wiederherstellbarkeit der Daten hat jedoch ihren Preis. RAID 5 verwendet einen kompletten Datenträger für die Parität, und RAID 6 verwendet zwei Datenträger.
Wiederherstellung
Bei RAID 5 und 6 muss außerdem die Rebuild-Dauer für die Wiederherstellung berücksichtigt werden. Ein Rebuild findet statt, wenn ein Datenträger im Array durch einen neuen Datenträger ersetzt wird. Im Fall von herkömmlichen HDD-Festplatten können Sie mehr Datenträger hinzufügen, anstatt die Datenträgerkapazität zu erhöhen. Zusätzliche Datenträger erhöhen die Lese- und Schreibleistung und verkürzen die Rebuild-Dauer. Im Fall von SSDs sollten Sie analysieren, ob die Datenträger mit höherer Kapazität auch eine bessere Lese- und Schreibleistung bieten. SSD-Datenträger mit höherer Kapazität bieten oft auch eine bessere Lese- und Schreibleistung. In diesem Fall können Sie die Lese- und Schreibleistung mit den Datenträgern mit höherer Kapazität verbessern. RAID 5 kann einen Datenträgerdefekt verkraften, bevor Daten im Array verloren gehen. RAID 6 kann zwei Datenträgerdefekte verkraften.
Nachteile
RAID 5 und 6 können zwar einen Datenträgerausfall verkraften, jedoch nicht ohne Konsequenzen. Mit RAID 5 sind Sie in der Praxis so anfällig wie mit RAID 0, bis ein neuer Datenträger hinzugefügt wird. Wenn ein weiterer Datenträger ausfällt, gehen sämtliche Daten im Array verloren und müssen von anderen Shards oder mit einem Snapshot wiederhergestellt werden. Aus diesem Grund wird stattdessen oft RAID 6 empfohlen, da mit dieser Konfiguration mehrere Datenträger praktisch gleichzeitig ausfallen können. Wie zu Anfang erwähnt, ist es wichtig, dass Sie die Toleranz Ihres Projekts bezüglich Leistung und Datenintegrität kennen, um diese beiden Punkte abwägen zu können.
Bei einem Datenträgerausfall wird außerdem die Leistung von RAID 5 und 6 stark beeinträchtigt, da das Array die Parität verwenden muss, um die von den Datenträgern gelesenen Daten neu zu berechnen.
Vor- und Nachteile
| Vorteile (+) | Nachteile (-) |
|
|
Mehrere Datenpfade in Elasticsearch (MDP)
Elasticsearch hat eine Einstellung mit dem Namen path.data, mit der Sie die Speicherorte für die Elasticsearch-Datendateien im Dateisystem konfigurieren können. Wenn Sie unter path.data eine Liste angeben, verwendet Elasticsearch mehrere Speicherorte für die Datendateien. Angenommen, Ihre Datei „elasticsearch.yml“ enthält den folgenden Eintrag:
path.data: [ /mnt/path1, /mnt/path2, /mnt/path3 ]
In diesem Fall schreibt Elasticsearch an mehrere Orte im Dateisystem. Jeder dieser Pfade kann sich auf einem separaten Datenträger befinden.
Die Benutzer können mehrere Datenpfade für Elasticsearch definieren, um mit mehreren Datenspeichern zu arbeiten.
Leistung und Kapazität
Elasticsearch teilt die Daten in Shards auf, und die Shards werden in den Datenpfad mit dem größten freien Speicherplatz geschrieben. Wenn eine Shard einen Großteil der Schreibvorgänge erhält, wird Ihre Leistung auf die Geschwindigkeit eines Datenpfads beschränkt. Wenn Sie Ihre Daten jedoch gleichmäßig auf mehrere Datenpfade verteilen, können Sie die Schreibgeschwindigkeit aller verwendeten Datenträger nutzen. Elasticsearch garantiert nicht, dass Schreibvorgänge auf mehrere Datenpfade verteilt werden. Daher schwankt die Leistung manchmal und ist nicht immer einheitlich.
MDP garantiert keine Spiegelung und keine Parität für die Daten. Sie können also die komplette Datenträgerkapazität für Ihre Daten nutzen, mit Ausnahme von Grenzwerten, die ich in den Vor- und Nachteilen genauer erklären werde. Um die volle Datenträgerkapazität nutzen zu können, brauchen Sie mindestens dieselbe Anzahl an Shards und Datenpfaden.
Wenn Sie einen neuen Datenpfad zu einem Knoten hinzufügen, der bereits Daten auf anderen Pfaden enthält, kann auf dem neuen Datenträger Hot-Spotting auftreten. Da Elasticsearch die Shards nicht gleichmäßig auf verschiedene Datenpfade verteilt, werden alle neuen Shards an den neuen Pfad gesendet, da dort der meiste freie Speicherplatz vorhanden ist. Elasticsearch übernimmt Änderungen an der Datei „elasticsearch.yml“ nur beim Hochfahren. Daher muss der komplette Knoten neu gestartet werden, wenn Sie einen Datenträger hinzufügen.
Wiederherstellung
Datenträger können und werden ausfallen. Wenn ein Speichergerät ausfällt, das zu Ihren Datenpfaden gehört, wird der Knoten in Gelb angezeigt und die Daten auf dem jeweiligen Gerät sind nicht mehr verfügbar. Elasticsearch kann jedoch weiterhin in diesen fehlerhaften Datenpfad schreiben, in dem IOExceptions ausgelöst werden. Um dies zu verhindern, ist es wichtig, dass Sie den problembehafteten Datenpfad wie folgt aus der Elasticsearch-Knotenkonfiguration entfernen:
- Deaktivieren Sie die Shard-Zuweisung.
- Fahren Sie den Knoten herunter.
- Entfernen Sie den fehlerhaften Datenpfad aus der Elasticsearch-Konfiguration.
- Starten Sie den Knoten neu.
- Aktivieren Sie die Shard-Zuweisung erneut.
Um permanente Datenverluste zu vermeiden, sollten Sie die Replikation in Elasticsearch aktivieren. Die Standardkonfiguration verwendet ein Replikat pro Shard.
Anschließend verteilt Elasticsearch die Shards von anderen Knoten gleichmäßig. Elasticsearch kann keine Shards zwischen Datenpfaden verteilen. Weitere Details finden Sie in der Auflistung der Nachteile. Wenn nicht genügend Kapazität für die gleichmäßige Verteilung im Cluster vorhanden ist, wird der Knoten weiterhin in Gelb angezeigt.
Achten Sie beim Ersetzen von Datenträgern darauf, die Einbindung des alten Datenträgers aufzuheben und alle LVM-Gruppen zu deaktivieren. Auf diese Weise wird garantiert, dass das Betriebssystem den neuen Datenträger ordnungsgemäß verarbeiten kann. Nachdem Sie den neuen Datenträger installiert haben, müssen Sie den Pfad wieder zur Elasticsearch-Einstellung path.data hinzufügen. Wenn Sie den fehlerhaften Datenträger ersetzt haben, verwendet Elasticsearch den neuen Pfad.
Nachteile
Wenn ein Gerät ausfällt, das zu mehreren Datenpfaden gehört, wird der Pfad bei der nächsten Shard-Zuweisung ignoriert. In nachfolgenden Runden wird der Pfad für Shard-Zuweisungen jedoch wieder als gültig betrachtet. Dabei können IOException-Fehler auftreten, wenn die oben beschriebenen Schritte nicht ausgeführt werden.
Elasticsearch verarbeitet Grenzwerte auf Basis des jeweiligen Knotens. Dieses Detail ist wichtig, denn wenn ein Datenpfad den hohen Grenzwert erreicht, gilt dies automatisch für den kompletten Knoten. Diese Regel gilt auch, wenn in anderen Datenpfaden genügend freier Speicherplatz vorhanden ist. Der Knoten, der den Grenzwert erreicht hat, akzeptiert in diesem Fall keine neuen Shards mehr und verschiebt Shards aktiv auf andere Knoten oder versetzt den Knoten in einen schreibgeschützten Zustand.
Angenommen, wir haben einen Knoten mit sechs Datenpfaden mit jeweils 500 GB und einer Gesamtkapazität von etwa drei TB. Es kann vorkommen, dass ein einziger Datenpfad eine Datenträgerauslastung von 90 % erreicht. In diesem Fall erreicht der gesamte Knoten den oberen Grenzwert, und der Knoten wird als schreibgeschützt markiert. Dies gilt auch dann, wenn die anderen Datenträger auf dem Knoten zu weniger als 50 % ausgelastet sind.
Elasticsearch garantiert keine gleichmäßige Verteilung der Shards innerhalb eines Knotens. Es erfolgt also kein Balancing der Shards zwischen mehreren Datenpfaden. Wenn ein Benutzer mehrere Datenpfade verwendet, platziert Elasticsearch die Shards also auf dem Datenträger, auf dem zum jeweiligen Zeitpunkt am meisten freier Speicherplatz verfügbar ist. Wenn eine Shard mehr Daten empfängt und vollläuft, gleicht Elasticsearch die Shards nicht aus. Dabei kann die E/A-Last ungleich verteilt werden, wenn Sie diese Regel nicht beachten. Wenn Sie einen neuen Datenträger zu einem Knoten hinzufügen, der bereits Daten in anderen Pfaden enthält, kann außerdem eine hohe E/A-Last auf dem neuen Pfad auftreten.
Vor- und Nachteile
| Vorteile (+) | Nachteile (-) |
|
|
Fazit
Wenn Sie den Punkt erreichen, an dem Sie Ihre Datenkapazität erweitern müssen, wird es spannend! Wir haben in diesem Blogeintrag verschiedene Optionen und Tools besprochen. Für die größengerechte Planung Ihres Datenspeichers gibt es jedoch keine Einheitslösung.
Falls Sie weitere Fragen oder Bedenken zur größengerechten Planung Ihres Elasticsearch-Deployments haben, finden Sie mich und eine stetig wachsende Community von hilfsbereiten Benutzern jederzeit in unseren Diskussionsforen.
Oder noch besser ... Für den Fall, dass Sie diese Punkte nicht selbst verwalten möchten, wiederhole ich meine guten Neuigkeiten von weiter oben: Die Elastic Cloud nimmt Ihnen diese Verwaltung ab. Für die Skalierung reicht es aus, einen zusätzlichen Knoten hinzuzufügen. Sie müssen nie wieder Server auspacken, in Racks montieren und verwalten. Außerdem unterstützt die Lösung (höchstwahrscheinlich) Ihre vorhandene Infrastruktur in Amazon Web Services, Google Cloud Platform oder Microsoft Azure. Testen Sie die Lösung noch heute kostenlos!