Using a Redundant Historian

You can configure Historian Server to have a partner Historian Server that can be used as a hot backup if the primary historian is not available. This is called a redundant historian setup. If Application Server is configured to store data to Historian Server, the AppEngine automatically sends data to both the primary historian and the specified partner. If one of the historians goes offline, the AppEngine goes into store-and-forward mode for the historian that is offline to store the historized data until the historian comes back online. After the connection is restored, the AppEngine forwards the data to the historian that was offline. The Historian Client automatically detects and selects the online historian from the redundant pair.

The historians in a redundant setup are not intended to be a synchronized pair, where both the historian configuration and data are fully and automatically synchronized. It is up to you to make sure that the two historians are symmetrical and synchronized. The following recommendations are examples of actions you should take to keep the pair synchronized; otherwise, forwarded data is not inserted as previously described.

• If you make configuration changes for one historian, be sure to perform the same action on the partner.
  
• If you perform a .csv import on one historian, you need to repeat the import on the partner.
  
• If you add or update data to one historian using SQL or the Historian SDK, you need to repeat the action on the partner. To specify a historian partner, modify the value of the Historian Partner system parameter typing the computer name of the partner historian. You can use either the host name, fully-qualified name, or an IP address. Leading backslashes are optional. In network environments where AppEngine and Historian Client computers on different subnets must access the partner, be careful to use a name or IP address that can be correctly resolved from all of those network locations and not just between the Historian Servers themselves.
  

 
In a Dual Historian configuration, special attributes report a combined summary status for both partner Historians.
 
Statuses for Individual Historian Connections

• Engine.Historian.ConnectStateMask – Bitmask where the lowest order bit represents the connection state of the primary historian and the second bit represents the connection state of the partner. If no partner is configured, the second bit will always be 0.
  
• Engine.Historian.InStoreForwardMask – Bitmask where the lowest order bit represents the store-and-forward state of the primary historian and the second bit represents the store-and-forward of the partner. If no partner is configured, the second bit will always be 0.
  
• Engine.Historian.ConnectionPartner – Name of the partner Historian Server. You can use either the host name, fully qualified name, or an IP address. Leading backslashes are optional. The name/IP used must be one that can be correctly resolved by all of the AppEngine and Historian Client computers that will connect to the partner.

Statuses for Overall Historian Connection

• Engine.Historian.ConnectState – Physical state of the connection between HCAL and the historian. This value should remain TRUE as long as HCAL is able to communicate with the historian, regardless of whether it is historizing data or not. A network failure, for example, will cause the ConnectState attribute to be set to FALSE. Even if the ConnectState attribute is FALSE, the AppEngine may still be connected to the historian and appear listed as a client in the historian System Management Console. In a redundant historian setup, the connect state is TRUE if the connection is good for at least one of the historians. To determine state of an individual historian in a redundant setup, use the ConnectStateMask attribute.
  
• Engine.Historian.ConnectStateCmd – Used to control the state of historization between the engine and the historian. If this value is set to FALSE, the engine will stop sending updates to HCAL, and HCAL will disconnect from the historian to ensure that a gap is displayed on a history trend. HCAL will disconnect from the historian even though it is able to communicate with it, as reflected by the ConnectState attribute. 

Active Engine Statuses

• Engine.Historian.InStoreForward – If set to TRUE, HCAL is in store-and-forward mode. In a redundant historian setup, the InStoreForward attribute is TRUE if either one of the historians is in store-and-forward mode. To determine state of an individual historian in a redundant setup, use the InStoreForwardMask attribute.
  
• Engine.Historian.StoreForwardProblem – If set to TRUE, the HCAL on the active engine is unable to store data while in store-and-forward mode. In a redundant historian setup, the StoreForwardProblem attribute is TRUE if either one of the historians has a store-and-forward issue.
  
• Engine.Historian.StoreFwdDataLost – Logical OR of individual StoreForwardDataLost statuses – Set to TRUE when HCAL is in store-and-forward mode, the store-and-forward deletion threshold has been exceeded, and history data has been lost. This value remains TRUE until the connection to the historian has been re- established and store-and-forward is no longer in effect.
  
• Engine.Historian.StoreForwardSpaceAvailable – The available storage space in MB for the HCAL of the active engine. Since this is the same hard drive for both historians, possibly measured at different times, this is the arithmetic minimum of the values reported by the primary and secondary historian.
  

The same set of attributes apply to the standby Engine when working in a redundant Engine configuration:

1. InStoreForward_Standby
2. StoreForwardProblem_Standby
3. StoreForwardDataLost_Standby
4. StoreForwardSpaceAvailable_Standby

 
Store-and-Forward

The following is the store-and-forward directory structure created for a Galaxy where the WinPlatform (GRPlatform) and the Engine (AppEngine1) both are enabled for storage to historian (X01STD) and where a historian partner has been configured. Notice there is one folder for each Historian Server part of the pair. The custom store-and-forward directory was configured as C:\S&F.