Redundancy Architecture

WinCC OA can run in redundant mode where two WinCC OA servers (“called "left” and “right” in the following context) are used and the failure of one of these systems is compensated by the other. One of the servers is always the “active” one, sending data to peripheral devices and handling user interfaces, the other server is the “passive” one, maintaining a copy of the state of the active server.

This chapter describes the redundancy in the NGA environment. For details about general redundancy, see chapter Redundancy, basics.

The main aspect of NGA redundancy is to avoid losing historical data due to single hardware or software failures. The implementation is intended to be able to cope with single failures, not multiple parallel ones (e.g. hard disk crash on both servers). Another aspect of NGA redundancy is to provide historical read access for remote user interfaces even if one redundant WinCC OA node or one database node is down (if the database is redundant and located on a separate server).

There is also a special option called “split mode” for redundancy. This executed option puts both servers in the active state until the mode is deactivated - after which one of the servers remains active and the other is restarted, including recovery (standard WinCC OA redundancy function when a server project is restarted). This option is currently not supported by the NextGen Archiver.

Each redundant server has an “error state” (so called “health state”) which normally should be identical on both servers. If not, the server with the better “health state" will get active, possibly causing a “switchover” between the active and the passive server. If a server has stopped, it must be synchronized at the next restart to have the same “health state” (data point values, alert states etc.) as the currently running one. This is called recovery.

In order to convert an existing NGA based project to a redundant one in addition to non-NGA related steps (see Redundancy, basics) the NGA frontend and backends also have to be converted to redundancy. This is accomplished by clicking the button “Create redundant NGA data” (“General” tab in the NGA configuration panel, see Configuration - Archive Group).

For using NextGen Archiver in a redundant system two different schemas – depending on the redundancy support of the used database(s) – are possible:

• If the database is not able to do redundancy on its own (e.g. the open source version of InfluxDB®), the database must be running on both nodes, which are independent of each other (as far as the database is concerned)
• If the database is capable of redundant operation (i.e. PostgreSQL®, MS SQL®) then both redundant NGA instances can talk to a common database instance which will perform redundant operations (switchover, recovery) on its own.