Standard and High-Availability Configurations
Standard and High-Availability Configurations
You have wide flexibility in configuring the Historian system. Since Historian can support a fully distributed architecture, you can spread the data collection, server, administration, and client data retrieval functions across many different nodes in a network, or you can install all components on a single computer.
Since the Historian API is the basic building block for connectivity, all Historian functions, including data collection, administration, and data retrieval, use the Historian API.
You can connect the Historian API to a local Historian Server in the same manner as to a remote Historian Server by simply providing the name of the server. This name must be the Computer Name or IP Address of the target Historian Server, and the server must have TCP/IP connectivity. If you use the Computer Name of the server rather than the IP Address, the IP Address must be available to the client through DNS, a WINS server, or through the local host table.
It is recommended that you install the Historian Server on a central dedicated server. Next, install data collectors on each data source, and point them back to the central Historian Server by specifying the appropriate server Computer Name. Install a separate data collector for each type of collection interface used in your system.
You can also have mirroring of stored data on multiple nodes to provide high levels of data reliability. Data Mirroring also involves the simultaneous action of every insert, update and delete operations that occurs on any node.
You can install various types of collectors on a single computer, subject to constraints detailed in Installing Historian Data Collectors.
Standard Historian Architecture
Standard Historian offers unique capabilities and benefits for a sustainable competitive advantage:
- Built-in Data Collection
- Fast Read/Write Performance speed
- Enhanced Data Security
- Robust Redundancy and High Availability
The following topics give you a quick insight to different use cases to consider when deploying your Historian architecture.
Single Node Data Only System
Figure: Single Node Data Only System
Data Collection from SCADA Systems and other Programs
Figure: Enterprise Data Collection Examples
Integration with Client Programs
Figure: Data Collection and Client Connection Examples
High-Availability Architecture
Figure: High Availability Example
You can mirror stored data on multiple nodes to provide high levels of data reliability. Data Mirroring involves the simultaneous action of every insert, update, and delete operation that occurs on any node. Historian allows you to have up to three mirrors, a primary and two additional mirrors.
Historian Data Mirroring
If you have purchased an Enterprise-level license for Historian and your license entitlement includes mirror nodes, you have the option of setting up to three mirrors (primary server + two mirrors).
Historian Data Mirroring provides continuous data read and write functionality. In a typical data mirroring scenario one server acts as a primary server to which the clients connect.
To create a mirror, you add mirror nodes and establish a data mirroring session relationship between the server instances. All communication goes through the Client Manager, and each Client Manager knows about the others.
Mirrors must be set up in a single domain.
Figure: Mirroring Example
Client Connections in Mirrored Environments
When a client (either a writing collector or reading client), connects to the Client Manager, it gathers information about each client Manager along with all archive, tag, and collector configuration information from the Configuration Manager, and stores this information locally in its Windows Registry.
A relationship is then established between each remote client and a single Client Manager, which directs read and write requests across the other mirrors. If that relationship is broken, it will establish a new relationship with the next available Client Manager, which assumes the same responsibilities. This bond is maintained until that Client Manager is unavailable, and then the process of establishing a relationship with another Client Manager is repeated.
When more than one node is running, the Client Manager uses a "round robin" method between the good nodes to balance read loads. Each read request is handled by a node as a complete request.
Writes are sent independently but nearly simultaneously to any available Data Archiver so that the same tag shares a common GUID, name, timestamp, value, and quality as passed to it by the Collector.
Read and Write Client with Mirroring
Historian in a Cluster Environment
- Read the Important Product Information document and verify that all the prerequisites are properly installed.
- Configure a failover cluster in Windows Server 2008 R2. See Installing Historian in a Cluster Environment. See also Configuring Clusters section in the Using Historian Administrator ebook.
- To use Historian Alarms and Events in a cluster environment, select the appropriate SQL Server for both the Cluster Nodes.