Historians and Multiple Servers

In most smaller systems (ranging up to a few thousand tags) you may not need to have more than a single Historian tag.

Reasons why you might consider adding one or more additional Historians include:

• Load distribution in larger systems - each Historian can be configured to save its data to a separate server, thus reducing load on any individual server.
• Alternate storage locations for selected tags - you may configure each historian to save to a different directory, or to a different storage format.
• Alternate configurations for data limiting - you may choose to limit the amount of data stored for some tags, but not limit data collected from others. Each Historian can have its own configuration.

This is the default configuration of a multi-server application running on a primary and backup server. HistorianA is the System Historian, saving data on the primary server, then copying it to the backup. The advantage of this configuration is that it creates a fully redundant copy of all data. If Server 1 is the primary, it will direct Server 2 to also write all data as it arrives. If one or the other server goes offline for a period of time, data will be synchronized when access to that server is restored.

 

A variation of the above is to configure the Historian to save data to specific database on one server. Typically, this is done only by sites that use a 3rd-party database. On one server, data is stored using the default VTScada system but on the other, data is stored using the commercial database. Users will see no difference.

To prevent data loss, ODBC Historians should always have a backup server using a distinct, alternate data store. The VTScada database format is always to be preferred for reliability.

 

Using only a 3rd-party database

For this configuration, while both Historians will write to a single database, they will be writing to separate schemas on that database. This configuration would occur if the following configuration is one on the primary VTScada server and left unchanged when the application is installed on the remote server.

SystemHistorianStorageType      = ODBC
SystemHistorianStorageLocation  =  Driver=SQLite;Server=DBServer;Database=DBName;Uid=user;Pwd=pwd 

There is no particular advantage to having the System Historian write to separate schemas on the same server. Therefore, if using an ODBC storage type you should consider using a workstation configuration file to set a unique StorageLocation value on each server.

Two Historians

This figure compares the difference between having one versus two Historians on a single server. There is no advantage to this configuration - it merely illustrates the difference.

Historian Load Distribution

This example is designed to handle an extremely high data-logging load by providing three Historians, each with one redundant server. It is assumed that each Historian is logging data from 1/3 of the tags.

In this configuration, each of the machines will carry 2/3 of the disk activity load.

Server detail shown from the Advanced Interface of the Edit Server Lists page of the Application Configuration dialog.