NGA redundancy

CAUTION: This scenario is only available for PostgreSQL® and InfluxDB®.

Redundancy with duplicated Database Instances managed by NGA:

In case of databases which are not redundancy-capable, NextGen Archiver must take care of the main redundancy use cases:

  • Keep passive DB in sync with the active one
  • Switchover between redundant partners
  • DB Sync after restart of a passive system
  • Including database / connection state in overall “system health”
Figure 1. NGA redundancy architecture

The basic idea to perform this is to use two identical backends on each redundant node, one connected to the local database, the other one to the database on the redundant partner. The active WinCC OA server is writing to both backends, the passive WinCC OA server just buffers the data blocks until they have been successfully written to the databases by the active backend, then this data is discarded.

In this scenario, the two databases are completely independent of each other. They are not part of a cluster and both are written to by the active WinCC OA server. Therefore, these databases are kept consistent by writing the same data to both.

In case of a redundant system, the NGA frontend sends all data additionally to the backend writing to the other WinCC OA server (“Backend 2” in the picture above). After a switchover, the formerly passive WinCC OA server starts to write the existing buffers (which have not yet been committed by the formerly active WinCC OA server) into the databases (local and remote).

If the other WinCC OA server (or at least the database) is down or unreachable, the backend writing to this host will buffer the data. To cover a longer time range in a redundant environment, the buffering method must be set accordingly (buffer to disk) – see Configuration - Frontend.

After the restart of the passive WinCC OA server / database, the backend of the active WinCC OA server writing into the passive database will automatically detect the availability of the database and start to write the buffered data (recovery). The passive WinCC OA system will delete any locally stored buffers automatically if data has been written by the active WinCC OA server.

All read requests for historical values / alerts (dpGetPeriod, dpGetAsynch, alertGetPeriod, dpQuery) from user interfaces will automatically be routed to the active WinCC OA system by the Event Manager. Control managers must be started by using the command line parameter "-connectToRedundantHosts" to be automatically routed to the active WinCC OA host. This is standard WinCC OA redundancy behavior.

Figure 2. WinCC OA System Overview panel for a redundant NGA project

The NextGen Archiver is also shown on WinCC OA’s System Overview panel.

When a project is generated which is using NGA, the standard backend (PostgreSQL®) is displayed for both redundant nodes and the error state calculation includes the NGA manager. The weight is calculated based on the backend connection to the database (bad = no connection to database).

Note: Split mode is not available for redundant NGA projects! Split mode is not disabled in the panel. Therefore, do not use it in a redundant project.

For additional notes on security of PostgreSQL® databases, see chapter PostgreSQL® Notes.