Upgrading Redundant Pairs
- Last UpdatedJun 23, 2022
- 4 minute read
You can reduce plant down time by upgrading the two partner nodes in a redundant pair, one at a time.
Platforms hosting redundant pairs may be deployed even when a partner platform is not the same software version as the Galaxy Repository (GR) platform, or is in the Software Upgrade Pending (SUP) state.
When upgrading a redundant pair, we recommend upgrading the standby partner first. This way, only one failover of the redundant engines is needed, thus minimizing the period of time in which process data is not collected. After upgrading the first node, upgrade the second as soon as possible. When only one node is upgraded, backup and failover are not available. Both nodes must be at the same software version to enable redundancy.
The following table illustrates the workflow for upgrading a Galaxy Repository and one redundant pair, consisting of different nodes, from software version 1 (v1) to version 2 (v2). Action items are shaded. In this example, the redundant pair is comprised of Node B and Node C, as a redundant Application Engine is hosted by the platform on each node. Use the Platform Manager to determine which platform (P1 or P2) is hosting the active Application Engine. See the Platform Manager User Guide for additional information.
To upgrade a redundant pair
Follow the actions listed in the table to upgrade a GR node and redundant pair. These instructions assume an initial state where the primary engine (E1) is active. At the conclusion of this procedure, all three nodes are upgraded and the backup engine (E1b) is active.
|
Node A Galaxy Repository (GR) |
Node B Primary AppEngine (E1) |
Node C Backup AppEngine (E1b) |
||||
|---|---|---|---|---|---|---|
|
Step |
Action |
Resulting State |
Action |
Resulting State |
Action |
Resulting State |
|
--- |
(Initial state) |
Deployed. |
E1 Deployed – Active. |
E1b Deployed – Standby. |
||
|
1 |
Upload run-time changes |
Changes made at run-time now stored in the database. |
||||
|
2 |
Upgrade (with AppServer deployed but shut down) |
All objects on P0 become undeployed. |
||||
|
3 |
Reboot when prompted |
Software is now at v2. |
||||
|
4 |
Open IDE and migrate database |
Galaxy database now at v2. IDE shows P1 and P2 in SUP state. |
||||
|
5 |
Optional: Open and migrate InTouch ViewApps |
InTouch ViewApps now at v2. |
||||
|
6 |
Cascade deploy P0 |
All objects on P0 are deployed. |
||||
|
7 |
Upgrade (with AppServer deployed but shut down) |
P2 and its hosted engines and objects become undeployed. |
||||
|
8 |
E1 becomes undeployed. E1 shows as undeployed, but objects under E1 show as deployed. |
Cascade Deploy P2 Note: This action results in a brief downtime for objects on E1 and E1b as E1 becomes undeployed (a few seconds to a few minutes, depending on number of objects). |
E1b becomes active; hosted objects are now running under v2. Note: E1b does NOT start from the check- pointed state of non- upgraded E1. |
|||
|
9 |
Upgrade (with AppServer deployed but shut down) |
P1 becomes undeployed. |
||||
|
10 |
Cascade deploy P1 |
E1 is deployed as part of P1 deployment. E1 starts as standby and fully syncs with active engine. |
No down- time for objects on E1b as E1b continues to run as active. |
|||
|
--- |
Final state |
Deployed. |
E1 Deployed – Standby. |
E1b Deployed – Active. |
||
After you have upgraded to System Platform 2023, you can enable CPU load balancing to improve the performance of redundant AppEngines during failover. See "Working with Redundancy" in the Application Server User Guide for additional information.
The following table describes the behaviors associated with specific upgrade actions and states.
|
Action or State |
Behavior |
|---|---|
|
Cascade deploy a Platform after upgrade |
If the upgraded platform hosts a backup redundant engine with a partner in the SUP state, then during the deploy operation, it will extract the hosted objects from the partner and deploy them along with the backup redundant engine. |
|
Deploy a redundant engine with a partner in the SUP state. |
The deploy operation is always a Cascade Deploy. |
|
Multi-selection for a cascade deployment includes a redundant engine with a partner in SUP state |
The cascade deploy operation skips the redundant engine in SUP state and logs a message. |
|
Select a backup redundant partner engine for deployment |
The backup redundant engine extracts the hosted objects from the primary redundant engine and deploys them along with the backup redundant engine. The hosted objects are under the primary redundant engine on a partner platform which is in SUP state. The hosted objects will be forced to deploy with the newer software version during the deployment of the backup redundant engine. A dialog displays with the option to continue deployment or to cancel. |
|
Partner engine is deployed but not reachable or not ready to sync. |
Redundant engine deployment fails. |
|
Partner engine has older software version. |
The partner engine is detected and recognized as having an older software version. It is automatically stopped and unregistered. Primary engine transitions into Active – Partner not Upgraded redundancy status. Primary and backup partners cannot sync, but references to a redundant engine with this status—or with Active or Active – Standby not Available redundancy statuses—will resolve. Application Objects can be deployed to a redundant partner with Active – Partner Not Upgraded redundancy status. You will not be able to deploy the partner engine until you have upgraded it. |