V12 FAQ: The Centralized Agent Upgrade

Finally, the big day has come: A new article in my blog.

Believe me, I was looking forward to this day at least as much as you were!

But let’s get to the topic.

If you have been to a single Automic event since last October, you have already heard of the Centralized Agent Upgrade and maybe even seen a demo.

If you have not seen a demo, then I recommend this short video from Automic:

Automic Software – Centralized Agent Upgrade

Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen
Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren

This video demonstrates how you can use the CAU, so I will not explain this to you in this article. Instead, I give answers to the most important questions that the video leaves open.

This works best in form of an FAQ:

No.

This feature is new in V12 and only works from v12 onward. So you will have to manually upgrade your agents to V12.

Please note: In addition, you also need to update the Service Manager to V12!

Anyone with: Access to client 0000 and the privilege Execute system upgrades.

You can find new agent versions by searching for “Centralized Agent Update” in the Automic Marketplace.

Important: The objects must be imported to client 0000 to be available for CAU.

You use the PluginManager in the AWI for that. You can find it in the menu point Packs in the Administration perspective.

If you do not see this menu item there, you may first have to install the PluginManager in your AWI. You can also find it in the Automic Marketplace.

Nope. Only Upgrades / Downgrades of existing agents are possible.

No, absolutely not.

First, the agent has to be stopped during the upgrade. As this takes only a few seconds. we could let it pass as “Almost Zero-Downtime”.

But that’s not all. As soon as you start the upgrade process, the agent enters Suspend Mode. In this mode, the agent remains active while tasks are still running on it, but does not take any new tasks. New tasks remain in sthe status Waiting for Host. By the way, since V12, this also affects SCRI objects that want to execute certain script functions (e.g., GET_FILESYSTEM) on agents.

This means that as long as processes are active on the agent, the agent is not available for new processes – this is definitely a downtime from a business perspective. And it can take a very long time if there is a long-running task active on the agent.

So choose wisely when to start a CAU for an agent!

You can always start one.

But it will only be executed once the agent is active. And when running tasks on the agent, then it may take a long time – see the answer to the question “Is the CAU a Zero Downtime Upgrade?”

No, you can create a CAU for inactive agents. The CAU runs automatically the next time the agent starts.

You can find the answer to this question under “Is the CAU a Zero Downtime Upgrade?”

Yes, fortunately!

It can happen: You start a CAU and overlook a long-running job on the agent. Or a job turns out to be long-running only at this unsuitable moment. The agent is in Suspend mode, and no new jobs start.

In that kind of situation, to return the agent to normal operation you must disconnect the agent from the system in the administration perspective. The agent will automatically reconnect to the system and is then in normal mode.

Yes and no.

The procedure goes as follows: First, the agent is placed in Suspend Mode, where it no longer assumes new tasks.

Once all running tasks are completed, the agent replaces its files with the new version.

The agent then terminates itself with the return code 248.

There is no ServiceManager involved in all previous steps. The only thing that matters is that if the agent decides to use return code 248, the ServiceManager will immediately restart it.

However, this could also be done by any other start script / program.

Ha, I’ve been waiting for you to ask this question.

The answer is quite cool: With a CAU, the AE memorizes in the database, which target version the agent has.

If the agent is started with a different version, it is automatically updated / downgraded by the AE via CAU to the target version. In the upgrade history you can see this as REPAIR.

This may also be relevant for agents running on clusters. You first run the CAU on the agent on one cluster node. If the cluster switches and the agent on other nodes with the same name but a different version comes up, it is automatically updated to the correct version.

They are not overwritten, the original files are retained.

This also means that new INI file parameters, which may be introduced in a new agent version, are not being rolled out by the CAU.

They are automatically deleted after the upgrade.

Sure!

The script function MODIFY_SYSTEM has a new parameter named DEPLOY.

Details and examples can be found as usual in the Automic Documentation.

Yep!

There are two new keys in UC_HOSTCHAR_DEFAULT:
EXECUTE_ON_DEPLOYMENT_RUN and EXECUTE _ON_DEPLOYMENT_AGENT.

In addition, there are some new variables that will be passed to the notifications.

For details, refer to the Automic Documentation.

You could certainly convince me with a nice comment to also create such FAQs for other interesting features.

Von |2022-06-30T13:07:31+02:0024. März 2017|Kategorien: AutomicBlog|Kommentare deaktiviert für V12 FAQ: The Centralized Agent Upgrade

Share This Story!

FacebookTwitterLinkedInE-Mail

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:

Automic Software – Centralized Agent Upgrade

Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen
Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren

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:

Nein.

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!

Jeder mit: Zugriff auf Mandant 0000 und dem Privileg Systemaktualisierungen durchführen.

Neue Agentenversionen finden Sie, indem Sie im Automic Marketplace nach “Centralized Agent Update” suchen.

Wichtig: Die Objekte müssen auf Mandant 0000 importiert werden, damit sie für CAU zur Verfügung stehen.

Dafür benutzen Sie den PluginManager im AWI. Sie finden ihn im Menüpunkt Packs in der Perspektive Administration.

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.

Nope. Nur Upgrades / Downgrades bestehender Agenten sind möglich.

Nein, bei Weitem nicht.

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!

Sie können jederzeit eines starten.

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?”

Nein, Sie können ein CAU auch für inaktive Agenten anstoßen. Das CAU wird dann automatisch ausgeführt, wenn der Agent das nächste Mal startet.

Die Antwort hierauf verbirgt sich hinter der Frage “Ist das CAU ein Zero Downtime Upgrade?”

Ja, zum Glück!

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.

Jein.

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.

Ha, ich habe schon darauf gewartet, dass Sie diese Frage stellen.

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.

Diese werden nicht überschrieben, die ursprünglichen Dateien bleiben erhalten.

Das bedeutet auch, dass neue INI-Datei-Parameter, die eventuell in einer neuen Agentenversion eingeführt werden, durch das CAU nicht ausgerollt werden.

Sie werden nach dem Upgrade automatisch gelöscht.

Sicher!

Die Scriptfunktion MODIFY_SYSTEM kennt einen neuen Parameter DEPLOY.

Details und Beispiele finden Sie wie gewohnt in der Automic Hilfe.

Yep!

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.

Sie könnten mich bestimmt durch einen netten Kommentar davon überzeugen, solche FAQs für weitere interessante Features zu erstellen.

Von |2017-03-24T11:57:23+01:0024. März 2017|Kategorien: AutomicBlog|Kommentare deaktiviert für V12 FAQ: Das Centralized Agent Upgrade

Share This Story!

FacebookTwitterLinkedInE-Mail

Titel

Heute noch Automic lernen.

Erweitere dein Automic Know-how mit Kursen, Tutorials und Tools aus der Praxis!

Direkt buchen

Natürlich hast du auch die Möglichkeit, PEM für zwei Wochen kostenlos und unverbindlich zu testen.

Newsletter

  • Dieses Feld dient zur Validierung und sollte nicht verändert werden.
Nach oben