Redundant system requirements

In a system configured for redundancy, a redundant AppEngine pair consists of one primary and one backup AppEngine. The redundant pair is configured in the AppEngine editor. The AppEngine enabled for redundancy is considered the primary engine of the redundant pair.

When the primary engine is configured for redundancy, a backup engine is automatically created on a separate platform.

Use the Operations Control Management Console, Object Viewer, or the IDE to work with the redundant engine pair. The IDE provides visualization of the redundant pair in the Deployment view pane.

The following figure shows a pair of platforms, each configured with three redundant AppEngines. Note the AppEngine icons and names. The name (Backup) is appended to the redundant AppEngine that was created automatically from the primary AppEngine.

Redundant Engine configuration requires the following:

• Redundant pair AppEngines must be deployed to different platforms.

• Both nodes hosting the redundant AppEngine pair should run the same version and service pack levels of supported operating systems.

• The Redundancy Message Channel (RMC) of each platform must be configured by assigning the corresponding IP address in the platform editor.

Best Practice

Platforms hosting primary and backup AppEngines must have identical configurations for the following elements:

• Software providing or getting data from/to the ApplicationObject Server, such as SuiteLink, DDE, OPC Servers.

• Store and Forward directories

• Common user-defined attributes

• Common scripting

• Warm redundancy setting

  Note: For more information on attributes and scripting, see Templates.

Changing the default platform and AppEngine settings depends on the size of the system, the number of I/O points, and other variables.

Detailed information on tuning the Platform and Engine settings is included in Support Article 22407: Fine-Tuning AppEngine Redundancy Settings.

AppEngine Redundancy States

The deployment sequence (Cascade, Primary First, or Backup First) of the AppEngine pair determines which AppEngine takes the Active State.

When AppEngines are deployed individually, the first engine deployed takes the Active state while the second engine deployed takes the Standby state. The engines maintain their states until a failure occurs or there is forced failover event.

Beginning with System Platform version 2020 R2 SP1, AppEngines include an option for enabling warm redundancy. This option is located on the Redundancy page of the AppEngine object. Enabling warm redundancy is recommended. There are, however, some cases in which you should not enable warm redundancy. For existing redundant engines that use startup scripts, test before enabling warm redundancy to ensure that the scripts work without impacting system behavior and performance.

• When warm redundancy is enabled, the Standby engine is initialized and started at the same time as the Active engine. The Standby engine runs offscan, while the Active engine runs onscan. This allows much quicker failover from the Active to the Standby engine.

• When warm redundancy is disabled, the Standby engine does not perform the initialization and start up steps until failover occurs. When failover occurs, the Standby engine then goes through initialization and startup states. Once the engine starts, it can then transition to onscan and become active.

If either engine is deployed by itself, it assumes the Active Engine state. In a cascade deploy from the galaxy object, when the primary AppEngine is available it becomes active while the backup AppEngine goes to standby.

If a network communication problem or a failure (such as computer hardware loss or failure) occurs, the standby AppEngine assumes the active state and the engine that was in the active state may assume the standby state. When the cause of the failure has been remedied, this engine assumes the standby - ready state.

For more information on redundancy, see the Application Server User Guide.