About High Availability

Historian supports high availability of the Historian server, archive files and configuration files. To facilitate this support, Historian uses Microsoft Cluster Server (MSCS) as well as an automated backup strategy. High availability decreases the likelihood of archive file corruption due to software or hardware failures. Implementing high availability ensures that collection of your data remains uninterrupted.

How it Works

If the primary Historian server fails due to software or hardware issues, MSCS replaces it with another Historian server. In addition, through the use of automated backups to a shared location, at least one known good Historian archive is maintained at all times. Older archives are replaced once per hour only if there is a more recent archive in place.

To provide high availability of Historian server for Client Manager, Configuration Manager, and Diagnostics Manager components of the distributed Historian service using Microsoft Failover Cluster Service, you must configure them as generic services in Failover Cluster. For information, refer to Microsoft documentation.

High availability is achieved by following these steps:
  1. Every 5 seconds, MSCS monitors the health of all services and applications it is managing by performing a quick check of whether each service is in a running state.
  2. Every 60 seconds, MSCS performs a more thorough test of the applications' health.
  3. Server high availability logs are added to the server and queried.
  4. If these steps fail, Historian assumes the server is no longer running, which causes the cluster to initiate failover of the application.
Note: By default, MSCS monitors the health of all the services and applications every 5 seconds and 60 seconds. You can change this frequency using the cluster administrator.

For most failures, the cluster will detect a problem within 5 seconds of an application or service becoming unresponsive. In the case of a server hang, where the server process is still running but is otherwise unresponsive, it may take as many as 60 seconds to detect. The time to switch to another Historian server includes the time required for the cluster to re-start the Historian server. Server start-up time depends on the size and number of online archives.

Limitations

  • Only a single Historian resource instance is supported per cluster.
  • The Historian installation automatically registers Historian and AlarmArchiver resources with MSCS.
  • Configuring an AlarmArchiver resource on MSCS requires a dependency on a Historian resource.
  • Running collectors on a cluster is not recommended, as they are not supported on the cluster server. Therefore, failover cannot be performed if a cluster node goes offline. Historian offers a separate collector high availability feature.
  • Historian local security with local users is not supported in cluster nodes.

High Availability of Archive and Configuration Files

Historian supports high availability of the latest archive (.iha) and configuration (.ihc) files. A copy of the latest .iha and .ihc file is created once every hour. If the latest archive files become corrupt, Historian will restore the files.

The following conditions apply when using this feature:
  • Archive files are backed up only for tag data, not for alarms and events data.
  • When using a cluster, this feature is automatically enabled; you cannot disable it.
  • By default, this feature is disabled on a 64-bit Windows operating system.
  • When you enable this feature, backup of all the current archive files is created. This will increase your storage overhead to twice that of the current archive. Therefore, for better performance, we recommend that you do not use this feature for a large-scale system.