Enabling 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 Configuring the Redundancy Message Channel .

For information about distributed networks, see Using 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" in the AVEVA Application Server Scripting Guide 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, set the Engine Failure Timeout option to 2000 milliseconds. You may need to tune this parameter between 2000 ms and the default 10000 ms, depending on the requirements of your application.

   When the Active engine fails during a failover, it restarts automatically and becomes the Standby engine.

   Note: The actual engine failure time-out is three times the value of this parameter. If you set the parameter to 2000 ms (2 seconds), a failover occurs if the AppEngine fails to communicate with the computer’s Bootstrap for 6 seconds. A setting of 10000 ms (10 seconds) can be too long a wait period (30 seconds) for a well-functioning redundancy operation.

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.