Migration von Alt-Daten aus Elastic 1.7

Mit dem Versionswechsel von service.monitor 4.3 auf 4.4+ wurde ein großer Versionssprung bei der in Analytics verwendeten Basistechnologie Elasticsearch vorgenommen. In der unten stehende Tabelle ist ersichtlich, dass Elastic von Version 1 auf Version 7 aktualisiert wurde.

Übersicht der Versionen

Übersicht service.monitor Versionen und Elasticsearch Versionen
service.monitor	Elasticsearch
`Version 4.3`	`Version 1 (1.7.x)`
`Version 4.4`	`Version 7 (7.6+)`
`Version 4.5`	`Version 7 (7.6+)`

Positiv an diesem Wechsel sind die vielen funktionalen Erweiterungen, eine bessere Performance, Stabilität und Wartbarkeit, als auch die Rückkehr in einen aktiv gepflegten Software-Zyklus seitens Elasticsearch. Auf der Gegenseite muss festgestellt werden, dass durch den großen Sprung Standard-Upgrade-Pfade im Elasticsearch Stack nicht zur Verfügung stehen und Bestandskunden für sich die Frage beantworten müssen, wie sie mit den vorliegenden Alt-Indizes umgehen. Dieser Artikel beschreibt daher einen einfach durchzuführenden Migrationsweg und gibt Tipps, wie der Betrieb des Elasticsearch Clusters möglichst nahtlos fortgesetzt werden kann.

Migration durch Reindexierung

Einfach ausgedrückt besteht die Lösung der Migrationsfrage im kurzzeitigen Betrieb von zwei Elasticsearch-Instanzen und der Migration der Alt-Indizes durch eine vom Neu-System angestoßene Reindexierung des Datenbestandes. Reindexierung bedeutet die Abfrage von Index-Daten (z.B. Nutzungsaktivitäten in map.apps) und die erneute Abspeicherung jedes einzelnen Ereignisses in einem neuen (anderen) Elasticsearch Index.

Ein idealtypischer Ablauf einer Aktualisierung von service.monitor (auf einem Host) würde so aussehen:

Installation des neuen Elasticsearch Clusters (Version 7.x)
Aktualisierung der monitor-analytics-Webapplikation
Aktualisierung der map.apps-Bundles für service.monitor Analytics
Stoppen des alten Elasticsearch Clusters (Version 1.7.x)
Inbetriebnahme des neuen Clusters (es werden bereits Ereignisse protokolliert)
Rekonfiguration und Neustart des alten Clusters (Portwechsel)
Durchführen der Reindexierung
Stoppen / Deinstallation des alten Elasticsearch Clusters

Individuell kann das beste Vorgehen von dem hier beschriebenen abweichen, ebenso wie die Werte für Ports und Indexnamen nur beispielhaft gewählt sind.

Inbetriebnahme des neuen Clusters

Im Zuge der Inbetriebnahme des neuen Clusters kann eine Konfigurationseinstellung gesetzt werden, die für die erfolgreiche Reindexierung wichtig ist. Dazu muss in der Datei elasticsearch.yml im conf-Ordner der Installation der Wert reindex.remote.whitelist hinzugefügt werden. Die zusätzliche Zeile sieht dann so aus und enthält eine Liste der Elasticsearch Cluster, die abgefragt können werden sollen. In diesem Fall, der alte Cluster in Version 1.7.x.

reindex.remote.whitelist: ["localhost:9201", "127.0.0.1:9201", "host.example.com:9201"]

Rekonfiguration des alten Clusters

Da die Reindexierung über das HTTP-Protokoll erfolgt und beide Cluster parallel betrieben werden, muss der alte Cluster umkonfiguriert werden, sodass dieser auf anderen Ports lauscht. Dies wird durch eine Anpassung der Datei <install>\conf\elasticsearch\elasticsearch-analytics.yml erreicht.

Ändern bzw. fügen Sie die folgenden beiden Werte der Konfiguration hinzu:

http.port: 9201
transport.tcp.port: 9400

Der Wert für http.port definiert den Port, über den Elastic per HTTP erreichbar ist. Der andere Wert dient der internen Kommunikation in einem Cluster. Wichtig ist auch hier, dass er sich vom Standardwert 9300 des neuen Clusters unterscheidet.

Durchführen der Reindexierung

Die Reindexierung wird am einfachsten mithilfe der Dev Tools aus Kibana erledigt. Öffnen Sie dazu Kibana und navigieren zu Management > Dev Tools. In der Console der Dev Tools können HTTP-Elasticsearch-API-Kommandos einfach abgesendet werden.

Durch das Absenden mehrerer Kommandos kann nun damit begonnen werden, die Indizes vom alten System zu lesen und in neue Ziel-Indizes zu schreiben. Im folgenden Beispiel werden alle Daten des alten Systems unter Port 9201 aus allen Indizes, die mit logstash-tool- beginnen, in einen neuen Index mit dem Namen analytics-usagelog-tool-old auf dem neuen System reindiziert.

POST _reindex?wait_for_completion=false
{
"source": {
"index": "logstash-tool-*",
"remote": {
"host": "http://localhost:9201"

    }

  },
  "dest":   {"index": "analytics-usagelog-tool-old"}
}

Der Aufruf des oben stehenden Kommandos liefert eine Task-ID zurück. Über die ID kann der aktuelle Status der Migration abgefragt werden:

GET _tasks/<ID>

Auf dem alten System kommen folgende Indizes/Index-Patterns für eine Migration in Betracht (abhängig von Ihrer indivduellen Betriebsweise):

Zuordnung der alten Indizes zu neuen Indizes (Vorschlag)
Alt-Index(pattern)	Neuer Index
`logstash-app-*`	`analytics-usagelog-app-old`
`logstash-map-*`	`analytics-usagelog-map-old`
`logstash-tool-*`	`analytics-usagelog-tool-old`
`logstash-server-*`	`analytics-usagelog-server-old`
`logstash-log-*`	`analytics-usagelog-log-old`
`logstash-other-*`	`analytics-usagelog-other-old`

Das oben dargestellte Kommando ist demnach abgewandelt mehrfach auszuführen. Für weitere Information ziehen Sie die Reindex API-Dokumentation zurate.

Das konkrete Mapping von alten in neue Indizes hängt sowohl von der Bestandsindexstruktur auf dem alten System als auch von der gewünschten Zielindexstruktur ab. Je nach Datenmenge kann eine Aufteilung auf mehrere Indizes sinnvoll sein. Ein Index sollte die Größe von 20 GB Festplattenplatz nicht überschreiten.

Stoppen / Deinstallation des alten Elasticsearch Clusters

Nach einer erfolgreichen Reindexierung kann der alte Cluster gestoppt und deinstalliert werden. Evtl. überführen Sie die Elasticsearch Indexdateien aus dem Dateisystem in eine langfristige Archivierung, sodass gegebenenfalls ein Backup des alten Datenbestandes wieder genutzt werden kann.

Wir unterstützen Sie gerne im Rahmen eines Consultings bei den Fragestellungen und bei der Durchführung der Migration. Bitte sprechen Sie uns an!