Enable AppEngine redundancy

You enable AppEngine redundancy in the Primary AppEngine. You must also configure two WinPlatforms for redundancy, one to host the Primary AppEngine and one to host the Backup AppEngine.

Important: WinPlatforms hosting redundancy-enabled AppEngines must be deployed to computers running the same operating system.

The configuration of both WinPlatforms should be the same. At a minimum, the store-forward directory configurations must be common to both WinPlatforms:

During configuration, you can assign Primary and Backup AppEngines to the same WinPlatform. To deploy, you must assign the Primary and Backup AppEngines to different WinPlatforms.

Each production computer hosting a redundancy-enabled AppEngine must have a minimum of two network cards. One NIC is for the supervisory network and PLC network, if the computer has only two network cards. The other must be for a dedicated Ethernet connection between computers for the redundancy message channel (RMC). The RMC handles redundancy monitoring, message handling and data synchronization between redundant pairs. For more information about the RMC, see Configure the redundancy message channel .

For information about distributed networks, see Multiple network interface cards.

You configure redundancy in AppEngine/WinPlatforms objects using their Object Editors.

The redundancy-related parameters in the AppEngine Object Editor are located on the Redundancy and General tabs.

An AppEngine that is part of a redundancy pair has a deployment status indicating its own status and that of its partner object. These statuses are visually indicated in the Application views.

You can set the status of a redundancy pair to one of the following states:

To create AppEngine redundancy

1. On the Redundancy tab, for the Primary AppEngine, select the Enable Redundancy check box.

2. On the same tab, select the Enable Warm Redundancy check box to improve failover performance.

   • When Warm Redundancy is enabled, failover from the active to standby engine occurs much faster than when it is disabled. Warm redundancy starts up and initializes the Standby engine concurrently with the Active engine. DI client objects subscribe to both the Active and Standby engines, even though the Standby engine is running offscan until failover occurs. The standby engine transitions to onscan at failover without requiring the DI Objects to restart and subscribe, thus greatly reducing the time needed for the standby engine to become active. This checkbox will be checked by default for new redundant pairs (Warm Redundancy enabled).

     Note: The behavior of redundant engines that use Startup or Undeploy scripts may differ between Warm Redundancy and Legacy Redundancy. For existing redundant engines that use Startup or Undeploy scripts, test engine behavior before enabling Warm Redundancy in the production environment. See Script execution types for additional information.

   • When Warm Redundancy is disabled (legacy behavior) the Standby engine does not perform start up and initialization until failover occurs, and DI objects subscribe to only the Active engine. After initialization, the engine then transitions to onscan and becomes active, and DI Objects must restart and subscribe to the now-active (formerly standby) engine. The additional time needed for start up, initialization, and subscription increases the time needed for failover to complete. This checkbox will be unchecked for migrated redundant pairs (legacy behavior; Warm Redundancy is disabled).

   Default redundancy behavior:

   • New Redundant Pairs: Run Warm is enabled by default.

   • Redundant Pairs migrated from System Platform 2020 R2 or prior release: Run Warm is disabled by default (uses legacy behavior).

3. Configure the remaining redundancy parameters as needed. See the help file for the AppEngine for specific information about these parameters.

4. On the General tab, the default Engine Failure Timeout option is 30000 milliseconds (30 seconds). You may need to tune this parameter, depending on the requirements of your application.

   The standby engine is in a passive state while the active partner is up and running. The standby engine monitors the health of the active engine and waits to become active. It will assume the role of the active engine after the engine failure timeout period, if a failover occurs.

After you save the configuration of the object and check it into the Galaxy, the icon for the object changes. A Backup AppEngine is created with the same configuration as the Primary object.