RDSynchronizer
RDSynchronizer
RDSynchronizer is a component that can be added to the CDP application to make the application redundant. RDSynchronizer needs RDNodeSync blocks (it will auto-create them at runtime, if not existing) for the application value and state synchronization to happen and an RDSelector block for the information which one of the redundant applications is currently the leader.
RDSynchronizer takes care of contacting all other applications in the redundant application group. RDSynchronizer acts as a manager for all the RDNodeSync blocks in the application and orders them to act either as leaders (send value updates to followers) or as followers (receive value updates from leader).
Note: There is no explicit need to add and pre-configure RDNodeSync blocks manually, because when RDSynchronizer starts with no RDNodeSync blocks configured for it, then it will auto-create one at the application top-level - using RDNodeSync default values. RDNodeSync blocks need to be added and pre-configured only when you need some special, non-default configuration for them.
RDNodeSyncView Blocks
In online mode, RDSynchronizer creates a list of RDNodeSyncView blocks under itself. It creates one RDNodeSyncView block for each RDNodeSync block that it manages. This list is therefore handy to see the status of all the RDNodeSync blocks in the system from one place.
RDSynchronizer Signals, Properties and Alarms
Signals
| Name | Direction | Description |
|---|---|---|
| LeaderIndex | Input | Zero-based index of currently elected leader application configured via RDAppList. The value instructs RDSynchronizer to switch itself (and all RDNodeSyncs that it manages) either to leader (when the LeaderIndex points to the current application) or follower (otherwise) mode. Value is expected to be a zero-based index - for example, LeaderIndex = 0 indicates that the first application in the RDAppList is leader. |
| Started | Output, read-only | Signal that will be set to true only after the current application is fully started up and synchronized with the configured companion redundant applications (either as leader or follower). When all companion applications can not be contacted, then this signal will still be set to true after the CompanionWait timeout. |
| RedundantLeader | Output, read-only | Signal that will be set to true only after the current application is fully started up and synchronized and selected as a leader in the redundancy group and there is at least one follower connected to it to provide redundancy. In other words, this signal is set to true only when the SyncStatus property is set to 1 or 2. |
| Follower | Output, read-only | Will be set to true when this application is currently in a follower state (i.e. application is not yet fully started up or the LeaderIndex is not set to this application index) |
Properties
| Name | Special flag | Description |
|---|---|---|
| RDAppList | Semicolon-separated list of application names that form the synchronizable redundant application group. Note: Note, that the order of the application names in this property is very important as LeaderIndex signal acts as a zero-based index of the application in this list. | |
| RDGroup | Specifies the name of the redundancy group. Every RDSynchronizer contacts only RDSynchronizers of redundant applications with the same RDGroup value. Usually only one RDSynchronizer with the default value "RDGroup1" is enough to add to make the application redundant. In some cases, multiple RDSynchronizers with different RDGroup can be useful, for example when different parts (components) of the application need to be synced by different redundant application groups. | |
| StartupDelay | Time to wait after application startup before the RDSynchronizer starts to manage RDNodeSync nodes. The timeout allows LeaderIndex routed from any RDSelector to propagate and settle thus not causing the RDNodeSync nodes to flip between incorrect leader/follower states for some short cycles at the startup. | |
| CompanionWait | Time to wait after application startup for companion applications to appear. After this timeout RDSynchronizer sets its Started signal to true even when some companions are not available. | |
| Leader | Read-only | Will be set to true when this application is currently a leader in the redundancy group (i.e. the LeaderIndex is set to this application index) |
| SyncStatus | Read-only | Current synchronization status of the RDSynchronizer and all RDSelector nodes managed by it. See SyncStatusValues for possible values. |
SyncStatus values
SyncStatus property can have the following values set:
| Value | Status Description |
|---|---|
| 0 | Initial value, no synchronization status yet |
| 1 | RDSynchronizer is set to synchronization leader and all configured (by RDAppList) followers are connected. When all followers RDSynchronizers are reporting SyncStatus 3 then maximum redundancy and failover readiness is achieved. |
| 2 | RDSynchronizer is set to synchronization leader and some configured followers (but not all of them) are connected. |
| 3 | RDSynchronizer is set to follower and is connected and successfully synchronized from the leader. When all configured follower RDSynchronizers are reporting SyncStatus 3 then maximum redundancy and failover readiness is achieved. |
| -1 | Error in the RDSynchronizer configuration was detected. |
| -2 | RDSynchronizer is set to synchronization leader but there are no follower applications to synchronize the values to. No redundancy is therefore achieved. |
| -3 | RDSynchronizer is set to follower but it is not possible to contact the leader application. |
Alarms
| Name | Description |
|---|---|
| NodeStatus | Alarm is triggered when any of the RDNodeSync blocks that are managed by the RDSynchronizer have reported issues in status i.e. their SyncStatus becomes non-zero |
Application-Specific Configuration for Cloned Applications
By default the redundant application cloning in Studio copies everything from the source application to the cloned application, unchanged. The cloning process only alters full routings that refer to the source application so that they will start to refer to the newly cloned application.
This default routing correction can be altered to more complex logic using AppSpecificNames and FixedAppName blocks that can be added to the RDSynchronizer block.
AppSpecificNames
AppSpecificNames block can be added to specify the target application or component names that should be different in every cloned application. This is useful when the cloned applications are all similar except some routings have to refer to different nodes (applications or components or any other node) in their routings.
Properties of AppSpecificNames
| Name | Description |
|---|---|
| Names | Semicolon-separated list of cloned application-specific target names, in the same order as the applications are listed in the RDAppList property of the parent RDSynchronizer block. When the application is cloned, this list is taken and the name from the position of the source application (in the RDAppList order) will be replaced with the name at the position of the cloned application. The replacement is applied for all routings of the cloned system. |
Example usage of AppSpecificNames block.
The following are some example usages of the blocks (in the YAML configuration snippet format).
Example 1. Two redundant clonable applications have explicitly to use different IO apps in their routings:
configure: - uri: RDSynchronizer add: - name: IOAppNames model: Redundancy.AppSpecificNames values: Names: IOApp1;IOApp2
Example 2. Two redundant clonable applications have to use two different simulator apps:
configure: - uri: RDSynchronizer add: - name: SimAppNames model: Redundancy.AppSpecificNames values: Names: Sim1;Sim2
Example 3. Two redundant clonable applications have to use different components under some non-redundant IO companion app:
configure: - uri: RDSynchronizer add: - name: IOCompNames model: Redundancy.AppSpecificNames values: Names: IO.Comp1;IO.Comp2
FixedAppName
The FixedAppName block can be added to specify the application names that should not be altered in the routings during the application clone. This block can be useful when you have pre-configured routings to some specific cloned applications and you do not want these routings to be altered during the application clone.
Properties of FixedAppName
| Name | Description |
|---|---|
| Referrer | Specifies the referrer path in RDApp where the FixedAppName will be only applied to. Can also be a UI widget object name like 'lineEdit1'. |
| FixedName | Specifies the fixed application name that should not be altered during application clone. |
Example usage of FixedAppName block (in the YAML configuration snippet format).
Example 1. RDSelector.QoS.RD1App.Routing and RDSelector.QoS.RD2App.Routing has not to be altered during clone:
configure: - uri: RDSynchronizer add: - name: QoSRD1AppAlive1 model: Redundancy.FixedAppName values: Referrer: RDSelector.QoS.RD1App.Routing FixedName: RDApp1 - name: QoSRD1AppAlive2 model: Redundancy.FixedAppName values: Referrer: RDSelector.QoS.RD2App.Routing FixedName: RDApp2
Example 2. Application part in UI widgets named meter1 and meter2 cdpRouting has not to be altered during clone, as they are explicitly set to connect to the application names RDApp1 and RDApp2:
configure: - uri: RDSynchronizer add: - name: FixedName1 model: Redundancy.FixedAppName values: Referrer: meter1 FixedName: RDApp1 - name: FixedName2 model: Redundancy.FixedAppName values: Referrer: meter2 FixedName: RDApp2
AppSpecificValues
The AppSpecificValues block can be added when some configuration values have to be different in each of the cloned applications.
Properties of AppSpecificValues
| Name | Description |
|---|---|
| ValueNodes | Node routing where the values have to be different across cloned applications (values to apply are specified in the Values property). Usually contains only one routing to a node (it can be a routing to any of the companion application node), but can contain multiple routings separated by semicolons, when several nodes across the application should have the same values specified in the Values property. |
| Values | Semicolon-separated list of values in redundant applications, in the same order as the applications are listed in the RDAppList property of the parent RDSynchronizer block. When the application is cloned, then the value from the corresponding position (in the RDAppList order) will be applied to the target nodes specified in the ValueNodes, both in the clone target and also in the clone source application. The value list should have the same size as the list in RDAppList property. |
Note: Note, that the corresponding value is replaced in the clone source application as well. But the value there is not updated immediately when the Values property is set or modified - the value in the source application will only be updated during any "Clone" or "Update From Source" menu action executed from the CDP Studio.
Example usage of AppSpecificValues block (in the YAML configuration snippet format).
Example 1. Two redundant, cloned applications have to use different IP addresses/ports in their configurations. In the first application the address should be 192.168.1.10:555 and in the second application the address should be 192.168.1.11:666:
configure: - uri: RDSynchronizer add: - name: AppSpecificHosts model: Redundancy.AppSpecificValues values: ValueNodes: RDSelector.IOServer1.RemoteAddress;RDSelector.IOServer2.Host Values: 192.168.1.10;192.168.1.11 - name: AppSpecificPorts model: Redundancy.AppSpecificValues values: ValueNodes: RDSelector.IOServer1.RemotePort;RDSelector.IOServer2.Port Values: 555;666
Section
See also RDNodeSync and RDSelector.
Get started with CDP Studio today
Let us help you take your great ideas and turn them into the products your customer will love.