Wichtige Dinge, die Sie beim Upgrade von Elasticsearch 1.x auf 2.x wissen sollten

Übersicht

Im Betrieb einer Anwendung muss man oft Upgrades auf das neueste Release eines Produkts vornehmen: um Schritt zu halten mit neuen Funktionen und Fehlerbehebungen und um den Support zu gewährleisten. Mit Elasticsearch ist es nicht anders und mit dem Release von Version 2.0 wurden eine Reihe weitreichender Änderungen eingeführt, die eine vorhandene 1.x-Installation beim Upgrade beeinträchtigen können. Diese werden in der Dokumentation als Breaking changes bezeichnet. Bitte beachten Sie, dass ein Neustart des GESAMTEN Clusters erforderlich ist.

Sehen Sie sich unser Video zum Upgrade von Elasticsearch 1.x auf 2.x an.

Wie nehme ich nun ein sauberes Upgrade auf Elasticsearch 2.x vor?

Mit ein paar Tests außerhalb der Produktionsumgebung besteht nur eine geringe Wahrscheinlichkeit, dass ein Upgrade fehlschlägt oder Unstimmigkeiten in Ihren Daten verursacht. Dazu ist allerdings einiges an Planung notwendig – im Folgenden eine Zusammenfassung:

• Machen Sie sich mit der Liste der Breaking changes vertraut, die im neuen Release enthalten sind. So passieren keine Überraschungen der Art „Hey, was ist mit der Funktion passiert, die wir vorher benutzt haben?“.
• Setzen Sie den network.host auf eine _non_loopback Adresse in elasticsearch.yml. Bitte beachten Sie, dass es auch ein Interface sein könnte, das als „_[networkInterface]_“ konfiguriert ist, bspw. „_en0_“, „_ens160_“ oder „_eth0“.
• Laden Sie das Migrations-Plugin herunter und installieren Sie es auf Ihrem Cluster, bevor Sie ein Upgrade versuchen. Bitte beachten Sie, dass das Plugin die Mappings, Indexeinstellungen und Segmente nur prüft (d. h. nicht korrigiert) und danach markiert, was vor Beginn des Migrationsprozesses korrigiert werden muss. Da es nicht nach Index Templates sucht, müssen Sie immer noch die gesamte Dokumentation der Breaking changes lesen, bevor Sie erforderliche Änderungen manuell vornehmen.
• Benutzen Sie die Funktion Snapshot & Restore (ein MUSS), um eine Kopie aller Produktionsdaten in einer Testumgebung zu erzeugen, mit denen Sie alle Upgrade-Migrationstests durchführen können. Beschädigen Sie lieber diese, als Ihren Produktions-Cluster zu gefährden.
• Das Upgrade über Major versions hinweg (1.x auf 2.x) erfordert den vollständigen Neustart des Clusters.
• Für Nicht-Systemd-Installationen empfehlen wir die Verwendung des aktuellsten elasticsearch init-Skripts von 1.x auf 2.x (es gibt ziemlich viele Unterschiede):

        2.1 DEB init
        2.1 RPM init

• Nehmen Sie alle empfohlenen Modifikationen an Ihrer Cluster-Konfiguration und Ihrem Backend-/Frontend-Code vor, den Ihre Anwendung in diesem Zusammenhang nutzt, und berufen Sie sich dabei auf die Ergebnisse des Migrations-Plugins und dem Dokument zu Breaking changes.
• Konsultieren Sie alle Upgrade-Dokumentationen für Plugins für Elasticsearch, um sicherzustellen, dass diese zum aktuellsten Release kompatibel sind.
• Achten Sie darauf, dass sowohl Logstash als auch Kibana ein Upgrade auf eine unterstützte Version erhalten, um die volle Kompatibilität zu Elasticsearch 2.x zu gewährleisten.
• Beachten Sie, dass für ein Kibana-Upgrade auch ein Upgrade des Marvel-Plugins und des Agenten erforderlich ist, da die Benutzeroberfläche in Kibana integriert wurde.
• Sense ist jetzt Open Source und ebenfalls ein Plugin für Kibana statt für Marvel, muss also nach dem Upgrade manuell installiert werden.
• Logstash 2.x nutzt das HTTP-Protokoll jetzt standardmäßig und erfordert möglicherweise manuelle Änderungen in der Logstash-Konfiguration. Das Ausgabe-Plugin elasticsearch_java kann bei Bedarf installiert werden.
• Achten Sie darauf, den richtigen Upgrade-Pfadzu nutzen.
• Der Upgrade-Prozess für die Indizes kann überwacht werden. Sehen Sie sich dafür den API-Befehl ‚check upgrade status‘ an.

Mein Upgrade ist kaputt, Hilfe!

Wenn die Upgrade-Gremlins auftauchen und Ihr Leben aufmischen wollen, obwohl Sie die vorigen Schritte genau befolgt haben, können Sie es noch auf folgenden Wegen versuchen:

• Stellen Sie der Community im Diskussionsforum eine Frage. Sie werden positiv überrascht sein von der Hilfsbereitschaft unserer Nutzer-Community.
• Schreiben Sie einen Fehlerbericht auf GitHub, wenn Sie glauben, beim Upgrade-Prozess einen neuen Fehler entdeckt zu haben.
• Wenn Sie ein Kunde mit Subskription sind, können Sie im Support-Portal ein Ticket erstellen, damit ein Experte von Elastic Ihnen bei der Behebung von Upgrade-Problemen hilft.

Sie suchen nach Möglichkeiten, Ihre Ausfallzeit zu minimieren oder das Wartungszeitfenster für einen vollständigen Cluster-Neustart zu reduzieren?

Wenn Ihnen die Risiken zu groß oder der Upgrade-Berg zu gewaltig erscheinen, haben wir hier einige Optionen für Sie:

• Erstellen Sie einen neuen Cluster mit der neuen Version von Elasticsearch und den kompatiblen späteren Releases von Logstash, Kibana und anderen Plugins (falls erforderlich).
• Senden Sie Ihre Quellereignisdaten gleichzeitig an den alten und den neuen Cluster und schalten Sie den alten Cluster ab, sobald Ihre vorgeschriebene Speicherfrist abgelaufen ist. Diese Methode eignet sich besser für geringere Speicherfristen wie 7 Tage oder 1 Monat.
• Indexieren Sie Ihren gesamten Datensatz erneut von der Quelle zum neuen Cluster und schalten Sie danach den alten ab.

Obwohl diese Methode zu Beginn mehr physische (oder virtuelle) Ressourcen verbraucht (obwohl eine Testumgebung für diese Funktion vorübergehend zu geringfügig höheren Zusatzkapazitätskosten umgestaltet werden könnte), dauert diese Phase nur kurz an. Sobald der neue Cluster die Daten des alten hat und alle erforderlichen Funktionen für Ihre Frontend-Anwendung bereitstellen kann, ist der vollständige Wechsel vielleicht die einfachere Alternative.

Achtung: Jeglicher Code, der zum Senden oder Empfangen von Daten von Elasticsearch geschrieben wurde und auf Mappings oder veränderten Funktionen basiert (siehe Breaking changes), bedarf unabhängig vom gewählten Upgrade-Pfad immer noch manueller Modifikation.

Bekannte Probleme

Im Folgenden finden Sie eine Liste der Probleme, die bereits beobachtet wurden und die Sie bei Ihrer Upgrade-Planung berücksichtigen sollten sowie Fehlerbehebungsvorschläge für fehlgeschlagene oder unvollständige Upgrades:

• Keine Einstellung für network.host (oder falsche Einstellung). Bevor Sie Elasticsearch 2.x starten, müssen Sie sich vergewissern, dass Sie den network.host: _non_loopback in elasticsearch.yml einstellen.
• Das Migrations-Pluginist nur zur Elasticsearch-Version 1.x kompatibel und sollte (zusammen mit allen 1.x-Plugins) entfernt werden, sobald es bestätigt, dass vor dem Upgrade keine Änderungen erforderlich sind, d. h. vor dem eigentlichen Upgrade.
• Legen Sie ein Backup aller Konfigurationsdateien an, sodass diese im Rahmen eines Paket-Upgrades (DEB, RPM etc.) ersetzt werden können und Sie danach die neueren Konfigurationsdateien an Ihre benötigten Cluster-Einstellungen anpassen können.
• Prüfen Sie vor einem Upgrade-Versuch, ob ausreichend Laufwerksspeicher auf den jeweiligen Cluster-Nodes vorhanden ist. Dieses grundlegende Upgrade-Prinzip wird oft vernachlässigt.
• Möglicherweise nehmen Sie das Upgrade von einem sehr alten Relase vor (vor 0.90). Die Lucene-Version muss dabei zu Elasticsearch 2.x kompatibel sein. Konsultieren Sie also bitte die „upgrade API“-Dokumentation, um festzustellen, ob zuvor eine manuelle „upgrade API“-Anfrage durchgeführt werden muss.
• Plugins müssen auf dem neusten Stand gehalten werden, um die Kompatiblität zum neuesten Release von Elasticsearch zu gewährleisten. Wenn es eine neuere Plugin-Version gibt, die zur Elasticsearch 2.x-Version, auf die Sie upgraden wollen, kompatibel ist, müssen Sie das alte Plugin entfernen, das Upgrade vornehmen und danach das neuere Plugin installieren.Ähnlich verhält es sich mit einem Plugin-Ordner mit einem ungültigen Plugin: Dann startet Elasticsearch nämlich nicht.
• Der Marvel-Agent muss auf allen Nodes im Cluster installiert werden. Da das Marvel-Agenten-Plugin das Lizenz-Plugin benötigt, muss zuerst das Lizenz-Plugin auf allen Nodes installiert werden. Wenn Sie das nicht tun, kann es besonders bei der Nutzung des Java-Node-Clients zu Problemen kommen, wenn die .jar-Lizenzdatei nicht Teil des Projekts ist.
• Client-Nodes, auf denen der Marvel-Agent läuft, müssen aufgrund bekannter Probleme mit Version 2.0 mit diesem Node-Typ und der Marvel-Ausführung ein Upgrade auf mindestens Elasticsearch 2.1 erhalten.
• Sie werden keine Indizes mit sich widersprechenden Field-Mappings auf Elasticsearch 2.x upgraden können (diese Indizes starten dann vielleicht gar nicht mehr!). Das bereits erwähnte Migrations-Plugin sollte diese erkennen.
• Wenn Sie bei geschlossenen Indizies und einem Filter im Migrations-Plugin letzteres nicht erfolgreich ausführen können, sehen Sie sich diesen Workaround an.
• index_analyzer existiert nicht mehr und Vorlagen werden nicht vom Migrations-Plugin geprüft, daher kann es zu Exceptions kommen. Sie müssen die alten Vorlagen manuell aktualisieren, um dieses Problem zu umgehen.
• Stellen Sie sicher, dass Ihre Kernel-Version aktuell ist, da ältere Releases Probleme mit dem neueren fsync haben, das von Elasticsearch 2.x genutzt wird.
• Das Upgrade auf ein bedeutendes Release wie Elasticsearch 2.x funktioniert nicht, wenn einige Nodes mit älteren Releases verbleiben. Alle Nodes müssen im Rahmen der Neustart-Upgrade-Schritte ein Upgrade auf das neue Release erhalten.
• Ausführung inkompatibler Releases von Logstash und Kibana nach dem Upgrade auf Elasticsearch 2.x.