Source level failover for PI to PI

Source Data Archive-level failover maximizes interface data availability on the receiving Data Archive. Source Data Archive-level failover requires that two source Data Archives having identical tag definitions and data streams for interface points are available . This requirement ensures that the interface will obtain the same data regardless of which source server is active.

Failover is enabled by specifying a primary and secondary source server in the interface startup file. On startup, the interface attempts to establish a connection to each source server then loads and initializes its tag list. Data collection begins from the primary source server, making it the active node while the secondary source server assumes the standby role. However, if one of the source servers is unavailable on startup, the other server is designated the active source regardless of whether it is configured to be primary or secondary. PI to PI server-level failover can happen in two scenarios:

Loss of connectivity to the source

The first failover condition occurs when the interface loses communication with the active PI source server. This may be the result of a temporary network outage, shutdown of the active source server, hardware failure, and so on. The interface does not have a way of identifying the cause of the disconnection. A disconnection means that the interface did not receive a response from the active source within the timeout period. The interface may initiate a short wait then attempt to reconnect to the active source before attempting to failover. The timeout period, pause between reconnection, and number of reconnection attempts are all user configurable parameters.

Note: The default network timeout period is 60 seconds; however, it is not an interface configuration parameter. The network timeout period is configured through the PI API configuration file, pilogin.ini. Please refer to the PI API Users Manual for information on adjusting the default timeout period.

Stale data on the source

For stale data to be detected and failover to occur, the PI to PI server-level failover requires the use of two status points on the source PI servers, one point on the primary and one point on secondary. These status points are referred to in the PI to PI user guide and appear in the Interface Configuration Utility (ICU) as the "Source Server Interface Status Utility Tag" and the "Secondary Source Interface Status Utility Tag". The status points can be created and configured in one of two ways – via Performance Equations or via the Interface Status Utility.

Note: AVEVA strongly discourages using the ISU for the status points for the PI to PI Interface. Instead, you can simply create points that impersonate the ISU points used by the PI to PI failover and employ a mechanism to update those points continuously with the "Receiving Data" digital state. This can be done using Performance Equation points. The PI to PI interface expects the points to be updated on some regular frequency (e.g. every minute) to ensure that server-level failover works correctly.

To use Performance Equations (PE), create a single PE point (yes, a single point) with a data type of "Digital" on the primary collective member. This point will be replicated to the secondary member. Name the point so it is easily identifiable, for example “pitopi1_server_level_failover_point”. In the PItoPI ICU configuration for server level failover, for the primary PI source server, choose the primary PE point as the ISU point. Then choose the secondary source server and choose the secondary PE point as the ISU point; in this case, it will be the same point for both.

Note: Implementing a PE scenario might be configured to limit the PI to PI failover to instances where communication is lost to the source PI server. If your PE is not using a source interface watchdog point as input, then that would be the case; for example, a PE that simply updates itself on some frequency. It might not make sense to use a watchdog point from a single interface in the PE if you have multiple interfaces running on the interface computer. One interface might be down intentionally, which would cause source failover thrashing.

When PEs are used to emulate ISU points, make sure digital PEs are used. The local PE schedulers on each Data Archive collective node must be used and the PE data should not be buffered between members of the collective. The PE should have a value of “0” which represents the “RECEIVING DATA” state and the PE can either be triggered by a source watchdog PI Point or not:

• An example PE with source watchdog point, scheduled to update at some frequency that is less than 60 seconds, but no more than the watchdog point frequency:
  

  IF ('*' - prevevent('Watch dog point','*')) < 60 THEN 0 ELSE 1

• An example PE that acts as a simple heartbeat without using a watchdog point: simply set the PE to a constant of "0", which represents the "RECEIVING DATA" digital state. Schedule it to update on some frequency, e.g. every minute.

PItoPI source level failover causes the PI to PI Interface to read the snapshot value of the status point on the PI Server serving up the data. The interface reads the status point at a dynamic frequency that is not configurable. The interface does not connect to nor read the snapshot on the backup source PI Server until failover occurs.

Receiving Server Failover Status Point (Optional)

An optional Receiving Server failover status point can be set up on the target PI Server. This is a digital point that contains the status of the server level failover. Create the following digital states for the point:

• RETRYING CONNECTION=0,

• PRIMARY,

• FAILOVER,

• SECONDARY,

• INTF STARTUP,

• RECOVERING HISTORY,

• INTF SCANNING,

• INTF SHUTTING DOWN,

• ACCESS DENIED,

• SRC SRV CNXT BAD,

• RCV SRV CNXT BAD

UFO Failover Considerations

In a PItoPI Server level failover configuration, if redundant PItoPI UFO instances are configured, each PItoPI failover instance should use a unique member of the collective as its primary source Data Archive when configuring the server failover.

Debugging

Set /db=7 to enable the interface to print the value it receives from the call to get the ISU digital state.

Note: Setting this parameter may result in extraneous logging.

Failover status logging (/FST Point)

If you enable this setting, you must configure the failover status point on the target PI Server. This point must be manually created by the user. The required point attributes are the following:

The digital set states are:

Note: Source tag mapping by point ID is not compatible with Data Archive-level failover. This is because there is no guarantee of a point ID match between two source Data Archives unless they are part of a PI collective.

Note: PI Data Archive-level failover cannot be configured when time range history recovery (/HRONLY) is used, since the interface does not run continuously in that mode.

For more information on configuring Source Data Archive-level failover, see the Source PI Data Archive-level failover parameters section in this document.