Container-Based System Upgrade - Automic Automation Kubernetes Edition

As a system administrator, you must meet the necessary requirements, check for incompatibilities between versions and go through a number of preparation steps before carrying out an upgrade.

You can also migrate an existing, manually installed Automic Automation system to a container-based system. This option is available for upgrades from version 12.3 and higher and for migrations from the same version (version 21.0).

As of version 24.3, it is also possible to perform a Zero Downtime Upgrade for AAKE instances. To do so, you need to explicitly set the ZDU option in the values.yaml file, see Zero Downtime Upgrade for AAKE.

Tip! This section contains information relevant for container-based systems. If you are searching for information relevant to manually upgrading your system, see Upgrading an Automation Engine System Manually.

This page includes the following:

Upgrade Overview 

Click the image to expand it.

Graphic depicting the container upgrade process

Analytics in the Upgrade Context

When migrating to an AAKE system, Analytics is never installed in the AAKE cluster. If you have Analytics installed in the version you want to upgrade, it remains on-premises.

For information on how to configure the connection between your Analytics on-premises installation and the Automic Automation Kubernetes Edition, see Configuring the Connection between Analytics On-Premises and AAKE.

Zero Downtime Upgrade for AAKE

You can also perform a Zero Downtime Upgrade for AAKE instances. To do so, you need to explicitly set the ZDU option in the values.yaml file as follows:

labels:
  features.aa-install-operator/upgrade-mode: zdu

In that case, the install operator handles the Helm upgrade without any downtime. AWI displays the message "System upgrade is in progress." while the ZDU Helm upgrade is in progress, thus signalizing all Users that a system upgrade is ongoing.

Upgrade Process

The Install Operator carries out the following steps:

  1. Upon starting the ZDU mode, the Install Operator spins up a set of pods for the target version in parallel to the base version so that the services can be redirected to the new, target pods.

  2. AWI is shut down in the base version, which means that Users must log in manually to the target version.

  3. The Agents are disconnected from the base version so that they can reconnect automatically to the target version.

    The Install Operator checks periodically if there are any Agents still connected to the base version. It checks every five seconds for the period of time defined in the timeoutCheckConnectionsSeconds parameter in the values.yaml file. After that, the Agents are disconnected from the base version.

  4. Once the period defined times out and the Agents connect to the new version, the Install Operator waits for the period defined in the timeoutDelConnectionsSeconds parameter of the values.yaml file to see if there are any Users connected to the base version. If that period times out and there are still connections to the base version, the upgrade process fails. In this case, you can manually check the connections.

  5. The Install Operator waits for executions still running on the base version to finish before finalizing ZDU and deleting the base version. To do so, it checks if there are any remaining entries in the MQMEM table of the base version for the period defined in the timeoutCheckExecutionsSecond parameter of the values.yaml file.

  6. Once the period defined times out, the Install Operator waits for the period defined in the timeoutCleanupExecutionsSeconds parameter of the values.yaml file for the remaining entries to be deleted from the table. If there are any entries left after the parameter times out, the upgrade process fails. In this case, you can manually check the MQMEM table.

  7. Once the upgrade process is done, the Install Operator waits for the period defined in the timeoutFinalizeSeconds parameter of the values.yaml file before finalizing the upgrade and deleting the base version.

    If this period times out and the ZDU cannot be finalized, the upgrade process fails.

To avoid the system upgrade failing due to a timeout, you can change the default values of the parameters relevant to the ZDU upgrade in the values.yaml file as needed :

  • timeoutCheckConnectionsSeconds: Defines how long the Install Operator should check if there are Agents still connected to the base version.

    Default value: 3000

  • timeoutDelConnectionsSeconds: Defines how long the Install Operator should wait for Agents to connect to the target version and for Users to be disconnected from the base version.

    Default value: 600

  • timeoutCheckExecutionsSecond: Defines how long the Install Operator should check if there are any remaining entries in the MQMEM table of the base version.

    Default value: 3000

  • timeoutCleanupExecutionsSeconds: Defines how long the Install Operator should wait for the remaining entries in the MQMEM table are deleted.

    Default value: 600

  • timeoutFinalizeSeconds: Defines how long the Install Operator should wait for the upgrade process to finalize before deleting the base version.

    Default value: 600

Upgrade Steps

  1. Preparing for the Container-Based System Upgrade

  2. Upgrading Container-Based Systems

See also: