Nachdem es aus aktuellem Anlass in den letzten Artikeln um Ereignisse ging, habe ich mir für heute endlich wieder ein technisches Thema vorgenommen: Ich führe an einem Testsystem das V12 Zero Downtime Upgrades (ZDU) durch und berichte von meinen Erfahrungen.
Eine Anleitung zur Durchführung finden Sie in der Automic Dokumentation. Die Online-Hilfe ist manchmal etwas langsam, verwenden Sie dann einfach die Dokumentation im heruntergeladenen Paket.
Automic empfiehlt, alle Upgrades per ZDU durchzuführen. Ich warne Sie aber schon im Voraus: Das ZDU stellt etwas mehr Aufwand als ein konventionelles Upgrade dar. Dafür kommt es zu keiner Applikationsdowntime.
Wissenswertes zum Zero Downtime Upgrade
Es gibt zwei unterschiedliche Modi, die während des ZDU aktiv sind:
- Compatibility Mode:
Vom Start des Upgrades bis zum Abschluss aktiv. Die Performance des Systems ist dabei merkbar reduziert (ca. um 1/3 reduziert, das System behält ca. 2/3 der Leistungsfähigkeit). - Parallel Mode:
Gegen Ende des ZDU aktiv. In diesem Modus laufen WPs der alten und neuen Version parallel.
Für die Durchführung des ZDU beschreibt Automic mehrere mögliche Vorgehensweisen.
- Halbierung des bestehenden Systems:
Das bestehende System wird halbiert, für die deaktivierte Hälfte wird das Upgrade durchgeführt, danach folgt die zweite Hälfte. - Verteilte Installation:
Die bestehende Installation wird verdoppelt. Das erfordert deutlich mehr Vorbereitung, da beispielsweise die Anzahl der Ports verdoppelt werden muss, was neue Firewallfreischaltungen notwendig machen kann. - Verwendung des Automic Proxies:
Das ist die stressfreie Variante, denn man kann die Connections auf den Proxys bündeln.
Ich habe für meinen Test die Methode „Halbierte Umgebung“ ausgewählt, um eine sehr frühe V12 auf die neueste V12 upzugraden. Ich habe also kein Versionsupgrade durchgeführt, sondern nur einen Hotfix eingespielt.
Vorbereitung des Zero Downtime Upgrades
1. Download der gewünschten Ziel-Version von downloads.automic.com
2. Upgrade des AWI auf die neueste Version
Natürlich erstelle ich zuerst ein Backup der alten Version. Auf ein Upgrade des Tomcat Application Servers verzichte ich, da meine Version 7.0.70 noch kompatibel ist. Die Kompatibilität von Komponenten können Sie mit dem Automic Compatibility Checker testen.
3. Upgrade der Utilities
Zuerst erstelle ich ein Backup von Utility/bin und Utility/db, danach installiere ich die neuen Utilities ins Verzeichnis bin.
Dann müssen die Konfigurationsdateien angepasst werden. Weil ich nur einen Hotfix installiere, kopiere ich die Konfigurationsdateien der alten Utilities.
Zum Abschluss kopiere ich noch das Verzeichnis db.
4. Parallele Installation der AE der Zielversion
Ich habe die Methode „Halbierte Umgebung“ gewählt, deshalb muss ich als nächstes die neue Version parallel zur alten installieren. Ich installiere sie in den Ordner bin_target, für das Upgrade eines echten Systems sollten Sie sich natürlich mehr Gedanken um die Benennung machen.
Die Datei ucsrv.ini kopiere ich von der alten Version, sodass sie identisch für alle Prozesse ist. Vergessen Sie dabei nicht, den entsprechenden JDBC Treiber für den JWP ins Unterverzeichnis lib zu kopieren!
5. Einem User auf Mandant 0000 das Privileg „Systemaktuallisierungen durchführen“ zuweisen
6. Datenbank sichern
Das können Sie gegebenenfalls auch später machen, am besten unmittelbar vor dem Laden der Initialdaten.
Es wird spannend: Das Upgrade geht los
Ich schildere hier Schritt für Schritt mein Vorgehen beim Upgrade. Die Nummerierung meiner Schritte entspricht nicht der Nummerierung im AWI.
1. Login als User mit passender Berechtigung auf Mandant 0000
2. Assistenten starten
Dafür wählen Sie in der Perspektive Administration „Automation Engine Verwaltung“, dann „Systemaktualisierung“ und klicken schließlich auf „Assistenten zur Systemaktualisierung starten“.
Das System wechselt jetzt in den Compatibility Mode!
3. Neue Initialdaten laden
Als nächstes lade ich die neuen Initialdaten mittels DB Load Utility. Es ist ein seltsames Gefühlt, den DB-Load von Initialdaten auf ein laufendes System durchzuführen.
Aber alles funktioniert tadellos, nur die Laufzeit ist auffällig lang. Auf meinem sehr kleinen Spielsystem dauert es mehr als 1,5 Stunden, da mein System aber auf schwacher Hardware läuft, ist der Wert sicher nicht repräsentativ.
4. Initialdaten prüfen
Als nächsten Schritt gibt das AWI die Prüfung der Initialdaten und den Start der Prozesse auf der Target-Version vor.
5. Prozesse umstellen
Mit meiner Methode „Halbierte Umgebung“ muss ich zunächst die Hälfte der Prozesse stoppen und im Servicemanager so umstellen, dass sie vom Verzeichnis mit den neuen Binaries (der Target Version) gestartet werden.
Danach starte ich die Prozesse mit den neuen Binaries über den Servicemanager.
6. Upgrade des AWI
Der Wizard testet an dieser Stelle, ob die Prozesse der Ziel-Version laufen. Außerdem fordert er dazu auf, das AWI upzugraden. Ich habe das schon in der Vorbereitungsphase erledigt.
7. Parallelmodus wird aktiviert
Das System läuft ab jetzt im Parallelmodus.
Hier bemerke ich einen interessanten Fehler im AWI: Die Meldungen über den Verbindungslisten sind auf Mandant 0 noch nicht lokalisiert, deshalb werden in meiner deutschen AWI Session nur die Meldungsnummern angezeigt.
8. Agenten wiederverbinden
Alle Agenten müssen zu einem CP mit der neuen Version verbunden sein. Mit meinem unkritischen Spiel-System klicke ich bedenkenlos auf „Alle Agenten wiederverbinden“.
9. Zu aktualisierende Plugins
Der Wizard zeigt jetzt eine Liste mit allen Plugins, die aktualisiert werden sollen. Ich muss nur die verwendeten AWI Plugins updaten.
Für das Analytics Backend und den Datastore ist kein Upgrade nötig, denn mittels md5sum stelle ich fest, dass die neuen Analytics Dateien identisch zu denen in meinem System sind.
10. Update des AWI Plugins
Ich verwende in meinem System die AWI Plugins „Analytics“ (für das AWI Dashboard), „Actions Builder“ (zum Bauen von Actions) und „Plugin Manager“ (zur Verwaltung von Packs).
Diese Plugins habe ich beim Update des AWIs nicht installiert, deshalb muss ich es jetzt machen. Die passenden Versionen sind im heruntergeladenen Paket:
- Das Analytics Plugin im Ordner Automation.Platform\Analytics\ui-plugin
- Den ActionBuilder im Ordner Tools\Action.Builder
- Den Plugin Manager im Ordner Tools\Plugin.Manager
Ich kopiere die Plugins (je ein JAR File) ins Tomcat-Unterverzeichnis webapps\awi\WEB-INF\autoinstall.
In die Datei plugin.properties (im Verzeichnis webapps\awi\config\webui-plugin-analytics) muss ich noch das API Key eintragen – und damit die Verbindung zum Analytics Backend funktioniert, muss ich danach Tomcat restarten!
Mit meinem Spiel-System ist das kein Problem. Auf einem größeren Produktivsystem können Sie den Restart vermeiden, indem Sie die plugin.properties im JAR-File mit dem Analytics Plugin vorher anpassen.
Nach dem Restart von Tomcat funktionieren die Analytics Dashboards wie erwartet.
11. Weitere Aktualisierungen
Bei diesem Hotfix muss ich sonst nichts aktualisieren, bei einem richtigen Update kommen noch weitere Punkte hinzu, zum Beispiel diverse Actionpacks.
12. Memory Einträge in der DB löschen, die auf alte Version zeigen
Der Wizard zeigt jetzt eine Liste mit Speichereinträgen an, die noch auf die alte Version zeigen. Bei mir sind das zum Glück keine.
Weder der Wizard, noch die Dokumentation sagen, was genau man mit Speichereinträgen machen soll, die noch auf die alte Version zeigen. Ich gehe nicht davon aus, dass man sie einfach löschen kann.
Ich empfehle Ihnen, den Support zu kontaktieren, wenn Sie hier nach ein paar Tagen noch Einträge sehen.
13. Agenten mittels CAU upgraden
Ich verzichte auf diesen Schritt. Das Central Agents Upgrade werde ich mir zu einem anderen Zeitpunkt genau ansehen. Jetzt klicke ich stattdessen auf „weiter“.
Das ZDU ist damit abgeschlossen.
Bei diesem letzten Schritt wurden im Hintergrund alle Prozesse mit der alten Version gestoppt. Ich muss deshalb die anderen Prozesse in meinem Servicemanager auf das Verzeichnis umstellen, in dem die neue Version liegt, und starten.
Upgrade des Servicemanagers
Der Servicemanager wurde noch nicht aktualisiert. Das kann man im Zuge des ZDU machen, indem man die Prozesse der Zielversion mit einer neuen separaten Installation des Servicemanagers startet. Sie sollten Ihren Servicemanager in zwei Fällen upgraden:
- Probleme in Ihrer Version des Servicemanagers wurden in der neuen Version behoben.
- Sie führen ein echtes Upgrade durch (nicht nur einen Hotfix).
Fazit zum Zero Downtime Upgrade
Grundsätzlich finde ich das ZDU echt eine Spitzen-Funktion! Systemupdate ohne Downtime – echt genial!
Auch die Umsetzung in Form dieses Wizards gefällt mir sehr gut! Er ist einfach zu bedienen und versucht sicherzustellen, dass man nichts vergisst.
Nehmen Sie das ZDU wegen des einfachen Wizards aber nicht auf die leichte Schulter! Erinnern Sie sich, was ich am Anfang geschrieben habe: Das ZDU ist mindestens genauso viel Aufwand wie ein herkömmliches Upgrade – nur eben mit anderem Ablauf.
An einigen Stellen sehe ich noch Platz für Verbesserungen:
- Die Übersetzung des Wizards ist noch nicht vollständig.
- Tomcat muss nach der manuellen Neuinstallation des Analytics UI Plugins neu gestartet werden.
- Die Dokumentation des ZDU geht überhaupt nicht auf die Verwendung des Servicemanagers ein, obwohl die meisten Kunden ihn verwenden.
- Es wird nicht geklärt, was in Schritt 12 (im Wizard: Schritt 6) mit den Memory Einträgen in der DB gemacht werden soll.
Mein Spiel-System lief auf einer Box, ohne Last, ohne User und mit 4 Agenten. Dieses System konnte ich problemlos upgraden, das ist aber bei Weitem kein Vorbild für ein echtes System-Upgrade! Auch die von mir genannten Erfahrungen und Verbesserungsvorschläge stellen keinen Anspruch auf Vollständigkeit!
Haben Sie schon ein ZDU durchgeführt? Wie sind Ihre Erfahrungen?