Patch redundant AppEngines

This section describes the workflow for patching a Galaxy Repository (GR) and one redundant pair of AppEngines (E1 and E1b).

• The GR is installed on platform P0.

• The redundant AppEngines are installed on primary platform P1 (active AppEngine E1) and backup platform P2 (standby AppEngine E1b).

• For simplicity, this procedure assumes that each platform has only one engine.

Patch the GR first, the backup platform next, and finally the primary platform.

Initial state

• The GR (Platform P0) is unpatched and deployed.

• AppEngine E1 (Platform P1) is unpatched and deployed as the active engine.

• AppEngine E1b (Platform P2) is unpatched and deployed as the standby engine.

Patch the GR (P0)

1. If necessary, upload runtime changes to the GR (P0). This stores any changes made during runtime in the database.

   Caution! If any configured default values, such as set points, were modified at runtime, uploading runtime changes will overwrite the default values.

2. Apply the patch to the GR node (P0). Shut down P0 and its engine when prompted.

   The GR and engines on P0 remain deployed, but are shut down.

3. Reboot when prompted.

   The galaxy database is now patched to the new version and P0 engines are running off-scan.

4. Open the IDE and connect to the galaxy.

5. Cascade deploy P0. This deploys all objects on P0 and clears the software-upgrade-pending state from the objects.

Patch the Backup Platform (P2)

Note: When you shut down the backup platform (P2), alarm information may stop being sent to all clients on all nodes. (This is uncommon, but may happen.) The primary logger will show a message similar to:
Warning ITAlarmProvider UpdateAlarm - Received message 8 with no alarm name for alarm provider.

If this happens, just continue the patching process. When the backup platform has been patched and redeployed, alarm information will again be sent to all clients.

6. Apply the patch to the backup platform (P2). Shut down P2 and AppEngine E1b when prompted.

   P2 and standby AppEngine E1b remain deployed, but are shut down.

7. Reboot when prompted.

   AppEngine E1b is now patched to the new version and running off-scan.

8. Cascade deploy P2.

   Deploying P2 results in a brief downtime for objects on AppEngines E1 and E1b as E1 becomes undeployed (a few seconds to a few minutes, depending on the number of objects).

   Once P2 is deployed, E1b becomes active and its objects are running on-scan. E1 is now the standby engine. However, objects will show as deployed under AppEngine E1, since the objects are now running on its redundant partner, AppEngine E1b.

   Note: E1b does NOT start from the checkpointed state of unpatched E1.

Patch the Primary Platform (P1)

9. Apply the patch to the primary platform (P1). Shut down P1 and AppEngine E1 when prompted.

   P1 and its engines remain deployed, but are shut down.

10. Reboot when prompted.

    AppEngine E1 is now patched to the new version and is running off-scan.

11. Cascade deploy P1.

    AppEngine E1 is deployed as part of the P1 deployment. It starts as the standby engine and fully syncs with active engine E1b.

    There is no downtime for objects on E1b since it continues to run as the active engine.

Final State

• The GR (Platform P0) is patched and deployed.

• AppEngine E1 (Platform P1) is patched and deployed as the standby engine. Before patching, E1 was deployed as the active engine.

• AppEngine E1b (Platform P2) is patched and deployed as the active engine. Before patching, E1b was deployed as the standby engine.