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 simpel durchzuführenden Migrationsweg und gibt Tipps, wie der Betrieb des Elasticsearch Clusters möglich 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 Neu-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 Index-Namen 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, so dass dieser aut anderen Ports lauscht. Dies wird durch eine Anpassung der Datei <install>\conf\elasticsearch\elasticsearch-analytics.yml erreicht.

Ändern bzw. fügen Sie die 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 mit Hilfe 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 mehrere 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):

Mapping alte zu neuen Indexen (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 abgwandelt mehrfach auszuführen. Die Reindex API ist hier . genauer dokumentiert.

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 Indexe 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 File-System in eine langfristige Archivierung, so dass 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!