OPC DA Interface Failover Manual
for OPC DA Interface Version 2.3.14.0-2.3.20.x or higher
OSIsoft, LLC777 Davis St., Suite 250
San Leandro, CA 94577 USA
Tel: (01) 510-297-5800
Fax: (01) 510-357-8136
Web: http://www.osisoft.com
OSIsoft Australia • Perth, Australia
OSIsoft Europe GmbH • Frankfurt, Germany
OSIsoft Asia Pte Ltd. • Singapore
OSIsoft Canada ULC • Montreal & Calgary, Canada
OSIsoft, LLC Representative Office • Shanghai, People’s Republic of China
OSIsoft Japan KK • Tokyo, Japan
OSIsoft Mexico S. De R.L. De C.V. • Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda. • Sao Paulo, Brazil
OPC DA Interface Failover Manual
Copyright: © 2002-2012 OSIsoft, LLC. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, LLC.
OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, Sigmafine, Analysis Framework, IT Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Data Services, PI Manual Logger, PI ProfileView, PI WebParts, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, LLC. All other trademarks or trade names used herein are the property of their respective owners.
U.S. GOVERNMENT RIGHTS
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC license agreement and as provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as applicable. OSIsoft, LLC.
Published: 06/2012
Table of Contents
Chapter 1. Introduction 1
Reference Manuals 1
Diagram of Hardware Connection 2
Server-level failover configuration 2
Interface-level failover using Microsoft clustering configuration 2
Chapter 2. Principles of Operation 3
Chapter 3. Server-Level Failover 5
Server-Level Failover Options using ICU Control 6
Server-Level Failover Configurations 7
Inactive Server Does not Allow Connections 7
Inactive Server Leaves OPC_STATUS_RUNNING State 7
Inactive Server sets Quality to BAD 8
Watchdog Tags 8
Isolated Watchdog Tags 9
Server-specific Watchdog Tags 11
Multiple Interfaces 11
Logging the Current Server 12
Controlling Failover Timing 12
Logfile Messages for Server-Level Failover 13
Chapter 4. Interface-Level Failover Using Microsoft Clustering 15
Choosing a Cluster Mode 16
Failover Mode 16
How It Works 17
Configuring APIOnline 18
Multiple Interfaces 18
OPCStopStat and Failover 20
Checklist for Cluster Configuration 20
Configuring the Interface for Cluster Failover 22
One Interface 22
Three Interfaces 23
Buffering Data on Cluster Nodes 24
Group and Resource Creation Using Cluster Administrator 24
Cluster Group Configuration 24
Installation of the Resources 28
Logfile Messages for Interface-Level Failover 30
Chapter 5. Using Combination of Server- and Interface-Level Failover 31
Appendix A. Technical Support and Resources 33
Before You Call or Write for Help 33
Help Desk and Telephone Support 33
Search Support 34
Email-based Technical Support 34
Online Technical Support 34
Remote Access 35
On-site Service 35
Knowledge Center 35
Upgrades 35
Appendix B. Revision History 37
OPC DA Interface Failover Manual 35
Chapter 1. Introduction
This is a supplemental document for configuring the OPC DA Interface. It covers configuring and managing the interface for redundancy of the OPC server, the OPC DA interface, or both. It is intended to be used in conjunction with the OPC DA Interface Manual.
For server-level failover, no special hardware or software is required. Interface-level failover using Microsoft clustering requires a Microsoft Cluster. Interface-level failover using UniInt does not require any special hardware or software. Configuration of the interface for UniInt failover is not covered in this manual. It is documented in the OPC DA Interface Manual.
In this manual each type of redundancy will be addressed separately and briefly examined being used together. Note that all the command-line parameters discussed in this document can be configured using the Interface Configuration Utility (PI ICU). The ICU simplifies configuration and maintenance, and is strongly recommended. PI ICU can only be used for interfaces that are collecting data for PI Systems, version 3.3 and greater.
Reference Manuals
OSIsoft
· OPC DA Interface Manual
· UniInt Interface User Manual
Diagram of Hardware Connection
Server-level failover configuration
Interface-level failover using Microsoft clustering configuration
OPC DA Interface Failover Manual 35
Chapter 2. Principles of Operation
The OPC DA interface provides redundancy for both the OPC server and the interface itself. For server-level failover, the interface can be configured to change to another OPC Server when the current server no longer serves data, when an OPC item changes value or quality, or when the OPC Server changes state. This allows the data collection process to be controlled at the lowest possible level, and ensures that data collection will continue even if the connection to the PI System fails.
For interface-level failover, two copies of the interface are running at the same time with only one sending data to the PI System. There are two types of interface-level failover supported by this interface. One uses Microsoft clustering and the other uses the UniInt failover mechanism. This manual describes configuration using Microsoft clustering.
When using Microsoft clustering, the cluster controls which copy of the interface is actually collecting data at any given time. Since the OPC Server may not be cluster-aware, there are several modes that can be configured, to ensure the least possible data loss in the event of a failover, without putting undue stress on the underlying data collection system. This type of failover is not highly recommended unless the user has other reasons for doing it.
The server-level failover can be combined with any type of interface-level failover to achieve redundancy at both levels of data collection, so that even the loss of both an OPC Server and one OPC DA Interface will not interrupt data collection. However, both types of interface-level failover cannot be used at the same time.
OPC DA Interface Failover Manual 35
Chapter 3. Server-Level Failover
The basis of server-level failover is that the interface should always be connected to a server that can provide data. An issue concerns how the interface knows when it should try to connect to another server. There are several ways in which an OPC Server may indicate that it is not able to serve data.
· It does not accept connections. This is the simplest one to deal with. There is nothing to configure except the name of the alternate server.
· It changes state when it is not active, usually to OPC_STATUS_SUSPENDED. The interface can be configured to failover to another server when the current server leaves the RUNNING state.
· It sends bad quality for all tags. To use, an OPC item must be defined which will always have a GOOD quality except when the server is not serving data.
· It has one or more OPC items that have a specific value when the server can serve data and another specific value when it cannot. With this version, it may be necessary to use the Transformation and Scaling ability of the interface, but as long as there is some way to translate the not-active value to a zero and the active value to >0, these OPC items can be used for Watchdog tags. It is possible to specify multiple tags as watchdogs, and specify a minimum value that defines an active server, so that the loss of some server functionality (for instance, one or two OPC Servers are not working) will not cause failover, but a falling below a specified minimum will trigger failover to another server.
· It has one or more OPC items that have GOOD quality when the server can serve data and BAD quality when it cannot. One watchdog tag or multiple watchdog tags can be specified, in addition to specifying the maximum number of watchdog tags that can have BAD quality on the active server without triggering failover.
· It has an OPC Item that has a specific, known value when a given server can serve data and a different known value when that server cannot serve data. In these cases, there is always one Item for each server, and two Watchdog tags are used to control which server is active. This configuration is referred to as “server-specific watchdogs”, because the watchdog Item refers to a given server’s current status, regardless of which server the Item value was read from.
Note: Special handling is also included for Honeywell Plantscape servers, as several customers have had difficulty in getting server-level failover to work properly with these servers. The /HWPS flag tells the interface to failover when it receives an error code of 0xE00483FD or 0xE00483FC on any tag.
The following table lists the command-line parameters used to control server-level failover. The next sections explain how to configure the interface for each of the cases above, using these parameters, and how to use the timing parameters to get the least data loss with the most reliability.
Parameter / Description/BACKUP / The name and location of the backup OPC server
/CS / The string tag into which should be written the name of the currently active server.
/FT / The number of seconds to try to connect, before switching to the backup server.
/NI / The number of interfaces running on this node.
/SW / The number of seconds to wait for RUNNING state, before switching to the backup server.
/WD / Watchdog tag specifications.
/WQ / Failover if watchdog tag has bad quality or any error.
/WS / Failover if the server leaves the RUNNING state.
Server-Level Failover Options using ICU Control
· Backup OPC Server Node Name – The name or IP address of the back-up OPC Server Node (/BACKUP).
· List Servers – Click this button to get a list of OPC Server Names from systems found in the Backup OPC Server Node Name field.
· Backup OPC Server Name – The registered name of the backup OPC Server on the above node (/BACKUP).
· Number of Interfaces on this Node – The count of instances of the OPC DA interface that are running on this node (/NI=#).
· Switch to Backup Delay (sec) – The number of seconds to try to connect before switching to the backup server (/FT=#).
· Wait for RUNNING State (sec) – The number of seconds to wait for the RUNNING status before switching to the backup server (/SW=#).
· Current Active Server Tag – The string tag into which should be written the name of the currently active server (/CS=tag).
· Primary Server Watchdog Tag – Watchdog tag for the primary server (/WD1=tag).
· Backup Server Watchdog Tag – Watchdog tag for the backup server (/WD2=tag).
· Multiple Watchdog Tag Trigger Sum – When using multiple watchdog tags, failover will be triggered if the sum of the value of these tags drops below the value entered in this box (/WD=#).
· Maximum number of Tags which can have Bad Quality or Any Error without triggering Failover –Trigger a failover if more than # number of watchdog tags have Bad Quality or Any Error. If one watchdog tag is configured set /wq=0. If more than one watchdog tag is configured, then # can be set from 0 to the number of watchdog tags configured minus 1 (/WQ=#).
· Failover if Server Leaves RUNNING State – (/WS=1).
Server-Level Failover Configurations
These are the server-level failover options supported by the interface. This section does not deal with timing of failover at all, only with how failover is triggered. See the section Controlling Failover Timing for timing considerations.
Inactive Server Does not Allow Connections
Use the /BACKUP parameter to provide the name of the other OPC server. If the interface cannot connect to one server, it will try the other one. The selection of which server is active is completely managed by the servers.
/SERVER=OSI.DA.1 /BACKUP=othernode::OSI.DA.1
Inactive Server Leaves OPC_STATUS_RUNNING State
Use the /WS parameter to control this. After the interface is connected to a server and collecting data, the server’s state is checked every 30 seconds. With the /WS flag set, if the server leaves the RUNNING state, the interface will disconnect from the current server and try to connect to the other server.
/WS=1
Inactive Server sets Quality to BAD
Some servers indicate only that they are not the active server by setting the quality of some, or all, their items to BAD. This can be used to trigger the failover of the interface to the other server, but the quality of the tag being used for a watchdog must be bad only when the interface should failover.
/WQ=# directs the interface to failover to the other server if more than # number of watchdog tags have Bad Quality or Any Error. Note that v1.0a servers do not return error codes for individual items, so for version 1.0a servers this parameter only checks the quality of the value sent from the server.
If one watchdog tag is configured, set /wq=0. If more than one watchdog tag is configured, then # can be set from 0 to the number of watchdog tags configured, minus 1.
/WQ= to the number of watchdog tags minus 1.
Watchdog Tags
For server-level failover, a specific PI tag can be defined as a watchdog tag. The OPC item that this tag reads must have a specific, known value when the server is able to serve data and another specific, known value when the server is unable to serve data. It is called a watchdog tag because its value changes to announce a change in the server status.
The remaining configuration options use Watchdog tags. Watchdog tags allow the OPC servers to notify the interface which server is the currently active server. If the value of the watchdog tag representing a server is greater than zero, that server is the active server. There are two different modes for using watchdog tags: isolated mode and server-specific mode. In isolated mode, each server knows only its own state. The items being used for these watchdog tags represent the current state of the server (such as backup state or active state). These items could have different values for the two servers at any given time. In server-specific mode, both servers know the state of the other server. Because of this, the items being used for the watchdog tags should match. In general, server-specific watchdog tags are a more robust failover model.