High Availability
Server High Availability
Historian includes support for high availability of the archive through the Microsoft Cluster Server, as well as through 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.
If the primary Historian server fails due to software or hardware difficulties, another Historian server is brought online to replace it by the Microsoft Cluster Server. Additionally, 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.
Configuring Clusters
Historian works with the Microsoft Cluster Service Manager to ensure high availability of the Historian server. If the primary Historian node in the cluster experiences difficulties, Historian is automatically started on another node to take over. Server high availability is managed through the Microsoft Cluster Service Manager.
To provide high availability of Historian Server for the Client Manager, Configuration Manager and Diagnostic Manager components of the Distributed Historian service using Microsoft Failover Cluster Service, you must configure them as Generic Services in Failover Cluster.
- For Windows 2003 Server: http://technetmicrosoft.com/windowsserver/en/technologies/genclust.mspx
- For Windows 2008 Server: http://technet.microsoft.com/en-us/library/cc732488(WS.10).aspx
- For Windows 2012 Server: https://technet.microsoft.com/en-us/library/dn50575aspx
Cluster Server monitors the health of all services and applications it is managing by performing a quick check of whether the service is in a running state every 5 seconds . Every 60 seconds it performs a more thorough test of the applications' health. Server high availability logs in to the server, adds a data point and queries it back. If these steps fail, Historian assumes the server is no longer live, which causes the cluster to initiate failover of the application. The 5 and 60 second frequencies are defaults and may be configured through 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 complete a switch-over consists of the time required for the cluster to re-start the Historian server. Server startup time is heavily impacted by the size and number of online archives.
Requirements
Historian must be installed on each node of the cluster. As such, a hardware license key is required for each node of the cluster. Configuring a Historian resource on Cluster Server requires dependencies on the following resource types:
- IP Address: Client access must be allowed to Historian server IP Address.
- Network Name: Client access must be allowed to Historian server Network Name.
- Storage: A shared storage device or shared storage location must be available to all Historian cluster nodes in order to store the Historian archive files.
When configuring Client Manager, Configuration Manager and Diagnostics Manager, enable the Use Network Name for Computer Name option on the General Tab of the resource's properties. This is done only after you configure the components of the Failover cluster.
Limitations
- Only a single Historian resource instance is supported per cluster.
- The Historian install automatically registers Historian and AlarmArchiver resources with Cluster Server.
- Configuring an AlarmArchiver resource on Cluster Server requires a dependency on an Historian resource.
- Running collectors on a cluster is not recommended, as they are not supported on the cluster server and do not fail over if a cluster node goes offline. Historian offers a separate collector high availability function.
Auto Recovery Backup Files
The Auto Recovery Backup Files option ensures high availability of the latest archive (.iha) and Historian configuration (.ihc) files. If the latest archive files become corrupt, Historian will load the Auto Recovery Backup Files and restore the archive. When enabled, a copy of the latest .iha and .ihc file is made once every hour.
The Maintain Auto Recovery Backup Files option does not automatically update Alarm data and events. Auto Recovery Backup Files are created only for tag data archives.
The Auto Recovery Backup Files option is enabled when running on a cluster, and cannot be disabled. By default, the Auto Recovery Backup Files option is disabled on a 64-bit Windows system. On a large-scale system, it is recommended that you disable Auto Recovery Backup Files option for better performance.