Reports and Trends Server Redundancy

Redundancy of Reports, Trends, and I/O servers is achieved by adding standby servers, within a defined cluster, to provide redundant system components. In addition you can also utilize the dual end point (or multiple network interfaces) capabilities of each component, effectively enabling you to specify a complete and unique network connection from a client to a server. See Network Redundancy.

Consider the following diagram:

Server redundancy of each component in the diagram is achieved by providing a corresponding standby server on the same network (LAN 1). Redundancy is provided as follows:

• If any of the servers become inoperative or communications become inoperative, their standby counterpart assumes operation.
• For I/O Server redundancy, when the inoperative I/O Server comes back online, it resumes control based on the individual I/O device primary or standby priority configuration..
• For Trend and Report servers, when the inoperative primary server returns online, the client will remain with the standby unless the primary has a higher priority.
• For Reports, and Trends Server redundancy, clients connect to either the Reports, or Trends primary server or standby server. On startup, clients try to establish a connection with the primary server. If a connection with the primary server cannot be established, they will try to establish a connection with the standby server. If the primary server becomes available, any clients connected to the standby server remain connected to the standby server unless the primary has a higher priority. If the standby server becomes inoperative the client will revert to the primary server. The priority is set using the connectivity parameters described below.

In 2018 Alarm Server Redundancy has been modified to be a main/standby model. Refer to Alarm Server Redundancy for more information.

Connectivity Parameters

The client sub system runs in every SCADA client or server process. It connects to all servers within all clusters that are enabled, allowing any process to send data requests to any other server, either through internal systems or Cicode function calls.

Two Citect.ini parameters allow you to configure how the client sub system will manage its connections to redundant pairs of Reports or Trends servers.

These parameters are [Type.ClusterName.ServerName]Priority and [Type.ClusterName.ServerName]DisableConnection, where Type is the relevant server type (Report or Trend). The default setting for these parameters provides behavior as described above, in that if the client sub system is redirected to a standby server it will retain a connection to that server, providing that it is operable, even when the primary server is restored. This is also the behavior that will occur if these parameters are not added for a given server type.

The connectivity parameters can be set at the system level using the Parameters form of the project, or specifically for each computer in the local Citect.ini file.

For a detailed explanation of these parameters see:

[Report.ClusterName.ServerName]Priority

[Trend.ClusterName.ServerName]Priority

[Report.ClusterName.ServerName]DisableConnection

[Trend.ClusterName.ServerName]DisableConnection

See Also

Published June 2018