ZDU - Distributed Installation
To upgrade the Automation Engine without any downtime, you use the ZDU Upgrade Process. For this purpose, you have to set up a distributed installation. This serves to ensure that a base and a target version system are available for conducting the upgrade and that testing the proper running of tasks and jobs is possible in the target version.
Notes:
-
In the ZDU documentation, all references to base and target system also mean base and target version.
-
It is recommended to use a test environment for extensive testing before installing upgrades on your production system.
-
Two special modes exist for this upgrade function:
-
Compatibility mode
This mode is started as soon as you choose the option Run System Upgrade Wizard in the wizard's System Upgrade page. In this mode, which is in effect until you click the option Next in the final seventh step of the wizard, certain system optimization functions are not available. Also system performance will be reduced noticeably.
-
Parallel mode
A mode during the upgrade when base and target version processes are active at the same time.
-
-
The password fields used in versions prior to 12.1 are still in use to allow potential rollbacks, given the entered passwords comply with the password rules. If a password exceeds 20 characters or contains a comma, it is no longer compliant with the rules prior to 12.1. In this case, the password is saved in the new fields using AES encryption. The password(s) in the old field remain unchanged. Additionally, the Login object has to be locked for editing by old user interfaces This is done by updating the field OH_AEVersion to 12.1. In case of a rollback, all new passwords which are not compliant with the old rules are deleted and the field OH_AEVersion is reset to 11.2. This action causes that the login objects are unlocked and can be edited with an older user interface. Also, older WPs can access them for processing.
This page includes the following:
Overview
As base and target version CP/WP processes are active in the parallel mode, you have to set up two separate installations in separate bin directories, one instance of the version you want to upgrade from (base), another of the version you want to upgrade to (target). These may be to installation on the same host (recommended), or in separate hosts.
-
You can use either method with a Proxy.
-
The two alternatives can be realized using either two AE installations or an existing AE installation by duplicating or splitting it.
Important! You have to use the same INI file (ucsrv.ini) for base and target version, located in one directory only. When updating to this version, please check the new port definition for all types of server processes.
More information:
Split an Existing Installation
In most cases this will be the solution of choice.
- Use two separate bin directories.
- Split an existing installation:
- In this case you use already configured and known ports.
- You would shut down half the system, that is, shut down half the number of all existing WPs and CPs. After upgrading the shut down ones to the target version, you would start them again.
Advantage:
-
Less time needed for configuring ports, as no additional ports are necessary.
Disadvantages:
-
Shutting down CPs results in agents and users connected to those CPs being disconnected.
-
System performance will be reduced to half of its usual amount.
Distributed Installation
In rare cases, where the number of agents in a system are tens of thousands, this setup is advisable. In case of doubt consult CA Automic support.
- Set up two installations of the AE system you want to upgrade (base version).
- Use either the same host and set up two separate installations.
- Alternatively use two separate hosts and separate installations.
- You have to configure double the amount of ports than are usually necessary for the correct working of an AE system.
- These ports have to be known to any clients that are going to connect to a CP, therefore enter them either in the INI or the config file.
This is necessary, because at some point during the upgrade base and target version CPs have to be active in a parallel mode at the same time.
- These ports have to be known to any clients that are going to connect to a CP, therefore enter them either in the INI or the config file.
- You also have to create double the amount of MQ1CPnnn and MQ2CPnnnn in the database.
Advantages:
- Using this kind of setup lets users continue their work without being disconnected.
- Agents can be phased out successively and connect to the new CPs.
Disadvantages:
- Setting up the system this way requires a little more preparation time at first.
- Additional ports are necessary, which have to be configured in Firewall and existing Proxies.
- All ports have to be known by all existing clients before you start the upgrade.
You can execute the
The Proxy combines and reroutes CP connections, while agents just connect to the Proxy, using the ports or port ranges configured in it.
- You have to set up one of the environment variants explained above, use a distributed installation or split your existing environment.
- Configure the second system in the Proxy accordingly.
- The Proxy will then reroute connections to either the base or target version CPs, as necessary.
Advantages:
- You do not have to configure any additional ports, either in the distributed installation or the split system environment.
- The connections will be taken care of by the Proxy so that agents will be connected to whatever system and CPs are active and in use, be it base or target system.
See also: