KBI 311334 Automatic Upgrade Facility For Argent Daughter Engines, Argent Motors And Argent Trusted Agents


Version

Argent Advanced Technology – All Versions

Date

Monday, 4 January 2016

Summary

Argent’s flexible architecture handles the smallest to the largest of networks – from 10 servers to over 25,000 servers

The following is a brief summary, for more information, review the Argent Architecture Guide at

https://help.argent.com/#e_arch

Architecture

  • Centralized Monitoring – Single Main Engine with all Argent AT components installed, monitoring machines remotely

    The “scheduler” and “monitoring” Engine is all done by the single Main Engine

  • Agent-Optional Monitoring – Single Main Engine with “Trusted Agents” deployed strategically on remote machines to perform monitoring against remote sites

    The “scheduler” is still handled by the single Main Engine, while there are one or more “Monitoring” Engines

  • Mother-Daughter Architecture – The Main Engine, now known as the “Mother”, replicates the scheduling and control information to “Daughter” Engines

    Daughter Engines schedule tasks locally and periodically returns monitoring data to the Mother Engine

  • Argent Non-Stop Monitoring – A pool of load-balanced Mother or Daughter Engine servers all sharing the same ODBC back-end database

    This architecture provides ultimate load-balancing, failover and scalability

Nomenclature:

  • Main Engine – The single central server that runs the Argent Console and Argent Supervising Engine services, and communicates directly with the back-end database
  • Trusted Agent – A remote monitoring Engine
  • Mother Engine – The alias for the “Main Engine” in Mother-Daughter Architecture; listens for connections from Daughter Engines
  • Daughter Engine – A regional scheduling and Monitoring Engine rolled into one; periodically contacts the Mother Engine to provide updates
  • Motor Engine – The name given to a Mother Engine that is part of a Non-Stop Monitoring pool

One challenge with a large distributed environment is performing Argent upgrades

Argent assists by providing a single central and automated upgrade facility

While this automates the upgrade of Argent products, care should be exercised when updating any production environment from any vendor

This KBI explains how Argent automates the upgrade process, and the planning that should be conducted prior to starting the upgrade

Technical Background

The Argent automatic upgrade facility covers the following typical installations:

  • Single Main Engine only
  • Single Main Engine with one or more Trusted Agents
  • Single Main Engine with one or more Daughter Engine
  • Single Main Engine with one or more Daughter Engines AND one or more Trusted Agents
  • Multiple Motor Engines (Argent Non-Stop Monitor) with/without Daughter Engines and Trusted Agents

In all of the above, the geographic location of the various Argent facilities is irrelevant; these machines could all be located in a single datacenter, or distributed through 50 countries

To upgrade an Argent AT installation, simply terminal into the Main Engine, or one of the central Motor Engine, and run SETUP.EXE in the installation package

After the setup program completes, the local installation is upgraded

In the case of Argent Non-Stop Motors, the setup program upgrades the local installation as well as all accessible Motor Engines

Afterwards, the next time any remote component such as Trusted Agents or Daughter Engines communicates with the Main Engine, a version conflict will be detected, which will trigger the auto-upgrade process for the Remote Engine

There are two exceptions:

  • Some Motor Engines may be offline during the upgrade

    If SETUP.EXE cannot access the Motor Engine installation folder, no upgrade can be done

    As a result, the Motor Engine will shut down immediately when it comes back online because it detects a version conflict with other upgraded Motor Engines

  • Daughter Engines or Trusted Agent services cannot start for various reasons

    If the Remote Engine is not running, it won’t be able to initiate the auto-upgrade process

In both cases, run SETUP.EXE locally at the Remote Engine to complete the upgrade

Auto-Upgrade: Behind The Scenes

When a version conflict is detected by the Remote Engine, the Remote Engine retrieves the list of all the required executables and DLLs from the Main Engine

It loops through the list, comparing the file Timestamp and Checksum

If the file is changed, it will be downloaded from the Main Engine

All updated files are saved in the cache folder $UPGRADE

If the process is disrupted for any reason, the Engine will resume from where it left off

After all changed files are downloaded, the Engine starts an external process ‘AT_UPGRADE.EXE’ which shuts down the service, replaces the changed files, and restarts the service

This completes the auto-upgrade

Resolution

N/A