• Redundant Application Engines

• The purpose of Application Engine Redundancy is to ensure continuous operation by providing an engine that remains active in the event of a single system component failure. It operates on the principal that with redundant engines, one engine is in an Active Role while the other is in a Standby Role waiting to take control.
• The hardware topology required for Redundant Application Engines functionality is simple: two computers with two network interface cards (NIC) each. (Additional network cards could be used for other purposes.)
• To configure redundancy, open the Application Engine Object Editor and check “Enable Redundancy” on the Redundant tab.

• The Application Engine that is enabled is considered the Primary engine of the redundant pair; when you enable this engine, an additional (Backup) engine is automatically created.
• Since an engine is required to run under a platform, the platform objects that sponsor the Primary and Backup application engines need to be configured to use the dedicated NIC. This NIC provides a high speed inter-connection link or Redundant Message Channel between the platforms. The Message Channel is vital to keep both engines synchronized with alarms, history, and checkpoint items from the engine that is in the Active Role. Each engine also uses this Message Channel to provide its health, along with status information, to the other.
• The sequence of deployment (cascade, Primary first, or Backup First) of the redundant pair of Application engines determines which of these in the pair will take the Active Role. The first engine deployed takes the Active role while the other one takes the Standby role. The engines maintain their current roles until a failure occurs. (A failure might consist of computer hardware lost or failed, or a network card failure.) If a failure occurs, the engine with the Standby role assumes the Active role and the engine that was in the Active role is given the role of Standby - Not Ready. When the cause of the failure has been remedied, this engine assumes the Standby - Ready role.

• Terminology

• Two sets of terms are critical to understanding the functions of redundant objects. These are described below.

• During Configuration

• Primary object: The object intended as the main or central provider of the functionality in the run-time. For AppEngines, it is the object you enable for redundancy. For data acquisition, it is the DIObject you intend to use first as your data source in the run-time.
• Backup object: The object that provides the functionality of the Primary object when it fails. For AppEngines, it is the object created by the ArchestrA infrastructure when the Primary object has been enabled for redundancy. For data acquisition, it is the DIObject you do not intend to use first as your data source in the run-time.

• During Run-Time

• Active object: The object that is currently executing desired functions. For AppEngines, it is the object that is hosting and executing ApplicationObjects. For data acquisition, it is the object that is providing field device data through the RedundantDIObject.
• Standby object: The passive object; that is, it is waiting for a failure in the Active object's condition or for a force-failover. For AppEngines, it is the object that monitors the status of the Active AppEngine. For data acquisition, it is the object that is not providing field device data through the RedundantDIObject.

Note: In the case of AppEngine redundancy, ArchestrA supports a one-to-one
topology in which the computers hosting the Primary and Backup object sets must
be connected by crossover cable and have fixed IP addresses.

•  Key Points

• Before placing an engine with redundancy enabled under a platform in the Deployment view, configure the platform Redundant Message Channel; otherwise the engine will show an error.

• In the Application Views panes of the ArchestrA IDE, only in the Deployment view will the Backup engine be visible.

• The Backup Engine cannot be edited.

• After editing an engine with redundancy enabled while it is deployed, when it is redeployed the engine which has the Active role will perform this function. It will then update the engine that is in the Standby role.

• A Backup engine's deployment status can be different from that of the Primary Engine, but operations such as renaming, importing and exporting, GRdump and GR load that are performed on the Primary Engine are automatically performed on the Backup. These operations cannot be performed on the Backup Engine alone.

• Platforms hosting primary and backup AppEngines should have identical configuration. For instance, it is possible to configure the platform with the Primary to be the InTouch Alarm provider and filter the areas you want to query in the Platform editor. For the Alarm Management system to behave correctly, this same configuration should be implemented in the platform with the Backup. It is recommended that you make the following parameters common to both platforms:

• IT Alarm provider-Areas
• Store Forward directories
• Common user-defined attributes (UDAs)
• Common scripting

• Dedicated and Shared Loads

• There are two types of redundant engine configuration: Dedicated and Shared load.

• In a Dedicated redundant configuration, if the Active Engine fails or is shut down, or if a communication failure occurs, the engine in the Standby Ready role assumes the Active role. In this scenario, the platform with the engine in the Standby Ready role is essentially idling. See the following illustration.

• In a Shared redundant configuration, two or more Redundant Engines reside on each of two platforms. Each platform hosts a Primary and a Backup engine. See the illustration below. This scenario operates similarly to the Dedicated configuration, but allows the application load to be shared on two computers until a failure occurs. When a failure occurs, one platform hosts the load of both application engines. The benefits of using this approach is that the time of failover is shortened and that only part of an application process is affected during a failure.

• What Happens in Run-time

• AutomationObjects are always assigned to the Primary AppEngine in the configuration environment. But in the run-time, AutomationObjects are always deployed to the Active AppEngine whether or not it was initially configured as the Primary object. All files are then deployed by the Active AppEngine’s WinPlatform to the Backup AppEngine as described above.
• In the run-time environment, the Active and Standby AppEngines first attempt to establish communications across the RMC. This occurs when an AppEngine belonging to a redundant pair first starts up. Therefore, if one AppEngine is relocated later to a different WinPlatform, this communication between AppEngines can be reestablished.
• During run-time, the Active and Standby engines communicate with each other and monitor each other's status.
• In the case of a hardware or software failure on one computer, the Standby AppEngine will become the Active one. Then, if you want to move the new Standby AppEngine from its hosting computer, undeploy this AppEngine by using the On failure mark as undeployed option on the Undeploy dialog box, and then reassign and redeploy it to a WinPlatform that is configured for redundancy on another computer.