Nick Price Übersetzung
Ich arbeite derzeit an einem großen Protokollierungsprojekt, das ursprünglich mit AWS Elasticsearch implementiert wurde. Nachdem ich mehrere Jahre mit großen Backbone-Clustern von Elasticsearch gearbeitet habe, bin ich von der Qualität der AWS-Implementierung völlig überwältigt und kann nicht verstehen, warum sie nicht behoben oder zumindest verbessert wurden.
Zusammenfassung
Elasticsearch speichert Daten in verschiedenen Indizes, die Sie explizit erstellen oder die nach dem Senden der Daten automatisch erstellt werden können. Einträge in jedem Index sind in eine bestimmte Anzahl von Shards unterteilt, die dann zwischen den Knoten in Ihrem Cluster ausgeglichen werden (so gleichmäßig wie möglich, wenn die Anzahl Ihrer Shards nicht gleichmäßig durch die Anzahl der Knoten geteilt wird). In ElasticSearch gibt es zwei Haupttypen von Shards: Basis-Shards und Replikat-Shards. Replikatshards bieten Fehlertoleranz bei einem Knotenausfall, und Benutzer können die Anzahl der Replikatshards für jeden Index separat festlegen.
Die Arbeit von Standard Elasticsearch
Elasticsearch - Es ist elastisch. Manchmal kann es ziemlich schwierig sein, aber im Allgemeinen können Sie dem Cluster Knoten hinzufügen oder diese löschen. Wenn beim Löschen eines Knotens eine geeignete Anzahl von Replikaten vorhanden ist, verteilt Elasticsearch Shards und verteilt sogar die Last auf den Knoten im Cluster. Dies funktioniert normalerweise.
Das Erfüllen teurer Abfragen kann manchmal zum Ausfall von Knoten und dergleichen führen, aber eine große Anzahl von Einstellungen hilft, die Arbeit aufrechtzuerhalten. Wenn bei einer ausreichenden Anzahl von Replikatsplittern der Knoten ausfällt, wirkt sich dies nicht auf die gesamte Arbeit aus.
Standard Elasticsearch bietet auch eine Reihe von Add-Ons, darunter das X-Pack, Überwachungsfunktionen, detaillierte ACLs, Überwachung und Warnungen. Der größte Teil des X-Packs wurde kürzlich kostenlos, wahrscheinlich als Reaktion auf die neue Splunk-Lizenzrichtlinie.
Amazon Elasticsearch Arbeit
Wie üblich nahm Amazon den Open-Source-Code für einen Teil von Elasticsearch, machte eine harte Gabel und begann, ihn als eigenen Dienst zu verkaufen, und führte schrittweise seine eigenen Versionen von Funktionen ein, die seit vielen Jahren auf die eine oder andere Weise in der Hauptversion von Elasticsearch verfügbar sind.
Dem Amazon-Produkt fehlen viele Dinge, wie zum Beispiel: RBAC und Audit, was für uns besonders problematisch ist, da wir Protokolle von verschiedenen Teams akzeptieren und diese voneinander trennen möchten. Derzeit verfügt jeder Benutzer, der Zugriff auf Elasticsearch hat, über alle Zugriffsrechte und kann versehentlich die Daten anderer Personen löschen, die Art und Weise ändern, in der sie auf den Knoten repliziert werden, und den Datenempfang durch Hinzufügen der falschen Indizierungsvorlage vollständig beenden.
Das ist frustrierend, aber nicht das größte Problem mit dem Service. Das Neuausgleichen von Shards - das zentrale Konzept von Elasticsearch - funktioniert in der AWS-Implementierung nicht, wodurch fast alles Gute in Elasticsearch negiert wird.
Wenn Daten zu Knoten hinzugefügt werden, kann normalerweise mehr als die anderen gefüllt werden. Dies wird erwartet, da nicht garantiert werden kann, dass die geladenen Datensätze dieselbe Größe haben oder dass die Anzahl der Shards immer gleichmäßig auf alle Knoten des Clusters verteilt ist. Dies ist nicht kritisch, da Elasticsearch Shards zwischen Knoten neu ausgleichen kann. Wenn ein Knoten wirklich voll ist, empfangen andere Knoten gerne Daten, anstatt sie zu füllen.
Dies wird von Amazon nicht unterstützt. Einige Knoten füllen sich möglicherweise (viel) schneller als andere.
Wenn in Amazon ein Knoten in Ihrem Elasticsearch-Cluster nicht über genügend freien Speicherplatz verfügt, empfängt der gesamte Cluster keine Daten mehr und wird vollständig gestoppt. Die Lösung von Amazon besteht darin, den Benutzern den Albtraum zu bereiten, die Anzahl der Shards in ihren Indizierungsvorlagen regelmäßig zu ändern und zuvor erstellte Daten in neue Indizes zu indizieren, vorherige Indizes zu löschen und gegebenenfalls die Indizierung der Daten in die vorherige Struktur rückgängig zu machen. Dies ist vollständig redundant und erfordert zusätzlich zu den hohen Rechenkosten, dass eine unverarbeitete Kopie der heruntergeladenen Daten zusammen mit dem analysierten Datensatz gespeichert wird, da für die erneute Indizierung eine unverarbeitete Kopie erforderlich ist. Dies verdoppelt natürlich den Speicherbedarf für „normale“ Arbeiten an AWS.
„Ups! Ich habe den gesamten Cluster nicht oft genug neu indiziert und der Knoten war voll! Was zu tun ist?"
Sie haben zwei Möglichkeiten. Löschen Sie zunächst so viele Daten wie nötig, um den Cluster wieder zum Leben zu erwecken, und beginnen Sie dann mit der Neuindizierung in der Hoffnung, dass nichts auseinander fällt. Haben Sie eine Sicherungskopie dessen, was Sie löschen möchten?
Die zweite Option besteht darin, dem Cluster weitere Knoten hinzuzufügen oder vorhandene auf eine größere Instanzgröße zu ändern.
Aber warten Sie, wie füge ich Knoten hinzu oder nehme Änderungen vor, wenn Shards nicht neu ausgeglichen werden können?
Die Lösung von Amazon ist eine blaugrüne Bereitstellung. Sie drehen einen ganz neuen Cluster hoch, kopieren den gesamten Inhalt des vorherigen Clusters in einen neuen und wechseln dann den alten Cluster und zerstören ihn.
Solche Größenänderungsaufgaben können Tage dauern. Bei großen Clustern kann das Duplizieren mehrerer Billionen Datensätze einige Zeit in Anspruch nehmen. Dies führt auch zu einer verrückten Belastung des vorhandenen Clusters (die wahrscheinlich bereits die Kapazität überschreitet) und kann tatsächlich zum Ausfall des Clusters führen. Ich habe mehrere ähnliche Vorgänge an mehr als 30 Clustern in AWS ausgeführt und nur einmal einen erfolgreichen Abschluss im automatischen Modus festgestellt.
Sie haben also versucht, die Größe Ihres Clusters zu ändern, und die Aufgabe wurde nicht abgeschlossen. Was jetzt?
Amazon-Interaktionen
Ihre Aufgabe, die Größe des Clusters zu ändern, wurde unterbrochen (für den Dienst, für den Sie sich wahrscheinlich entschieden haben, einen solchen Artikel nicht zu behandeln), sodass Sie das Ticket für den technischen Support von AWS mit der höchsten Priorität öffnen. Natürlich beschweren sie sich über die Menge oder Größe Ihres Shards und fügen freundlicherweise einen Link zu den "Best Practices" hinzu, die Sie bereits 500 Mal gelesen haben. Und dann warten Sie, bis es behoben ist. Und warte. Und warte. Als ich das letzte Mal versuchte, die Größe des Clusters zu ändern, und er blockiert wurde, was zu schwerwiegenden Fehlfunktionen führte, dauerte es SIEBEN TAGE, bis alles online war. Sie haben den Cluster selbst in ein paar Tagen wiederhergestellt, aber als alles gestoppt wurde, ist es offensichtlich, dass die Knoten, auf denen Kibana ausgeführt wird, den Kontakt zum Hauptcluster verloren haben. Der AWS-Support verbrachte weitere vier Tage damit, etwas zu reparieren, während er sich fragte, ob Kibana funktioniert. Sie wussten nicht einmal, ob sie das Problem behoben hatten, und ich musste überprüfen, ob sie die Kommunikation zwischen ihren eigenen Systemen wiederhergestellt hatten. Seitdem habe ich aufgehört, etwas anderes zu tun als Daten zu löschen, wenn der Knoten voll ist.
Die Kosten unserer Organisation für AWS sind enorm. Dies gibt uns die Möglichkeit, uns regelmäßig mit Experten auf verschiedenen Gebieten zu treffen, Implementierungsstrategien zu diskutieren und verschiedene technische Probleme zu lösen. Wir haben einen Termin mit einem Vertreter von Elasticsearch vereinbart, bei dem ich den größten Teil des Meetings damit verbracht habe, die Grundlagen von Elasticsearch zu erklären und ... die Macken ... ihres Produkts zu beschreiben. Der Experte war völlig geschockt, dass alles zusammenbricht, wenn der Knoten voll ist. Wenn der gesendete Experte die Grundlagen seines Produkts nicht kennt, ist es nicht verwunderlich, dass das Support-Team sieben Tage benötigt, um den Produktionscluster wieder aufzunehmen.
Endlich Gedanken
In dem Protokollierungsprojekt, in das ich mich vertieft habe, gibt es einen Teil der Architekturfehler und schwachen Entwurfsentscheidungen, an denen wir derzeit arbeiten. Und natürlich habe ich erwartet, dass sich AWS Elasticsearch vom Originalprodukt unterscheidet. In AWS Elasticsearch sind jedoch so viele grundlegende Funktionen deaktiviert oder fehlen, dass dies fast alle Probleme verschärft, auf die wir stoßen.
Für die einfache Verwendung und kleine Cluster funktioniert AWS Elasticsearch recht gut, aber für Cluster mit Petabyte-Größe war es ein endloser Albtraum.
Ich bin sehr gespannt, warum die Elasticsearch-Implementierung von Amazon keine Shards ausgleichen kann. Dies ist eine grundlegende Elasticsearch-Funktionalität. Selbst mit Einschränkungen im Vergleich zur Haupt-Elasticsearch wäre es sicherlich ein akzeptables Produkt für große Cluster, wenn es nur richtig funktionieren würde. Ich kann nicht verstehen, warum Amazon etwas so Defektes anbietet und warum sie die Situation seit mehr als zwei Jahren nicht mehr behoben haben.
Wie andere vorgeschlagen haben und es vernünftig erscheint, ist dieses Verhalten ein Zeichen für die AWS-Implementierung, die als riesiger Cluster mit mehreren Mandanten konzipiert wurde und versucht, Isolation bereitzustellen, damit sie für Endbenutzer wie ein eigenständiger Cluster aussieht. Selbst bei Optionen wie verschlüsselten Daten in Ruhe und verschlüsselter Datenübertragung erscheint dies plausibel. Oder vielleicht sind ihre Werkzeuge und Konfigurationen einfach ein Erbe einer viel früheren Architektur.
Und wie mein Freund bemerkte, ist es ziemlich lustig, dass sie es immer noch als "flexibel" bezeichnen, wenn Sie keine Knoten zu Ihren Clustern hinzufügen oder daraus entfernen können, ohne einen neuen zu starten und alle Ihre Daten zu übertragen.
Fußnote: Als ich diesen Text schrieb, fand ich vor zwei Jahren einen Beitrag mit vielen ähnlichen Behauptungen:
read.acloud.guru/things-you-should-know-before-using-awss-elasticsearch-service-7cd70c9afb4f