Redundancy

CDP Redundancy is a CDP add-on that can be used to make the CDP system fault-tolerant by seamlessly switching to a standing-by, real-time-synchronized backup application, in the case where an application fails because of a problem.

Redundancy Blocks Overview

To make the CDP system redundant, this add-on has the following blocks:

• RDSynchronizer - a value and state synchronization organizer block
• RDNodeSync - one or multiple blocks that carry on the actual synchronization of values and states
• RDSelector - a selector block that "senses" which one of the redundant applications is currently "alive"

When creating custom CDP blocks consult the Guide For Creating Redundancy-Aware Blocks.

Leader and Followers in Redundancy

Redundant applications are identical applications, that can immediately take over each other's function in case of one application failure. Together these applications form a redundant application group. In every redundant application group, at runtime, there is always only one application at any time which is in the leader state while all other (one or more) applications are on the follower state:

• Leader application is responsible for controlling the functions delegated to the redundant application group - like controlling the hardware or communicating with the user interface. Leader sends real-time synchronization updates to all follower applications with changed values and states.
• Follower applications are identical clones of the leader that run in parallel, only that they have no responsibility for functions delegated to the redundant application group. Followers receive real-time synchronization updates from the leader thus keeping their internal state identical to the leader, in real-time.

The following pictures illustrate the synchronization data flow from Leader to 2 Followers in different failover situations:

Creating a Redundant Application

Converting an existing non-redundant application into a redundant application is quite simple. For example, to make an application named App1 into a redundant application, only these actions are needed:

• Decide what will be the companion application name - for our example case let it be App2
• Add a RDSelector to the application and configure its RDAppList property with redundant application names
• Add a RDSynchronizer to the application and configure its RDAppList property with redundant application names
• Route LeaderIndex signal from RDSelector to RDSynchronizer
• Clone the App1 using CDP Studio clone application context menu to the initially chosen name (App2)

Creating a More Complex Redundant System

In the real world, just making an application redundant is not useful or enough, as usually some non-redundant hardware or some non-critical application (like a non-redundant UI application) needs to be connected only to the current leader redundant application.

In these cases, exact copies of RDSelector blocks needed to be added to the non-redundant applications as well and then be connected to the leader selector CDP port MUX or DEMUX Index selectors. These port MUX and DEMUX blocks then connect the correct values always from the current leader at any given time, as is shown in the example configuration diagram below.

In addition, sometimes RDNodeSync blocks can be needed to be added manually and pre-configured differently from defaults - for example, to apply some application-specific synchronization filter. For more detailed information see the RDNodeSync manual.

Leader Election

The leader for all blocks is elected by RDSelector, which "senses" the redundant application availability by listening to their heartbeat messages (which are generated also by the RDSelector block) quality plus using some additional information like application startup time and how long the application has already been selected as a leader.

In addition, a user-configurable quality-of-service (QoS) logic (like which of the applications has less noise or errors in connected hardware, etc) can be added to the RDSelector election process. For more detailed information see the RDSelector manual.