Architecture

The SKOOR Engine uses a PostgreSQL database to store its configuration data as well as its historical value and history data. It supports the use of a primary/standby setup to continuously replicate the database contents. PostgreSQL’s own replication methods are used, which means, that an exact copy of the database on the primary is being kept on the standby and all updates to the database on the primary server are replicated immediately to the standby. The primary server buffers the SQL statements in a binary log, the standby server requests these statements from the server.

This assures short outage times in case of hardware failures. However it will NOT protect from pilot errors like erroneous delete statements which will be synced immediately to the standby. Replication does not replace regular backups.

The following figure shows an example of a standard replication layout.

In the default mode the primary carries all load, all user requests are answered by the Apache webserver on the primary, measurement data are delivered by the collectors to the current primary server and stored in the database. The services eranger-server, eranger-collector and eranger-report do NOT run on the standby server.

Main features of the replication setup

• Replication can be implemented even with external SKOOR collectors.

• If a replication has been issued previously, a large portion of the database files will probably already be in sync. The script will NOT transfer old tables which are already in sync. This saves network bandwidth if a re-initialization has to be issued.

• There is no automatic failover from primary to standby. It was designed to leave this decision to a human. However, the script supports a non-interactive mode which would allow issuing a failover by a script. (option -f ).

• Possibility to monitor the primary from the standby (independent of SKOOR) sending one email as soon as it detects that the SKOOR engine is not running anymore on the current primary.

• Possibility to run custom scripts or commands before and/or after switching the server functions (standby to primary and vice versa).

Requirements

To setup the database replication a second SKOOR server is required with the same performance specifications as the first one. Although this standby will be in standby mode most of the time, it must be capable to carry the full load when its function changes from standby to primary.

The following prerequisites must be met:

• The same version of SKOOR is installed on primary and standby.

• (Optional) external collectors are setup correctly and are working

  • The server<n>_address parameter must be set to the same IP as the primary server

  • Collectors using the HTTP protocol can not be switched automatically

• The file /opt/eranger/bin/eranger-server-replication.pl is identical on primary, standby and all collectors. This means all involved hosts must have the same SKOOR Version installed.

• The file /etc/opt/eranger/eranger-replication.cfg is configured correctly and is identical on primary, standby and all collectors.

• Network connectivity

  • TCP port 22 (ssh) from primary to standby, vice versa and from primary and standby to all external collectors.

  • TCP port 50001 (SKOOR collector data delivery) from all external collectors to primary and standby.