Tach Zusammen!
Migration ist so ein tolles Wort. Es kommt mit einem eigenen Wiki-Eintrag:
https://de.wikipedia.org/wiki/Migration
Wir lernen also Migration heisst eigentlich nur Umzug auf Lateinisch aber selbstverständlich klingt das viel interessanter!
Tatsächlich gibt es ja nur einen interessanten Umzug:
https://de.wikipedia.org/wiki/Karnevalsumzug
Zumindest gibt es da Prinzen!
Besonders uninteressant finde ich die „die Wanderung von Schadstoffen im Grundwasserleiter“…wie gut, dass für uns lediglich die System-Migration wichtig ist.
Leider hat es diese Art der Migration noch nicht in das deutsche Wiki geschafft:
https://en.wikipedia.org/wiki/System_migration
Also ein Umzug jenseits von Köln und Düsseldorf!
Innerhalb der Orion
Plattform bekommen wir es eigentlich nur mit zwei Arten der Migration zu tun – die der Datenbank und/oder des Anwendungsservers.
Mehr generelle Info hier:
https://support.solarwinds.com/Success_Center/Network_Performance_Monitor_(NPM)/Migration_Guide
In meinem Beispiel möchte ich die DB von 2014 auf 2016 umziehen!
Der Hauptgrund dafür befindet sich…*trommelwirbel*…hier:
https://thwack.solarwinds.com/docs/DOC-176988#start=25
Tatsächlich ist das ein Szenario dem man sogar schon direkt nach Abschluss einer Evaluierung begegnen kann, wenn man vielleicht von der Express Version auf eine volle DB wechseln möchte ohne Daten zu verlieren.
Meine Situation:
1 VM mit den Anwendungen
1 VM mit der aktuellen Datenbank auf Version 2014SP2
1 VM mit der neuen Datenbank auf Version 2016SP1
Die offizielle Dokumentation in English befindet sich hier:
https://support.solarwinds.com/Success_Center/Orion_Platform/Migrate_the_SolarWinds_Orion_SQL_database_to_a_new_server
Da mein System läuft, muss ich es erst anhalten.
Dadurch entsteht natürlich ein Loch im Monitoring was ich aber ignorieren kann – ihr solltet das planen!
Ich gehe zu meiner VM und starte den Kollegen hier:
Okay jetzt stellt bitte sicher, dass ihr entweder
a) ausserhalb der Geschäftszeiten im Buero sitzt
-oder-
b) schon einen neuen Arbeitsvertrag irgendwo anders unterschrieben habt
Wenn a oder b zutreffen, klickt auf „Shutdown Everything“.
Keine Sorge, mit „everything“ ist nur SolarWinds gemeint und nicht der Rest der Welt!
Nach ein paar Sekunden ist alles Rot:
Tipp: Vergewissert euch, dass überall „stopped“ und nicht „stopping“ steht.
Dann auf zum nächsten Schritt. Kaffee? Noch nicht!
Wir müssen die DB Dateien verschieben.
Öffnet SQL Management Studio und findet die DB:
Rechtsklick darauf, Tasks und Backup
Merkt euch den Standardpfad oder ändert ihn und klickt auf OK
Schnappt euch die Datei und schiebt sie auf ein Netzwerkshare oder gleich direkt in das Dateisystem auf die neue Maschine.
Im SQL Management Studio ebenfalls wechseln:
Database --> Restore
Ich habe die .bak auf C: liegen:
Alles gut:
Jetzt müssen wir dem System noch mitteilen, dass die DB umgezogen ist. Migriert meine ich natürlich, migriert!
Also gehen wir auf den Anwendungsserver und starten den Configuration Wizard und wählen die Database aus:
Jetzt aber aufgepasst!
Hier kommt der aktuelle Zustand:
So soll es aussehen nach dem Einpflegen der neuen Daten – wir brauchen temporär ein Konto mit mehr Berechtigungen um einen neuen Benutzer anlegen zu können:
Die DB wurde gefunden! Ein Meilenstein!
Nun schnell noch das Konto erstellen:
Jetzt ist es Zeit für einen Kaffee. Viel Kaffee:
Wir haben unseren Job gemacht und müssen warten:
Und schliesslich:
Die Webseite startet:
Und ein kurzer Test zeigt, dass per „add default“ der neue SQL angesprochen wird:
Das war es! Jetzt kann die alte DB weg.
Es gibt dazu übrigens auch ein tolles Wort mit Wiki-Eintrag: Decommissioning.
https://en.wikipedia.org/wiki/Decommissioning
In Deutsch ganz einfach: Stilllegung. Mit drei L.
Und um das Thema auch noch kurz anzusprechen – wenn ich jetzt auch den Anwendungsserver migrieren möchte, vielleicht um von einem 2008 auf ein 2016 zu kommen folge ich in etwa diesen Schritten:
Ich installiere erst die Orion Plattform mit meinen Modulen auf der neuen VM – ganz einfach als Evaluierungsversion ohne vorherige Eingabe von Lizenzschlüsseln.
Durch den Configuration Wizard lasse ich mir irgendwo temporär eine DB anlegen die ich aber nie benutze.
Sobald das neue System steht, deaktiviere ich die Lizenzen auf dem alten System mittels License Manager. Diese stehen mir dann auf dem neuen System wieder zur Verfügung.
Sobald die Plattform wieder lizensiert ist, nutze ich den Configuration Wizard noch einmal und verweise auf die schon bestehende, echte, SQL hin.
Es gibt ein paar Stolperfallen – so werden z.B. Berichte die irgendwann mal mit der alten Win32 Anwendung erstellt worden sind nicht automatisch gesichert und wenn die neue VM eine andere IP oder gar einen anderen Hostnamen hat muss dies per Hand in der DB angepasst werden.
Aber das will ich heute ja alles gar nicht machen.
Meine Datenbankmigration ist geglückt, ich werde das Wort Migration auf der nächsten Party benutzen um schrecklich intellektuell zu erscheinen, und ausserdem scheint gerade die Sonne!
BRB, muss meine Sonnenbrille suchen!