Endlich, der große Tag ist gekommen: Ein neuer Blogartikel in meinem Blog.
Glauben Sie mir, ich habe mich auf diesen Tag mindestens genauso gefreut wie Sie!
Wenn Sie seit letztem Oktober auch nur auf einer einzigen Automic-Veranstaltung waren, dann haben Sie auch schon vom Centralized Agent Upgrade gehört und vielleicht sogar schon eine Demo gesehen.
Wenn Sie noch keine Demo gesehen haben, dann empfehle ich Ihnen dieses kurze Video von Automic:
In diesem Video erfahren Sie, wie Sie das CAU anwenden können, das werde ich Ihnen in diesem Artikel deshalb nicht mehr erklären. Stattdessen gebe ich Antworten auf die wichtigsten Fragen, die das Video offen lässt.
Am besten geht das natürlich in Form eines FAQs:
Das Feature ist in V12 neu dazugekommen und funktioniert erst ab V12 aufwärts. Sie müssen Ihre Agenten also erstmal auf dem herkömmlichen Weg auf V12 bringen.
Wichtig: Zusätzlich müssen Sie auch den ServiceManager auf V12 updaten!
Wichtig: Die Objekte müssen auf Mandant 0000 importiert werden, damit sie für CAU zur Verfügung stehen.
Wenn Sie diesen Menüpunkt dort nicht sehen, dann müssen Sie den PluginManager in Ihrem AWI eventuell erst installieren. Sie finden diesen ebenfalls im Automic Marketplace.
Geschenkt, dass der Agent während des Upgrade kurz gestoppt werden muss – das dauert nur wenige Sekunden und man könnte es als „Almost-Zero-Downtime“ durchgehen lassen.
Aber sobald man den Upgrade-Prozess startet, wechselt der Agent in einen Suspend Modus. In diesem Modus bleibt der Agent aktiv, solange noch Aufgaben auf ihm laufen, nimmt aber keine neuen Aufgaben an. Neue Aufgaben bleiben im Status Warte auf Host. Übrigens: Seit V12 betrifft das auch SCRI Objekte, die bestimmte Scriptsprachmittel (z.B. GET_FILESYSTEM) auf Agenten ausführen wollen.
Solange also Prozesse auf dem Agent aktiv sind, ist der Agent für neue Prozesse nicht verfügbar – das ist definitiv eine Downtime aus Business-Sicht. Und die kann sehr lange dauern, wenn auf dem Agent gerade ein Langläufer aktiv ist.
Achten Sie also sehr genau darauf, wann Sie ein CAU auf einem Agenten anstoßen!
Ausgeführt wird es aber nur, wenn der Agent aktiv ist. Und wenn auf dem Agent Aufgaben laufen, dann kann es auch lange dauern – siehe dazu die Antwort auf die Frage „Ist das CAU ein Zero Downtime Upgrade?“
Denn es kann ja mal passieren: Sie starten ein CAU und übersehen dabei einen Langläufer auf dem Agenten. Oder ein Job entpuppt sich erst in diesem ungeeigneten Moment als Langläufer. Der Agent ist im Suspend-Modus, und keine neuen Jobs starten.
Wenn Sie in einer solchen Situation den Agent wieder in den Normalbetrieb zurückholen wollen, dann müssen Sie den Agenten nur in der Perspektive Administration vom System disconnecten. Der Agent wird sich automatisch wieder mit dem System verbinden und ist dann im Normalmodus.
Es läuft folgendermaßen ab: Zuerst wird der Agent in den Suspend-Modus gesetzt, wo er keine neuen Aufgaben mehr annimmt.
Sobald alle laufenden Aufgaben beendet sind, ersetzt der Agent seine Dateien durch die der neuen Version.
Danach beendet sich der Agent selbst mit dem Returncode 248.
Für alle bisherigen Schritte braucht es keinen ServiceManager. Der macht nur eine einzige Sache: Wenn sich der Agent selbst mit Returncode 248 verabschiedet, wird er vom ServiceManager sofort wieder gestartet.
Das könnte aber auch jedes andere Start-Script/Programm erledigen.
Die Antwort darauf ist ziemlich cool: Bei einem CAU merkt sich die AE in der Datenbank, welche Zielversion der Agent hat.
Kommt der Agent mit einer anderen Version hoch, dann wird er von der AE mittels CAU automatisch auf die Zielversion up/downgegradet. In der Upgrade History sieht man das dann als REPAIR.
Relevant ist das eventuell auch bei Agents, die auf Clustern laufen. Sie führen das CAU zunächst auf dem Agenten auf einer Clusternode aus. Wenn dann der Cluster switcht und der Agent der anderen Nodes mit dem selben Namen aber einer anderen Version daherkommt, wird er von AE kurzerhand automatisch auf die richtige Version gehoben.
Das bedeutet auch, dass neue INI-Datei-Parameter, die eventuell in einer neuen Agentenversion eingeführt werden, durch das CAU nicht ausgerollt werden.
Die Scriptfunktion MODIFY_SYSTEM kennt einen neuen Parameter DEPLOY.
Details und Beispiele finden Sie wie gewohnt in der Automic Hilfe.
Es gibt in UC_HOSTCHAR_DEFAULT zwei neue Keys, EXECUTE_ON_DEPLOYMENT_RUN and EXECUTE _ON_DEPLOYMENT_AGENT.
Damit einhergehend gibt es auch einige neue Variablen, die den Notifications übergeben werden.
Details dazu finden Sie in der Automic Hilfe.