High Availability User Guide

High Availability User Guide
11/30/2006
© 1992-2006 OSIsoft, Inc. All rights reserved

OSIsoft, Inc. OSIsoft Australia
777 Davis St., Suite 250 Perth, Australia
San Leandro, CA 94577 USA Auckland, New Zealand
(01) 510-297-5800 (main phone)
(01) 510-357-8136 (fax) OSI Software GmbH
(01) 510-297-5828 (support phone) Altenstadt, Germany
support@osisoft.com
OSI Software Asia Pte Ltd.
Houston, TX
Johnson City, TN Singapore
Mayfield Heights, OH
Phoenix, AZ
OSIsoft Canada ULC
Savannah, GA Montreal, Canada
Seattle, WA
Yardley, PA OSIsoft, Inc. 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
Sales Outlets/Distributors
Brazil South America/Caribbean
Middle East/North Africa Southeast Asia
Republic of South Africa South Korea Taiwan
Russia/Central Asia
www.osisoft.com
OSIsoft, Inc. is the owner of the following trademarks and registered trademarks: PI System, PI
ProcessBook, Sequencia, Sigmafine, gRecipe, sRecipe, and RLINK. All terms mentioned in
this book that are known to be trademarks or service marks have been appropriately
capitalized. Any trademark that appears in this book that is not owned by OSIsoft, Inc. is the
property of its owner and use herein in no way indicates an endorsement, recommendation, or
warranty of such party's products or any affiliation with such party of any kind.
RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in

subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at
DFARS 252.227-7013
Table of Contents
Chapter 1: About this Manual....................................................................................................1
Introducing HA................................................................................................................................3
Chapter 2: High Availability Explained.....................................................................................5

Planned Maintenance ................................................................................................5
Unplanned Failure .....................................................................................................6
Benefits of High Availability and Platform Release One (PR1) .................................6
High Availability Architecture .....................................................................................7
Chapter 3: Overview of Product Behavior .............................................................................11

Level 1 Implementation............................................................................................11
Initial Connection .....................................................................................................13
Transition to a New Collective Member...................................................................15
Application Behavior with HA .....................................................................................................17
Chapter 4: Control Monitor......................................................................................................19
Chapter 5: DataSheet Control .................................................................................................21

Chapter 6: OSIsoft Developer Network ..................................................................................23

Chapter 7: OSI OPC Server......................................................................................................25

Chapter 8: PI Advanced Computing Engine (PIACE)............................................................27

High Availability User Guide Page iii

Contents
Chapter 9: PI ActiveView .........................................................................................................31
Chapter 10: PI AlarmView ..........................................................................................................33
Chapter 11: PI Analysis Framework (AF) .................................................................................35

Behavior When Connected to Primary ....................................................................36
Behavior When Connected to Secondary ...............................................................37
Chapter 12: PI BatchView ..........................................................................................................39
Chapter 13: PI DataLink .............................................................................................................41

Chapter 14: PI Manual Logger...................................................................................................45

Sending Archive Data ..............................................................................................45
Chapter 15: PI OLEDB ................................................................................................................47

Transition to a New Collective .................................................................................47
Chapter 16: PI ProcessBook .....................................................................................................49

Troubleshooting .......................................................................................................52
Chapter 17: PI ProfileView .........................................................................................................55
Chapter 18: PI SQC.....................................................................................................................57

Chapter 19: PI System Management Tools (SMT)...................................................................59

Page iv
Chapter 20: RLINK ......................................................................................................................61
Chapter 21: RtReports................................................................................................................63

PI Server Connection...............................................................................................63
RtReports Generator ...............................................................................................64
RtReports Editor ......................................................................................................70
Chapter 22: RtWebParts ............................................................................................................73

Chapter 23: Sigmafine................................................................................................................77

DataLoader Behavior When Connected to Primary ................................................77
DataLoader Behavior When Connected to Secondary ...........................................77
Appendix A: Glossary..................................................................................................................79
automatic connection (failback) ...............................................................................79
failover .....................................................................................................................79
connection preference .............................................................................................79
collective ..................................................................................................................80
HA server .................................................................................................................80
Level 1 .....................................................................................................................80
Level 2 .....................................................................................................................80
Level 3 .....................................................................................................................80
non-replicated PI Server ..........................................................................................80
primary server ..........................................................................................................80
secondary server .....................................................................................................81
Appendix B: Technical Support and Resources ......................................................................83

Before You Call or Write for Help ............................................................................84
Index ..............................................................................................................................................87
High Availability User Guide Page v

Chapter 1: About this Manual
This manual introduces OSIsoft's High Availability (HA) platform and describes what typical
users of our client and server products can expect when they upgrade their PI Systems.
Chapter 2 explains how HA works.
Chapter 3 presents a general overview of the differences in client product behavior for:
Initial connection to an HA PI Server, and
During transition to a secondary server following planned or unplanned loss of

connectivity
Subsequent chapters offer a product-by-product description of HA-related behavior exhibited
within each OSIsoft product. Use these remaining chapters as a reference guide to finding out
more specific information on how HA affects the applications you use.
If you are an advanced user that writes data to PI Server, or you manage your applications'
configuration settings, be sure to read the High Availability Advanced User Guide. It serves as
a compendium to this manual.
High Availability User Guide Page 1

Part I
Introducing HA
The chapters in Part I provide an introduction to the basic concepts surrounding High
Availability:
High Availability Explained
Overview of Product Behavior

Chapter 2: High Availability Explained
At OSIsoft we understand that uninterrupted access to data is a serious concern for our users.
That's why we've expanded our products to provide a feature called High Availability(HA).
This new offering enhances the reliability of PI Servers by providing you with an alternate
source of time-series data without requiring special hardware or clustered environments.
Here's how it works.
In the traditional PI System data is collected at an interface node and transmitted to a listening
PI Server where the user community can access it. Even in this simple configuration there are a
number of possible scenarios, both planned and unplanned, that could trigger data loss or
render data inaccessible.
Planned Maintenance
Operating System Updates
Software Upgrades
Hardware Upgrades
Reconfiguration
Unplanned Failure
Software Failure
Hardware Failure
Network Failure
Human Error
Planned Maintenance
So what happens when an administrator takes down a PI System for planned maintenance
without having an HA system?

Taking an interface node down for service prevents data from being gathered from its source
and creates a gap in data stored that may not be acceptable. Although OSIsoft interfaces buffer
data collected when a PI Server is unavailable, that data is not available to clients while the PI
Server is down for maintenance. While the circumstances of planned maintenance can be
controlled, the impact can be minimized but not eliminated entirely.
Unplanned Failure
While occurring infrequently, unplanned downtime represents a greater risk.
Even under the best circumstances there are times when hardware, software, or networks fail.
Any of these scenarios can bring down a system momentarily or until such time as the failure is
detected and repaired. This downtime could last several hours.
Generally, exposure is similar to that of planned maintenance, with a couple of exceptions.

Any failure bringing down an interface node can cause a loss of data. A failure of the PI Server
could also result in loss of any data that had not been previously backed up. There may be
permutations of either or both of these failure modes that can also have serious impact on the
system's ability to store and recover data for users.
Benefits of High Availability and Platform Release One (PR1)
OSIsoft has announced a timeline for releasing several key features implemented as platform
releases to enhance its product line. The first release in this schedule involves creating an HA
PI System, and is referred to in the timeline as Platform Release One (PR1).
As a result, if you use the PI System and upgrade to the HA version of our PI Server, PI SDK,
and client products you can generally expect:
Availability—A seamless connection and failover capability to replicated servers without

experiencing changes to your displays, spreadsheets, and portal pages.
Scalability—As more servers are available to satisfy the storage, retrieval, and computing
load.
PI System Administrators working with an HA system have the additional benefits of:
Reliability—You can expand your PI System to include one or multiple backup servers (a
collective) that handle data synchronization in the event of a failover situation. Moreover,
PI System administrators who choose to run a server collective have the option of running
machines of varying type, such as a laptop or desktop, or of varying processing capability,
such as running a 32-bit OS on one secondary node and a 64-bit OS on another.
Page 6
High Availability Architecture
Ease on Maintenance—Having HA facilitates maintenance of your system. You also

have the ability to troubleshoot offline, thus giving you time to analyze and diagnose what
is wrong without adversely affecting users.
Disaster recovery—Having the option to house PI Servers in different locations ensures
your data is protected in the event of a catastrophe and data can be located closer to the
users accessing it.
Quality of service—Demands on individual servers are reduced by distributing user
connections to a group of servers.
For more details on HA concepts and features, see the High Availability and PI Server
Replication manual.
The PI System already includes features that facilitate making data highly available. These
include the ability to conduct online backups, compatibility with Microsoft Clustering
technology, the distributed nature of data collection within the PI System, and the availability
of fault-tolerant third-party solutions that provide redundant hardware solutions.
Now, with the development of our HA PI System, OSIsoft is introducing a new architecture
with built-in features that specifically address the issue of data availability during planned and
unplanned downtime.
These features are visible at three levels, as described in the following sections.
PI Servers
Interfaces
PI SDK
PI Servers
The HA design provides multiple PI Servers that each act as independent storage and a source
for time-series data. These PI Servers function as a unit described as a collective. A collective
has two types of servers:
Primary—The main server in a collective where configuration changes are made. By

default, this is the only server that accepts non-buffered data.
Secondary—The remaining servers in a collective. These servers automatically adopt
configuration changes made on the primary.

In the PR1 release of High Availability, within a collective, configuration changes are allowed
on only the PI Server designated the primary. The other PI Servers in the collective are
designated as secondary and do not allow configuration changes, but do receive changes from
the primary.
PI Replication keeps the configuration databases consistent on the servers. Any change made to
the primary PI Server configuration is moved to the secondary PI Servers in real time,
according to a fixed schedule, or on demand. The figure below shows this overall architecture
of a collective consisting of two member servers.
HA Architecture
PI Server Replication
PI Server replication is one of the core concepts behind High Availability in PR1. It allows
redundant PI Servers, including a primary and one or more secondary servers, which together
are referred to as a collective. The PI Server point database, module database, user database,
trust table, and most of the configuration tables are replicated across the collective.
Additionally,
Interface buffering service writes time-series data directly to all members of the collective,
buffering data temporarily for those unable to receive data for a period of time and assuring
that time-series data stored in each archive is an exact duplicate of the others.
Any SDK-based PI client (for example, PI ProcessBook, PI DataLink) can automatically
switch from the primary PI Server to any of the replicated servers in the event connection
to the primary is unavailable, assuring that all clients always have read-access to PI data.
Page 8
Interfaces
Interface-level failover allows you to install redundant copies of an interface on separate

interface computers. This provides uninterrupted collection of process data even when one of
the interfaces is unable to collect data for any reason. Interface node maintenance—such as
hardware upgrades, security updates, and software installs—can occur without loss of data
because the redundant node automatically collects and sends data to the PI Server. Moreover,
in the event of a hardware, network, or software fault, interface level failover prevents the loss
of data, as the redundant node detects when the primary nodes fail and begins to send data to
the PI Server.
Interface nodes are configured to make use of a buffering service. All interfaces that write data
to the PI System can make use of this service. The buffering service queues the data
independently to each PI Server in a process called n-Way buffering. Each PI Server receives
the same data from the interfaces and performs its functions independently.
PI SDK
The PI SDK, the data access layer used by OSIsoft applications as a programmatic interface to
the PI Server, is enhanced to treat the collective as one logical data source. When the PI Server
is shut down normally through the pisrvstop.bat batch file or shutting down the OS, the
PI SDK receives an early notification of shutdown and immediately connects to a secondary PI
Server. When the PI Server providing data becomes unresponsive because of hardware or
software problems, or unreachable because of network problems, the PI SDK connects to an
alternate PI Server after a short timeout period.
Applications that use the PI SDK can take advantage of the failover behavior on any computer
where the new PI SDK is installed. The new PI SDK is backward compatible with older
versions of the PI SDK.
Once you install an HA-aware PI SDK (typically when you upgrade to an HA-aware version of
a client application) you get failover behavior against any collective, regardless of whether you
are using an HA-aware version of an application. Applications using previous versions of the
PI SDK do not benefit from the failover behavior and continue to function as before.

Chapter 3: Overview of Product Behavior
This overview provides details of how High Availability is implemented and presents two
scenarios in which applications interact with a PI Server.
The first describes how OSIsoft applications behave upon initial connection to a secondary PI
Server in a collective. The second scenario describes how applications behave during and after
a server transition within a collective, whether due to planned maintenance or an unexpected
loss of connection.
For each scenario we describe the expected behavior for users with each of the following levels
of HA PI System implementation:
Level 1: HA PI Server, pre-HA PI SDK, pre-HA release client application
Level 2: HA PI Server, HA PI SDK, pre-HA release client application
Level 3: HA PI Server, HA PI SDK, HA-aware client application
In each scenario you gain availability benefits by connecting your PI System to greater levels
of the HA platform.
HA PI Server HA PI SDK HA Client
Level 1 x
Level 2 x x
Level 3 x x x
Note: If you upgrade to an HA PI SDK or client application without upgrading to an HA

Server, you do not receive any High Availability benefits and your applications
exhibit the same behavior as they did prior to your upgrade.
Level 1 Implementation
At Level 1, a server has been upgraded to an HA version, but there is no HA version of the
client or HA version of the PI SDK installed.

If you use applications to read data from the PI Server, complete the recommended upgrade
process, and make the existing server primary, these applications behave as they did before
connecting to an HA PI Server.
If the recommended upgrade procedure is not followed and the existing server is configured as
a secondary, applications are subject to the secondary's limitations as described in Limitations
of Secondary Servers (page 13).
If you use applications that write data to the PI Server you receive error messages from the PI
Server when you attempt to perform a prohibited operation, such as writing data to a secondary.
See the High Availability Advanced User Guide for more detail.
At Level 2, the PI Server and PI SDK have been upgraded to HA versions, but the client
application is not HA-aware. This situation occurs when you have installed at least one HA
client application (resulting in the HA PI SDK installation) but are running a pre-HA version of
another client application.
The HA PI SDK gives pre-HA applications a preference to connect to the primary PI Server. If
the primary is available, applications behave as they did before connecting to an HA PI Server.
If the recommended upgrade procedure is not followed and the existing server is configured as
a secondary, applications are subject to the secondary's limitations as described in Limitations
of Secondary Servers (page 13). See the High Availability Advanced User Guide for more
detail.
Because the application is not HA-aware, it may attempt operations that are not supported on
the secondary. In this scenario applications automatically reconnect to the primary unless the
primary is unavailable, in which case they fail and return error messages. If your application
writes data to the PI Server you receive error messages from the PI SDK when you attempt to
perform a prohibited operation.
At Level 3, a PI Server, PI SDK, and client application are all HA-aware. This will give you the
full benefits of the HA architecture and is the preferred mode of operation. As you deploy HA
there will likely be a progression through Level 1 and 2 until all clients achieve Level 3
behavior.
In general, you will not notice any change in your applications' behavior when connecting to a
fully HA PI System. However there are some limitations with the PR1 release, particularly if
you use applications that write data to the PI Server or make configuration changes.
Page 12
Initial Connection
Limitation of Secondary Servers
The limitations of secondary servers in a collective include:
Writing configuration data is not supported. This limitation includes:

• PI Point attributes
• Digital State Sets
• User and Group information
• Module Database modules, PI Aliases, PI Properties, and values
Reading and writing batch data is not supported in PR1.
Writing time-series data using the PI SDK is not supported by default.
Because of these limitations, applications that successfully connect to the primary server can
function as with earlier versions, but if they connect initially, or become connected after a
failover to a secondary server, they become subject to these limitations. In general, applications
that only read data from a PI Server are fully functional regardless of the connected member.
Note: The replication of PI Servers guarantees that any configuration changes made on
the primary are reflected on all secondary servers. For example, you cannot edit a
point on the secondary, but you can edit on the primary and it will be replicated.
At Level 3, when the primary is unavailable, applications may restrict users from performing
certain functions by disabling menu items. When the primary is available these features
become enabled.
Initial Connection
When you connect to an HA PI Server for the first time there is a one-time process where the PI
SDK discovers which servers are part of the collective. When configured correctly by your PI
Server administrator this connection is seamless. You will not notice any difference in
behavior.
At Level 3 and Level 2 HA implementation, you can confirm your connection to the server by
opening the PI Connection Manager. Once a connection is made you can view the member of
the collective to which you are connected. Double-click a collective name to bring up a list of
server members that belong to that collective. A green dot appears next to the server member of
the collective that you are connected to.

PI Connection Manager Dialog Box
Collective Member Information Dialog Box
Page 14
Transition to a New Collective Member
If you are using an HA PI SDK, and your computer does not find the server you wish to connect
to, it will eventually time out. This is the same behavior you see when connecting to pre-HA
versions of the PI Server. The default timeout is 10 seconds per server in the collective.
Contact your system administrator or see the High Availability Advanced User Guide for more
information.
At Level 3 and Level 2, there are several cases when an application may make a transition to a
new collective member.
Planned server shutdown (for example, for planned maintenance)
An unexpected loss of connection
You attempt to perform a function not supported on the secondary server (automatic
failover)
You initiate a member switch with the PI Connection Manager dialog box (see High
Availability Advanced User Guide)
During this transition, there is a period when an application is disconnected. Until a new
connection is established, the application's behavior is identical to pre-HA operation.
This duration of the transition is dependent on what causes unavailability. An unanticipated

loss discovered through a timeout takes longer to reconnect. A planned server shutdown,
automatic failover, or member switch results in a shorter transition period.
At Level 1, client applications only connect to individual PI Servers, therefore there is no

difference from pre-HA behavior.
Planned Shutdown
During a server shutdown all PI SDK connections are notified of the impending connection
loss and the PI SDK initiates a failover to another member in the server collective. This takes
the same time as it does when initially connecting to a server.
Unexpected Loss of Connection
Unexpected connection loss is only detected when your client application has to exchange data
with a server. When your application attempts to send or retrieve data to a server that is
unreachable, it continues to check until the configured timeout period expires. After timeout on
a particular call, the PI SDK verifies that the remote server is really unreachable, then the server

attempts to connect to another member within the collective. The default call timeout is 60
seconds.
Because this type of failover is initiated by a data request, applications that do not request data
frequently may be unaware of the server outage for some time. Some applications, such as PI
ProcessBook and RtWebParts, receive snapshot updates from the PI Server every few seconds.
As a result, if one of these applications is connected to a server that becomes unavailable it does
not take long for the PI System to detect the situation and initiate a failover.
Automatic Connection
If you failed over from a primary to a secondary, or you are connected to a secondary but
attempt an operation not supported on that server, the PI SDK attempts to connect to the
primary server provided it is available. This allows client applications unaware of restrictions
to continue to work properly when the primary server in a collective is available.
As a result, you are able to proceed with your operation, and any configuration changes
replicate to the secondary servers in your collective. Following an automatic connection event
you remain connected to the primary server.
Page 16
Part II
Application Behavior with HA

The following chapters provide details on how OSIsoft client products and application servers
are affected when used within an HA environment:
Control Monitor
DataSheetControl
OSIsoft Developer Network
OSI OPC Server
PI Advanced Computing Engine
PI ActiveView
PI AlarmView
PI Analysis Framework
PI BatchView
PI DataLink
PI Manual Logger
PI OLEDB
PI ProcessBook
PI ProfileView
PI SQC
PI System Management Tools
RLINK

RtReports
RtWebParts
Sigmafine
Page 18
Chapter 4: Control Monitor
Control Monitor uses the PI API to communicate with the PI System. In PR1, there is no HA
support for applications that use the PI API, therefore there is currently no Level 3
implementation.
At Level 2 and Level 1, Control Monitor continues to work as it has in the past. You should
have no problem running the application once you upgrade to an HA PI Server. However,
because Control Monitor does not use the PI SDK, if the primary server in your collective
becomes unavailable, you have to manually connect to a secondary PI Server.

Chapter 5: DataSheet Control
Until the PI Server supports Batch Database failover, there is no Level 3 implementation for
DataSheet Control. See the chapter on BatchView (page 39) for more details.
At Level 2, the DataSheet Control connects to the primary PI Server and operates normally,
however some operations are limited.
At Level 1, the DataSheet Control connects to individual servers, not the collective. Therefore,
when an individual server goes down the application has no concept of failover. Once the
server returns, the client connects to the original server. From the perspective of client
behavior, this is the same as when connected to a pre-HA server.
Initial Connection
You can expect no difference in behavior in DataSheet Control when you initially connect to an
HA PI Server. This holds true for all three levels of HA implementation.
Because the DataSheet Control columns are generated from the Batch Database and batch
searches are disabled on secondary PI Server nodes, a transition away from the primary server
in the collective results in an error returned from the server.
When the DataSheet control is in Run mode (as opposed to Build mode) and the primary server
is lost, no new batches update in the grid. If a Refresh is initiated from the right-click menu, the
following error appears in the DataSheet space:
[-16030] Batch database access disabled on secondary server of
collective
You get the same error when you move from Build mode to Run mode.

Chapter 6: OSIsoft Developer Network
There are many OSIsoft Developer Network(OSIDN) applications available for download that
work with a broad spectrum of OSIsoft’s product line. For specific add-ins that work with
products such as Datalink or ProcessBook please review those client sections in this manual for
understanding and HA limitations.
In general, most OSIDN applications rely on whether or not client applications like
ProcessBook can handle HA. OSIDN applications related to server configuration like writing
tags, annotations, or other configurations are not compatible with HA.
Applications that do not belong to a client, such as the “Desktop Mini-view” control, do not
work with HA unless you rebuild and compile them against HA-compliant versions of the PI
SDK and write them to handle these new scenarios.
At Level 1, applications are not aware of the collective. When an individual server goes down,
the application has no concept of failover and disconnects. Once the server returns, the client
and application connects to the original server. From the perspective of client/application
Initial Connection
If you use OSIDN applications that use ProcessBook and DataLink you can expect no
difference when initially connecting to an HA PI Server. This holds true for all three levels of
HA but does not extend to applications that write or configure server data or information.
At Level 3 and Level 2, you have the added advantage of connecting to an HA PI SDK, which
allows you to failover to a secondary server in the event the primary server becomes
unavailable.
If you use ProcessBook add-ins and VBA you may notice some change in behavior for these
tools. See the ProcessBook chapter of the High Availability Advanced User Guide for more
details.

Chapter 7: OSI OPC Server
The current version of the OSI OPC Server does not support HA PI Server. This means that
Level 3 HA implementation is not currently applicable. This chapter summarizes the expected
behavior of the OPC Server at Level 2 and Level 1. See the High Availability Advanced User
Guide for more details.
At Level 2, the OPC Server connects to a collective. It is important to give a collective the same
name as the primary PI Server. This prevents you from losing some of the functionalities when
failing over to another member.
At Level 1, the OPC Server connects to individual PI Servers, not the collective. When an
individual PI Server within the collective goes down, the OPC Server is not able to fail over.
Once the original PI Server returns, the OPC Server connects to it and the data flow is restored.
It any case you will see some changes in the behavior and data flow during a failover. See the
High Availability Advanced User Guide for more details.
Initial Connection
At Level 2 and Level 1, if a collective name is the same as the primary, and OPC Server is
connected to the primary, you can expect no difference when initially connecting to an HA PI
Server for the purpose of browsing, deleting, and editing PI tags or reading and writing data.
At Level 2, since OPC Server is connecting to a collective through an HA PI SDK, a failover to

another member of a collective should happen automatically. However, some of the
functionalities of the OPC Server stop working while a primary server is unavailable. These
functionalities include advises, writes, point edits, and deletes. All data reads continue to work.
When your connection fails over to a new collective member, write and advise operations,
point updates, and deletes for both Data Access(DA) and Historical Data Access(HDA) stop
working. Provided your primary server and collective have the same name, OPC services begin
working again once the connection to a primary server is restored.

OSI OPC Server
Planned Shutdown
During a planned shutdown the OPC Server fails over to a new collective member. However, at
Level 1 you get an error indicating that a PI Server is unavailable. At this point all OPC Clients
connected to the OPC Server should wait until the PI Server connection is restored or
disconnect from OPC Server.
Page 26
Chapter 8: PI Advanced Computing Engine
(PIACE)
Advanced Computing Engine consists of three components:
Wizard
Manager
Scheduler
Their connection and failover behavior differ and are described in detail below.
Initial Connection
ACE initially connects to a collective member as follows:

Wizard Manager Scheduler
Level 3 primary only primary if available and primary only
secondary otherwise
Level 2 primary if available and primary if available and primary if available and
secondary otherwise secondary otherwise secondary otherwise
Level 1 primary only primary only primary only
Wizard and Scheduler
The Wizard and Scheduler both write data to the Module Database and therefore are only
useful when connected to the primary server. For this reason at Level 3, where you have an
HA-aware version of ACE installed, the Wizard and Scheduler are restricted to only connect to
a primary PI Server.
At Level 2, when you attempt to modify the Module Database, both the Wizard and Scheduler
return an SDK-generated error message informing you that you can not perform that operation.
At Level 1, ACE connects to individual servers, not the collective, therefore there is no HA
benefit to either the Wizard or Scheduler.

PI Advanced Computing Engine (PIACE)
ACE Manager
At Level 3 and 2, when you initially connect with a primary server in a collective, ACE
Manager behaves as it did prior to your HA upgrade.
At Level 3, when you connect to a secondary server in a collective, ACE Manager

automatically generates a pop-up message warning you that only read operations are permitted.
ACE Manager warning message at Level 3
Moreover, any menu item that would normally allow you to write data to the Module Database
is grayed out.
ACE Manager at Level 3. Unsupported menu items are grayed out.
At Level 2, when you connect to a secondary server in a collective, you do not have the
enhanced user interface that comes with an HA version of ACE Manager, however you are still
Page 28
prohibited from performing operations that modify the Module Database. All menu items
appear as normal, but any attempt to perform a write operation generates a pop-up error, and
the write attempt fails.
ACE Manager menu at Level 2
Error message when you select a prohibited menu item in Ace Manager at Level 2
The behavior for both planned shutdown and unexpected loss of connection is identical and is
summarized in the following table.
Level 3 no transition automatic transition no transition
Level 2 automatic transition automatic transition automatic transition

PI Advanced Computing Engine (PIACE)

Level 1 no transition no transition no transition
ACE Wizard and ACE Scheduler
At Level 3, ACE Wizard and Scheduler are required to connect to a primary server, therefore
there is no possibility for a transition to a new collective member.
At Level 2, ACE Wizard and Scheduler prefer connecting to a primary server. When the
primary server becomes unavailable, the HA SDK attempts an automatic transition when the
Wizard and Scheduler try to read updates to ACE calculations.
ACE Manager
At Level 3, when you make a transition to a secondary server, a message pops up informing
you that you are only able to perform read-only operations. The ACE Manager screen refreshes
and any menu item that normally allows you to perform write operations is disabled.
At Level 2, you have not upgraded to the HA-aware ACE Manager, therefore the user interface
appears the same despite your having made a transition to a secondary server. However write
operations are still prohibited. Any attempt to perform a write operation generates an error
message and fails.
Page 30
Chapter 9: PI ActiveView
HA behavior in PI ActiveView resembles that for PI ProcessBook. See the chapter on PI

ProcessBook (page 49) for details.

Chapter 10: PI AlarmView
At Level 3, AlarmView is HA-aware, as is the PI Server and the PI SDK. Due to the distinct
possibility of different alarm processing in primary and secondary servers, AlarmView only
connects to the primary server of a collective. When you choose a collective, you connect to the
primary. The HA-aware version of AlarmView released with PR1 has a built in connection
preference (page 79) of RequirePrimary, therefore if the primary server is unavailable, the
collective is unavailable.
At Level 2, AlarmView attempts to connect to the primary node in a collective because it is

unaware of HA logic. When the server fails to a secondary node, AlarmView functions
normally, except that you get errors when you attempt to write to the PI Server. These errors
occur on acknowledgement, commenting, adding reason codes, and adding extra information.
At Level 1, AlarmView and the PI SDK are not HA-aware. You may connect to a secondary
node, but receive error messages when attempting operations that are not allowed on the
secondary node. These operations include acknowledgements, commenting, adding reason
codes, and adding extra information. When you are connected to the primary server in a
collective AlarmView behaves normally.

Chapter 11: PI Analysis Framework (AF)
PI Analysis Framework connects to a PI Server by two distinct mechanisms.
The PI Analysis Framework Server (PI AF Server) makes a connection to the PI System in
order to store and retrieve data in the Module Database.
PI Analysis Framework Client applications (AF Clients), using the AF SDK, make
connections to the PI System through the PI Point Data Reference to read and write archive
data.
The PI AF Server does not currently support multiple instances of itself running against the
same collective. For this reason, at all three levels of HA, it is possible to have only one PI AF
Server running against the collective.
Caution: Do not install or enable the PI AF Server on the same computer as a secondary
PI Server.
At Level 3 and Level 2, you see some differences in the behavior of basic components of the
application during a failover or while connected to the secondary. The behavior change for the
client application can be dependent on the hosting application.
At Level 1, the Analysis Framework Server and Clients connect to individual servers, not the
collective. When an individual server fails, the application has no concept of failover. After the
server returns, the client connects to the original server. From the perspective of client
Initial Connection
Basic users of Analysis Framework can expect no difference when initially connecting to an
HA PI Server. This holds true for all three levels of HA.
At Level 3 and Level 2 you have the added advantage of connecting to an HA PI SDK, which
allows you to fail over to a secondary server in the event that you lose connection to the
primary server. However, the Analysis Framework has limited capabilities when connected to
the secondary.

PI Analysis Framework (AF)
In order to support failover at Level 3 or 2, the PI AF Server must reside on a computer other
than the PI Server.
The following sections describe what happens after a connection is lost and a new member is
connected. At Level 3 and Level 2 you experience only a momentary disruption of
communication when connection to a PI Server is lost. When connected to a secondary, there is
loss of functionality until the primary becomes available again.
Planned Shutdown
At Level 3 and Level 2, if a failover is initiated before a connection timeout occurs, no

indications of the change in collective members are seen in either the Analysis Framework
Server or Client. This is the same behavior seen when a network connection experiences an
outage of such short duration that it is not detected during an update poll. If the PI AF Server
resides on the same computer as the PI Server being shut down, it also shuts down, resulting in
complete loss of AF functionality.
At Level 3 and Level 2, when a new member connection is established during a failover, all
data is retrieved using the new connection. This is similar to existing behavior when a
connection is lost and then re-established, but is no longer dependent on connecting to the
original server.
Behavior When Connected to Primary
At all three Levels, the PI AF Server has full functionality.
For the non-SQL version of the PI AF Server, AF Cases, and AF Transfers are stored only in
the primary PI Server.
For AF clients, the default behavior for writing values through the PI Point Data Reference is to
write the values only to the primary. You can not configure an AF client, including the
AF-ACE analysis scheduler, to publish values to both the primary and its secondaries.
Page 36
Behavior When Connected to Secondary
Behavior When Connected to Secondary
At Levels 3 and 2, the PI AF Server automatically attempts to reconnect to the primary if an

unsupported operation occurs.
The PI AF Server has limited functionality when connected to a secondary. For both the SQL
and non-SQL versions of the PI AF Server, when the PI AF Server is connected to a secondary
you can not create or remove databases, or modify the UOM database in any way. Additionally,
for the non-SQL version, you can not retrieve, create, or modify AF Cases and AF Transfers.
For AF clients, the default behavior for writing values to a secondary is to attempt to failover to
the primary. If that fails, the write fails. The hosting application can modify the connection via
the PI SDK to allow writes to occur to the secondary. You can not configure the AF-ACE
analysis scheduler to allow writes to a secondary.

Chapter 12: PI BatchView
At Level 3, PI BatchView supports connecting to collectives. However, due to limitations for

batch data on the PI Server it is likely that whenever BatchView is used, the connection is to the
primary. If you use an HA-aware version of BatchView in ProcessBook you must also use an
HA-aware version of ProcessBook.
Note: For the PR1 release we highly recommend that you do not operate BatchView on a
secondary server, however there is a way to configure your PI Server to make this
possible. See the High Availability and PI Server Replication guide for more details.
At Level 2, BatchView connects to the primary PI Server and operates normally. However, if
you are running an HA-aware version of ProcessBook or another Excel add-in, then the
connection may be to a collective member that does not support batch data access. The PI SDK
automatically attempts to switch the connection to a collective member that supports batch data
access. However, if such a collective member is not online, the error messages and behaviors
are not as clear as in BatchView at Level 3.
At Level 1, the BatchView connects to individual servers, not the collective. Therefore, when
an individual server goes down the application has no concept of failover. Once the server
returns, the client connects to the original server. From the perspective of client behavior, this is
the same as when connected to a pre-HA server.
See the High Availability Advanced User Guide for more details.

Chapter 13: PI DataLink
At Level 3 and Level 2, there are some differences in the behavior of basic components of the
application during a failover. If you are a more advanced user, you may also notice changes,
particularly with regard to connection settings and permitted behaviors. These changes are
documented in the High Availability Advanced User Guide.
At Level 1, DataLink connects to individual servers, not the collective. When an individual
server goes down, the application has no concept of failover. Once the server returns, the client
connects to the original server. From the perspective of client behavior, this is the same as
when connected to a pre-HA server.
Initial Connection
At Level 3 and Level 2, you have the added advantage of connecting with the HA PI SDK,
which allows you to fail over to a secondary server in the event the primary server becomes
unavailable.
At Level 1, there is no change in how DataLink connects to an HA server. The DataLink

function connects to the server as if it was a standalone server.
Contact your system administrator or see the High Availability Advanced User Guide for more
information.
connected at Level 3 and Level 2 implementation. There is only a momentary disruption of
communication when your connection to a PI Server is lost.
All DataLink read calls to the collective first attempt to connect to the primary. If that does not
succeed, DataLink then attempts connection to a secondary server. Retrieval of data ensues
normally assuming that the connection can be made successfully to one of the members of the
collective.
For information on DataLink write calls, see the High Availability Advanced User Guide.

PI DataLink
In the following two scenarios, there are subtle differences in how DataLink behaves:
Planned Shutdown
For DataLink function calls there is no disruption of data flow. When you recalculate your
functions, DataLink automatically retrieves data from a secondary server. There are no visible
indications of the change in collective member seen in DataLink functions.
There is some difference in behavior with the trend control. See Unexpected Loss of
Connection (page 42) for more details.
For DataLink function calls, there is no disruption of data flow. When you recalculate your
functions, DataLink automatically retrieves data from a secondary server.
The trend control, however, behaves somewhat differently.
During a transition to a new collective member, if Enable Updates is set, then your trend
control momentarily enters a disconnected state. New snapshot data from the secondary are
plotted, but the data recorded up to that point are retrieved from the primary. At this point a gap
forms in the trend with an X denoting where DataLink lost its connection to a primary. Once
connection to a secondary is established, a second X on the trend display denotes where
DataLink made the transition to the new server.
After you perform a revert, both the archive data and the snapshot data come from the
secondary, and the gap in your trend display is no longer visible.
Transition to a New Collective Member in a DataLink Trend Control
Page 42

Chapter 14: PI Manual Logger
As of this writing, the latest version of PI Manual Logger is not HA-aware, therefore there is no
possibility for Level 3 implementation.
At Level 2 implementation some operations are limited when you are connected to a secondary
PI Server.
At Level 1, Manual Logger behaves as it did prior to connecting to an HA PI Server.
Initial Connection
At Level 2 and Level 1, all operations within Manual Logger behave normally when you
initially connect to an HA-aware PI Server.
At Level 2, most operations in Manual Logger that read data from the PI Server behave
normally.
You may notice a brief disruption in your display of archive data list and trend during the
transition period from one server to another. Trending data displays archive data from
whichever server you are connected to. Because there may be discrepancies between data on
the primary and data on the secondary, your trend may appear different after you make the
transition to a new collective member.
Sending Archive Data
While you can still view trends and perform most configuration operations in Manual Logger
when connected to a secondary PI Server, it is not recommended that you attempt to send
archive data to the PI System.

PI Manual Logger
After you make the transition to a secondary, if you attempt to send data to the PI Server your
operation fails and you receive the following server pop-up error:
Writing, editing, or removing time-series data on this collective
member is disabled.
The status of Tour Run changes from archived to completed in the Tour Run List View.
Note: The status bar on the Manual Logger screen incorrectly states Data
successfully sent to PI, even though all write operations attempted on the
secondary fail.
If the primary becomes available again, you are automatically reconnected (page 16) to the
primary, thus enabling write operations to work again—though you may notice a brief
interruption in performance during the time it takes to make the transition.
Page 46
Chapter 15: PI OLEDB
In combination with a PI SDK version that supports HA, PI OLEDB supports connection
failover to servers in an HA collective.
Initial Connection
At Level 3 and Level 2, it is preferable that you make a connection to the primary server of a
collective. Depending on how PI OLEDB is used, either the OLEDB application developer or
the end user has the ability to establish the connection preference to a collective. By default, PI
OLEDB connects to a collective with the connection preference of PreferPrimary. See the
High Availability Advanced User Guide for more detail.
At Level 1, PI OLEDB connects to individual servers, not the collective. When an individual
Additional options and their configuration are also described in the High Availability Advanced
User Guide.
Transition to a New Collective
Planned Shutdown
Because the PI OLEDB provider is not able to postpone a planned shutdown until a query is
finished, the behavior is the same as described in Unexpected Loss of Connection (page 48).

PI OLEDB
At Level 3 and Level 2 implementation, if you lose connection to a server you automatically
fail over to another member in the collective. The failover can be seamless if no query
execution is in progress.
If your server connection goes down in the middle of a data query you receive an error. This is
the same as pre-HA behavior. However, once you make the transition to another member of the
collective, your SQL query restarts.
Write Operations
In the PR1 release of HA, secondary servers have limited capabilities for write operations.
Connections also do not automatically fail over to the primary server. If the primary task of a PI
OLEDB application is to write data or perform a configuration, then a failover to a secondary
server is inappropriate. You should therefore configure the application to only make use of the
primary server by using the connection preference of RequirePrimary. For configuration
details see the High Availability Advanced User Guide.
Page 48
Chapter 16: PI ProcessBook
At Level 3 and Level 2, there are some differences in the behavior of basic components of
ProcessBook during a failover. If you are a more advanced user, you may also notice changes,
particularly within ProcessBook add-ins, VBA, and in regard to connection settings and
permitted behaviors. These changes are documented in the High Availability Advanced User
Guide.
At Level 1, ProcessBook connects to individual servers, not the collective. When an individual
Initial Connection
You can expect no difference in behavior in ProcessBook when you initially connect to an HA
PI Server. This holds true for all three levels of HA implementation.
At Level 3 and Level 2 you have the added advantage of connecting to an HA PI SDK, which
allows you to fail over to a secondary server in the event the primary server becomes
unavailable.
If you use ProcessBook add-ins and VBA you may notice some change in behavior for these
tools. See the High Availability Advanced User Guide for more details.
connected. At Level 3 and Level 2 there is only a momentary disruption of communication
when you lose connection to a PI Server.

PI ProcessBook
Planned Shutdown
If a failover is initiated before a connection timeout occurs, no indications of the change in

collective member are seen in ProcessBook displays. This is the same behavior seen when a
network connection experiences an outage of such short duration that it is not detected during
an update poll.
updating symbols on a ProcessBook display begin to show data from the new connection. This
is similar to existing behavior when a connection is lost and then reestablished, but is no longer
dependent on connecting to the original server.
Trend
At Level 3 and Level 2, in the event of a failover, data received up to that point by ProcessBook
is not discarded when a disconnection is detected. When you make a new connection current
values are plotted as they arrive. Consequently, traces in trends may show a gap for the period
during which the connection is lost. This behavior is identical to the case where a
non-replicated PI Server (page 80) is temporarily unavailable and then comes back online
while a display is open. An X marks the last good data point received and another X marks the
first good data point after reconnection, as illustrated below. Cursors in the gap show the
Disconnected message.
Trend during a failover period showing a gap when the connection was lost
Page 50
Any action to revert a display's time range results in a retrieval of displayed data from the
newly connected server for any symbols affected by the revert action. Afterward, no gap is
shown and the cursor no longer shows a Disconnected message. Annotations may not be
available on the new server depending on configuration. See the High Availability Advanced
User Guide for more detail.
XYPlot
At Level 3 and Level 2, in the event that a failover occurs, data received up to that point by
ProcessBook is not discarded when a disconnection is detected. When the new connection is
made, current values are plotted as they arrive. Consequently, there may be a gap in matched
points for the period during which the connection is unavailable. This behavior is identical to
the case where a non-replicated PI Server (page 80) is temporarily unavailable and then comes
back online while a display is open. An X on the plot axis marks the location of an unmatched
value when one of the expected pairs is a PI tag affected by a failover, as illustrated below.
XYPlot after failover
If both tags in a pair are affected by a failover, there may be an X at the 0 location of the plot, or
there may be no indication of missing data.
A ToolTip at the bottom left corner of the plot reports any disconnection messages, as
illustrated below. Note that the illustrated ToolTip does not show a failover or disconnection
message. The text used in the ToolTip depends on the circumstances reported by the PI Server.

PI ProcessBook
ToolTip at beginning of plot for missing data pairs
Troubleshooting
Because of limitations on replication of data in the PR1 servers, some data is not available on
secondary PI Servers in a collective. Furthermore, if you use VBA scripts or add-ins that rely
on the PI SDK and attempt to write data to a secondary member of a collective, you will
experience errors. You can review errors by opening the Status Report dialog box in
ProcessBook and clicking the Message Log button to review any recorded errors.
Status Report
The Status Report dialog box appears when you have a display in focus and you double-click
the Status icon located at the bottom of the ProcessBook window. In the event of
disconnection, if ProcessBook does not fail over to a secondary server, an error message
appears in the Status Report dialog. Typically, the message reads:
The requested server is not currently available. Primary.
Page 52
Troubleshooting
Check with your system administrator to make sure your PI System is configured correctly.
Note: To launch the Status Report dialog in PI ActiveView, click the Status icon on the PI
ActiveView toolbar.

Chapter 17: PI ProfileView
PI ProfileView uses the PI API to communicate with the PI System. In PR1, there is no support
for HA using the PI API.
ProfileView continues to work as it has in the past. You should have no problem running the
application once you upgrade to an HA PI Server. However, because ProfileView does not use
the PI SDK, if the primary server in your collective becomes unavailable, you have to manually
connect to another server. Since ProfileView displays are server-specific, you have to
configure displays for each server you plan on connecting to, even if they are part of a
collective.

Chapter 18: PI SQC
PI SQC functions entirely within ProcessBook, therefore the behavior of ProcessBook

regarding HA PI Servers and connections govern the behavior of SQC.
At Level 3 and Level 2, you may experience some differences in behavior during a failover.
You will also notice changes if you use VBA to write to the PI Server or perform other
advanced operations.
At Level 1, ProcessBook connects to individual servers, not the collective. When an individual
Initial Connection
Basic users of SQC can expect no difference when initially connecting to an HA PI Server.
This holds true for all three levels of HA.
At Level 3 and Level 2, you have the added advantage of connecting to an HA PI SDK, which
allows you to fail over to a secondary server in the event the primary server becomes
unavailable.
Some users of SQC (for example, those who use VBA to write values to the PI System) may
notice a change in behavior if the initial connection is to a secondary server in a collective. See
the High Availability Advanced User Guide for more details.
connected. At Level 3 and Level 2, you notice only a momentary disruption of communication
when connection to a PI Server is lost.

PI SQC
Planned Shutdown
If a failover is initiated before a connection timeout occurs, the SQC charts in ProcessBook
displays do not show any indication of the change in collective member. This is the same
behavior seen when a network connection experiences an outage of such short duration that it is
not detected during an update poll.
If you use VBA to write values to PI Server, you could see behavioral changes after failover.
Control charts configured to portray PI Server-based SQC Alarms could display differently
upon failover. See the High Availability Advanced User Guide for more details.
updating symbols on a ProcessBook display begin to show data from the new connection. This
is similar to existing behavior when a connection is lost and then reestablished, but is no longer
dependent on connecting to the original server.
SQC Charts
At Level 3 and Level 2, in the event that a failover occurs, data received up to that point by
ProcessBook is not discarded when a disconnection is detected. When the new connection is
made current values are plotted as they arrive. Consequently, traces in trends may show a gap
while the connection is lost. This behavior is identical to the case where a non-replicated PI
Server (page 80) is temporarily unavailable and then comes back online while a display is open.
An X marks the last good data point received and another X marks the first good data point
after reconnection. Cursors in the gap show the Disconnected message.
Page 58
Chapter 19: PI System Management Tools (SMT)
At Level 3, SMT provides an upgraded user interface that distinguishes between HA and
non-replicated PI Servers.
Level 2 and Level 1 are inappropriate for management of HA PI Servers.
At Level 2 or Level 1, HA PI Servers appear the same as non-replicated PI Servers. Only the
collective is visible, and there are no visual cues indicating whether you are connecting to a
primary or secondary server. Because the client is not HA-aware, and because the PI SDK may
not be HA-aware, the user interface does not provide role appropriate indications of actions and
tasks. You may well attempt tasks that cannot be performed on the server to which you are
connected. The resulting possibility of difficult to interpret error messages makes Level 2 and
Level 1 inappropriate for management of HA PI Servers.
Version 3.2.0.0 SMT enables management of HA PI Servers as well as non-replicated PI

Servers. PI SMT version 3.2.0.0 is delivered with the 1.3.4.3xx PI SDK. Features have been
added to the Host and plug-ins to provide an appropriate user interface for HA PI Server
management, and a new Collective Manager utility is provided to help you establish
collectives.
Initial Connection
At Level 3, you have the added advantage of seeing HA PI Servers differentiated from
non-replicated PI Servers and of being able to connect directly to a member server.
At Level 2 and Level 1, you see no difference in behavior when connecting to an HA PI Server
versus a non-replicated PI Server.
See the High Availability Advanced User Guide for more details.
At Level 3, connections in SMT are made to the collective's individual member servers rather
than to the collective itself. If a failover occurs and the HA PI Server is still on line, then you

PI System Management Tools (SMT)
can still use SMT to administer the server. If an HA PI Server is shut down, then the loss of
connection is handled in the same way as for a non-replicated PI Server.
Because the client is not HA-aware, and because the PI SDK may not be HA-aware,
implementation of HA PI Systems at Level 2 and Level 1 is inappropriate for management of
HA PI Servers. Level 2 and Level 1 connections are made to the collective. In the event of a
server failover, non-replicated PI Servers behave differently than PI Servers in a collective.
At Level 2, error messages are generated by the HA-aware PI SDK, but the client (Host and
Plug-ins) is not HA-aware, so the user interface does not reflect distinctions between primary
and secondary collective members. Those distinctions are essential for management of HA PI
Servers.
At Level 1, you may receive ambiguous error messages because neither the PI SDK nor the
client is designed with HA in mind.
SMT Host and Plug-ins
At Level 3, SMT provides an upgraded user interface that distinguishes between HA and
non-replicated PI Servers. SMT visually indicates the organization of HA PI Servers into
collectives and the roles of the servers within collectives. Plug-ins have been redesigned to
provide the user interface that is appropriate for the server/role being administered. In addition,
a new Collective Manager utility is provided to simplify the task of administering collectives.
Implementation of HA PI Systems at Level 2 and Level 1 is inappropriate for management of

HA PI Servers with SMT.
Page 60
Chapter 20: RLINK
There is no benefit in upgrading to any level of HA implementation because RLINK is largely

a PI API-based application with only a limited use of PI SDK for calls not available in the PI
API, such as the creation of PI Modules and PI Points.
Because there is no HA version of RLINK, there is no Level 3 implementation.
At Level 2 and Level 1, RLINK connects to individual servers, not the collective. When an
individual server goes down, RLINK does not fail over to another member of the collective.
Once the primary server becomes available, RLINK automatically reconnects to the original
server. From the perspective of client behavior, this is the same as when connected to a pre-HA
server
At Level 2, BUFSERV must be turned off on the RLINK server. During a loss of connection, if
you are using the RLINK add-in for ProcessBook, tag creation returns an error. If you are using
PMConfigure, attempts to create new PI Modules fail and return an error.
Initial Connection
You can expect no difference when initially connecting to an HA PI Server. This holds true for
all three levels of HA.
RLINK does not fail over to a new member of the collective. When you lose connection to the
primary PI Server, RLINK continues to poll for a PI connection until it is successfully
reestablished with the primary server. No user intervention is required in RLINK to reestablish
the PI connection.
After you reconnect to the primary PI Server, RLINK resumes the event detection and the
two-way conversation between the PI and ERP systems.
RLINK's primary design goal is no data loss. It runs as a Windows service, polls the PI Server
for certain configured events (that are relevant to the ERP system), and upon detection of such
events, initiates a two-way conversation between the PI System and ERP system. As part of the

RLINK
two-way conversation, RLINK sends PI data to the ERP system and writes ERP data to the PI
system.
When you lose connection to a PI Server, the detection of the events may be delayed, but the
RLINK polling architecture ensures that no event is lost. After you reconnect to the PI Server,
RLINK automatically and without user intervention resumes the event detection and the
two-way dialog with the ERP system. The data may arrive at the ERP system at a later time, but
the PI data values and the associated timestamps transmitted to the ERP system are the same as
had there not been a loss of connection to the PI Server.
Page 62
Chapter 21: RtReports
At Level 3 and Level 2, in both RtReports Generator and RtReports Editor there are
differences in the behavior of basic components of the application during a failover.
At Level 1, the RtReports Generator and RtReports Editor connect to individual servers, not the
collective. When an individual server goes down, the application has no concept of failover.
Once the server returns, the client connects to the original server. From the perspective of client
The RtReports application is comprised of the RtReports Server, the RtReports Generator, and
the RtReports Editor. The RtReports Server is the main component of the RtReports
application. The RtReports Server is responsible for managing report templates and executing
generated reports.
The RtReports Generator is a web application served by the RtReports Server. You connect to
and view web pages in the RtReports Generator through an Internet web browser. For this User
Guide, we refer to the web pages generated by the RtReports Server as the RtReports Generator
Search and Report Viewer pages.
The RtReports Editor is a smart client application that allows you to gain access to and visually
build Report Templates. The RtReports Editor connects to the RtReports Server through a
series of web services. All report template operations, such as save and delete, are sent to the
RtReports Server and executed by the RtReports Server.
PI Server Connection
There are two different types of PI Server connections that the RtReports application
establishes. The main connection is to the RtReports Template PI Server. This is the PI Server
that stores all RtReports Report Templates and associated data, such as compliance workflow
and electronic signatures. Subsequent connections are made to other PI Servers called Data
Servers that Report Templates can be executed against.

RtReports
RtReports Generator
Initial Connection
At Level 3, the RtReports Generator, by default, attempts to connect to the primary server in a
collective configured as the RtReports Template PI Server. The RtReports Template PI Server
is the PI Server configured to store RtReports Report Templates. When executing reports
within the RtReports Generator, the RtReports Generator writes report execution status
information to the RtReports Template PI Server's Module Database and this operation is only
permitted on the primary Server.
If the primary server is unavailable, the RtReports Server connects to a secondary server. When
the RtReports Server is connected to a secondary, the RtReports Generator is in read-only
mode. You are able to execute new reports and retrieve cached reports, but there is no
execution status information written to the RtReports Template PI Server.
At Level 2 and Level 1, when connected to the primary server configured as the RtReports
Template PI Server, the RtReports Generator and Server behaves the same as when connected
to a pre-HA server.
At Level 2 and Level 1, when connected to a secondary server configured as the RtReports
Template PI Server, you may experience problems due to the default operation of the
RtReports Server. When executing reports within the RtReports Generator, the RtReports
Generator writes report execution status information to the RtReports Template PI Server's
Module Database; however, this operation is not permitted on a secondary server and results in
errors. We do not recommend this configuration.
connected. At Level 3 and Level 2, you will notice only a momentary disruption of
communication when connection to a PI Server is lost.
Planned Shutdown
Level 3
At Level 3, if a failover is initiated on a collective configured as the RtReports Template PI

Server, no indications of the change in a collective member are seen in any RtReports
Generator Search or Report Viewer pages.
However, if the newly connected member is a secondary server and you attempt to execute an
operation through an instantiated RtReports Generator Search or Report Viewer page that is
Page 64
RtReports Generator
not supported on the secondary, an error message is displayed. The following list shows the
operations restricted based on the behaviors supported by the collective member.
In the RtReports Generator Batch Search page, executing a Batch search against any
collective member not configured to support reading batch data.
In the RtReports Generator Case Search page, executing a Case search against any
collective member that is configured as a secondary server.
In the RtReports Generator Report Search page, executing a Batch search against any
collective member not configured to support reading batch data.
In the RtReports Generator Report Search page, executing a Case search against any
collective member that is configured as a secondary server.
In the RtReports Generator Report Viewer page, executing any compliance workflow such
as entering comments or verifications while connected to a secondary server.
Note: If RtReports executes a report while the RtReports Server is connected to a

secondary server configured as the RtReports Template PI Server, no report status
information is written to the RtReports Template PI Server. This means no
compliance workflow may be initiated on the executed report and the report is not
inserted into the Report Cache. The Report must be re-executed when the
RtReports Server is connected to the primary server configured as the RtReports
Template PI Server.
Here is a list of operations that may result in errors based on the behaviors supported by the
currently connected member of the PI Server collective configured as the RtReports Data PI
Server:
In the RtReports Generator Batch Search Page and Report Search Page, executing a Batch
search against any collective member not configured to support reading batch data displays
the following error:
Error: Batch database access disabled on connected collective member
In the RtReports Generator Batch Search Page, executing a batch report template
generation request against any collective member not configured to support reading batch
data results in an error.
In the RtReports Generator Case Search page and Report Search Page, executing a Case
search against any collective member that is configured as a Secondary Server displays the
following error:
Error: Analysis Framework case access not permitted on connected
collective member
In the RtReports Generator Case Search page and Report Search Page, executing a case
report template generation request against any collective member that is configured as a
secondary server results in error.

RtReports
In the RtReports Generator Report Search Page, executing a batch report template
generation request against any collective member not configured to support reading batch
data results in an error.
In the RtReports Generator Report Search Page, executing a case report template
generation request against any collective member that is configured as a secondary server
results in error.
When the RtReports Server is connected to a secondary server configured as the RtReports
Template PI Server, any newly-instantiated RtReports Generator Report Viewer pages are in a
Read Only mode with red Read Only text appearing in the center of both the Header and Footer
menu bars. Comments, verifications, and approvals are shown, but no additional compliance
workflow operations can be performed. When the RtReports Generator Report Viewer is in
Read Only mode, the following operations are disabled:
Operation Description
Comment The Comment hyperlink implements the Comment dialog for entering
comments. When in Read Only mode, this link is disabled.
Verify The Verify hyperlink implements the Verification dialog for verifying report
sections. When in Read Only mode, this link is disabled.
Approve The Approve hyperlink implements the Approval Route functionality. When in
Read Only mode, this link is disabled.
Print The Print hyperlink implements Official Printing functionality. When in Read
Only mode, this link is disabled.
Note: You may Print the report using the Printers menu, but when the RtReports
Generator Report Viewer is in Read Only mode, Official Printing functionality is
disabled.
Since the RtReports Server and Generator prefer to be connected to the primary server of a
collective configured as the RtReports Template PI Server, the RtReports Server monitors the
PI Server collective for any change in member availability. When the primary server becomes
available, the RtReports Server and Generator enable all write operations. The first operation
not supported on a secondary server of the PI Server collective automatically switches
connection of the RtReports Server and Generator to the primary server of the collective. Once
this switch occurs, the RtReports Server and Generator behave as if initially connected to the
primary.
Level 2
At Level 2, if a failover is initiated on a collective configured as the RtReports Template PI

Server, no indications of the change in a collective member are seen in any RtReports
Generator Search or Report Viewer pages.
Page 66
RtReports Generator
However, if the newly connected member is a secondary server and you attempt to execute an
operation through an instantiated RtReports Generator Search or Report Viewer page that is
not supported on the secondary, an error message is displayed.
Since pre-HA versions of RtReports do not check the behaviors of a connected PI Server, the
following scenarios may occur during Level 2 operation.
In the RtReports Generator Batch Search Page, if you execute a Batch search against any
collective member not configured to support reading batch data you encounter the
following error:
Error during Batch Search: The target server database failed to
load.[-16030] Batch database access disabled on secondary server
of collective
In the RtReports Generator Case Search page, executing a Case search against any
collective member that is configured as a secondary server does not return any results. No
errors are generated, either written to the Windows Application Event Log or displayed on
the screen.
In the RtReports Generator Report Search page, executing a Batch search against any
collective member not configured to support reading batch data does not return any results.
An error is generated and written to the Windows Application Event Log, but no error
message is displayed.
In the RtReports Generator Report Search Page, executing a Case search against any
collective member that is configured as a secondary server does not return any results. No
errors are generated, either written to the Windows Application Event Log or displayed on
the screen.
When a Report Execution Request is submitted and the RtReports Server is connected to a
secondary server configured as the RtReports Template PI Server, no report execution
status information is written to the RtReports Template PI Server Module Database;
however, the report is generated and placed into the Report Cache. Furthermore, all
compliance workflow operations are enabled in the Report Viewer. Subsequent
compliance workflow operations fail to be inserted in the RtReports Template PI Server
but are shown in the Report Viewer.
Because of these scenarios, we recommend either using a non-replicated PI Server as the
RtReports Template PI Server or upgrade to an HA version of RtReports if you are using a PI
Server Collective as the RtReports Template PI Server.
At all Levels, when a new member connection is established due to an unexpected loss of
connection, the data request that initiated the failover may return an error. However, the
RtReports Server detects a failover and reflects the new behaviors of the connected collective
member in the RtReports Server. Once this operation occurs, the RtReports Generator behaves
exactly like the RtReports Server is making an initial connection as described above.

RtReports
Since RtReports expresses no preference for connections to a PI Server to retrieve data for a
report, it is possible that a collective providing PI data for a report could fail over while a report
is being generated. If the failover event causes a data request to return an error, this error is
treated like other report execution errors and stops the report execution. If no error was
generated as a result of the failover event, the RtReports Server stops execution of the report
and re-executes the report on the newly connected PI data server. If a subsequent failover
should occur during the re-execution of the report, the report execution is stopped and an error
message is returned.
Since unexpected loss of connection can happen randomly, the following sections describe
additional errors that may occur based on the state of the current RtReports Generator Search or
Report Viewer page that you are working with. If you experience any of these errors, you
should close the current browser session and open another. The new browser session will
reflect the current state of the RtReports Generator and Server.
RtReports Generator Batch Search Page
If a failover event occurs after the initial Batch results grid is populated, the following
errors may appear
• Expanding a row within the Batch results grid returns the following error:
Error: Batch database access disabled on connected collective
member
• Clicking the Report tab returns the following error:
Error getting reports: Error restoring object from persistence
string. CPIBatchRestorerReports for Recipe {BatchID} starts at
{BatchStart Time} and ends at {Batch End Time}
If a failover event occurs while on the Reports tab, clicking on a Report Name initiates the
report generation requests, however the Report Viewer displays an error:
Error restoring object from persistence string. CPIBatchRestorer
If a failover event occurs during the generation of a report, the RtReports Server attempts
to re-execute the report on the newly connected PI data server. Because the unique Batch is
not resident on the new server, the report generation fails with an error:
Error restoring object from persistence string. CPIBatchRestorer
RtReports Generator Report Search Page
Batch Context
If a failover event occurs after selecting report templates, and you attempt to search for
Batch contexts, the following error message is returned:
Error: Batch database access disabled on connected collective member
If a failover event occurs after selecting Contexts, and you attempt to generate reports, the
report execution request displays an error.
Time Context
Page 68
RtReports Generator
Time Contexts, you will notice the Generate box is not displayed. This is because the
RtReports Server cannot write report status information to the RtReports Template PI
Server. The report execution request generates a report into a Report Viewer in Read Only
mode.
If a failover event occurs after selecting Time Contexts, and you attempt to generate
reports, the report execution request generates a report into a Report Viewer in Read Only
mode and the report is not cached.
Case Context
Case contexts, an error message is returned:
Error: Analysis Framework case access not permitted on connected
collective member
If a failover event occurs after selecting Contexts, and you attempt to generate reports, the
report execution request displays an error.
RtReports Generator Report Viewer Page
If a failover event occurs after the initial generation of the Report Viewer page, and you
click the Comment hyperlink, enter a comment, and click OK; the following error message
is displayed:
Error: Unable to save request because the RtReports Server is not
connected to the Primary Template PI Server.
click the Verification hyperlink, enter a comment, and click OK; the following error
message is displayed:
click the Approve hyperlink, enter a comment, and click OK; the following error message
is displayed:
click the Print hyperlink, enter a comment, and click OK; the following error message is
displayed:

RtReports
RtReports Editor
Depending on the connection status of the RtReports Template PI Server, the RtReports Editor
reflects two modes of operation. If the RtReports Editor is connected to the primary server of
the RtReports Template PI Collective the Editor is in Normal mode. If the RtReports Editor is
connected to a secondary server of the RtReports Template PI Collective the Editor is in Read
Only mode.
If the RtReports Editor is in normal mode all operations are available.
If the RtReports Editor is in Read Only mode all operations that interact with the RtReports
Server are restricted. These operations include the following: Save, Save As, Check In and
Check Out. The Report Template Version Manager is available but you are only allowed to
open previous versions; you are not permitted to create a new version in this mode. If you are
an Administrator, the following Admin operations are restricted: Delete Reports, Check In
Report, Template Maintenance, and Import Security File. The Group Privilege and Report
Properties dialogs are available, but you are unable to save any changes.
You can determine the mode of the RtReports Editor by the text of the server in the status bar.
In Normal mode, text appears normal. In Read Only mode, text appears in bold with red font
and strikethrough.
Initial Connection
At Level 3, by default RtReports Editor attempts to connect to the primary server in a collective
configured as the RtReports Template PI Server. The RtReports Template PI Server is the PI
Server configured to store RtReports Report Templates.
If the primary server is unavailable, the RtReports Editor connects to a secondary server. When
the RtReports Editor is connected to a secondary, the RtReports Editor is in Read Only mode.
All operations that involve the RtReports Server are disabled. You can continue to work with a
report template but are unable to save the report template. When in a Read Only mode, you can
save a report template by exporting the Data Template and Format Template to an xml file that
can be later imported and saved to the primary server when it returns online.
At Level 2 and Level 1, when connected to the primary server configured as the RtReports
Template PI Server, RtReports Editor is the same as when connected to a pre-HA Server.
At Level 2 and Level 1, when connected to a secondary server configured as the RtReports
Template PI Server, RtReports Editor generates write errors when the following operations are
performed: Save, Save As, Check In, and Check Out. The following Administrator operations
also generate errors: Delete Reports, Check In Report, Template Maintenance, and Import
Security File.
Page 70
RtReports Editor
As stated above, at Level 3 RtReports Editor initially attempts to connect to the primary server
configured as the RtReports Template PI Server. When connected to the primary server, the
RtReports Editor is in normal mode and all operations are enabled. When connected to a
secondary server, the RtReports Editor is in Read Only mode and all write operations are
disabled. The RtReports Editor monitors the RtReports Template PI Server collective for any
change in member statuses.
At Level 2 and Level 1, RtReports Editor initially connects to a server configured as the
RtReports Report Template PI Server based on the default connection algorithm of the
collective. If connected to the primary, the RtReports Editor exhibits the same behavior as if
connected to a pre-HA Server. If connected to a secondary, the RtReports Editor generates
write errors when the following operations are performed: Save, Save As, Check In, and Check
Out. The following Administrator operations also generates errors: Delete Reports, Check in
Report, Template Maintenance, and Import Security File.
Planned Shutdown
At Level 3, when the RtReports Editor detects a change in the RtReports Template PI Server
collective status, the Editor analyzes this change. If the RtReports Editor is connected to the
primary server and detects a member status change, it determines if the primary server is
disconnected. If so, the RtReports Editor connects to a secondary server and changes its mode
to a Read Only state.
If the RtReports Editor is connected to a secondary server and detects a member status change,
it determines if the primary server is available. If so, RtReports connects to the primary server
and changes its mode to a normal state.
At Level 3, when the RtReports Editor detects a change in the RtReports Template PI Server
collective status, the Editor analyze this change. If the RtReports Editor is connected to the
primary server and detects a member status change, it analyzes this event and determines if the
primary server is disconnected. If so, the RtReports Editor connects to a secondary server and
change its mode to a disconnected state.
The RtReports Editor is a distributed application with several operations implemented in the
RtReports Server and called through web services from the RtReports Editor. It is possible that
you can perform one of these distributed operations and a failover occurs while this operation is
being performed by the RtReports Server. In this scenario, there are two possible outcomes:
1. An error is generated by the SDK during the execution of an operation, or

RtReports
2. The RtReports Server processes the failover event before attempting the RtReports Editor
operation.
If the first outcome arises, a PI SDK error propagates back to the RtReports Editor describing
the particular operation and error message generated on the RtReports Server. The RtReports
Editor also receives the change in member status of the PI Collective and takes the appropriate
action as described in the planned shutdown section.
If the second outcome arises, a general RtReports Editor error message is generated:
Page 72
Chapter 22: RtWebParts
The behavior of RtWebParts in an HA PI System is dictated by the installation of RtBaseline

Services (RtBLS), from which the web parts draw data.
At Level 3, there are few differences in behavior when drawing data from a PI Server
collective, as described in this chapter. If you are an administrator you may also notice changes
when administering RtBLS, as documented in the High Availability Advanced User Guide.
Level 2 is an unlikely scenario for RtWebParts. The HA version of the PI SDK is installed
when RtBLS is installed, and the HA version of RtWebParts requires the HA version of
RtBLS. See the High Availability Advanced User Guide regarding the implications of Level 2
implementation.
At Level 1, RtBLS connects to individual servers, not the collective. When an individual server
goes down, RtBLS has no concept of failover. Once the server returns, RtBLS reconnects to
that original server. From the perspective of an RtWebParts user, this is the same as when
connected to a pre-HA server.
Initial Connection
At Level 3, if RtBLS initially connects to a secondary server in a collective, there are some
limitations, particularly with regard to web parts that display value attribute data. Annotation
and value attribute data that is available from the primary server is unlikely to be available from
the secondary servers, and as a consequence, such data may not be shown in web parts that
display value attribute data when connected to a secondary server.
In some cases, certain value attribute data can be made available from secondary servers, but in
general such data is not present.
At Level 3, you may notice some slight differences in behavior when an RtBLS connection
makes a transition from one collective member to another.

RtWebParts
Connection Timeout
If the transition from one collective member to another takes longer than the configured
Connection Timeout for the collective, you see the same behavior as in pre-HA releases when a
PI Server becomes unavailable and then comes back online.
Updating with Secondary Data
When an RtBLS connection makes a transition from one collective member to another, most
web parts are updated to show data that originated from the collective member to which the
connection made the transition. This updated data may not exactly match what was seen from
the server from which the transition was made, particularly when recent data is being
displayed. See the High Availability Advanced User Guide for more information.
Annotations and Value Attribute Data
Normally, annotation and value attributes are not available from a secondary collective
member. Therefore, when an RtBLS connection makes a transition from the primary server in a
collective to a secondary server in that collective, any attempt to retrieve annotation data does
not return any data. As a specific example, icons that appear in RtTrend to depict the presence
of value attribute data for a particular value disappear when the connection is transitioned to a
secondary collective member.
In some cases, certain value attribute data can be made available from secondary servers, but in
general such data is not present. See the High Availability Advanced User Guide for more
detail.
Module Database
Changes to modules and their aliases and properties in a PI Server collective's Module
Database are always made to the primary PI Server in the collective, and then propagated to the
other members. Since there is a delay between the time in which the changes are written to the
primary and when they are propagated to the other members, it is possible that Module
Database data retrieved from one PI Server in a collective may not exactly match that retrieved
from another PI Server in the same collective.
Consequently, when an RtBaseline Services connection makes a transition from one collective
member to another, any RtWebParts that display data from the Module Database may be
refreshed with slightly different data, or may display an error. These effects are most evident in
RtTreeView, and in web parts that display data retrieved via a PI Alias or PI Property, such as
the RtGraphic web part when depicting a module-relative SVG. In addition, any web part that
draws data from the Module Database via a relational dataset based on the PI OLEDB provider
Page 74
is susceptible. There may also be related issues regarding RtBaseline Services configuration, as
described in the High Availability Advanced User Guide.

Chapter 23: Sigmafine
Sigmafine is a layered application developed on top of the Analysis Framework. Any added
advantage from High Availability in the Analysis Framework benefits Sigmafine users
accordingly. To understand the benefits of HA on the Analysis Framework see the PI Analysis
Framework (page 35) chapter of this manual.
Sigmafine does not read tag information directly from the PI System. Sigmafine plug-ins read
information from AF attributes, which can be configured to use the Analysis Framework PI
Point Data Reference. The only exception is the Component Data Reference that instantiates a
PI Point Data Reference to get tag information that is later converted into a DataTable format.
But even in this data reference, the actual retrieval is performed by the PI Point Data Reference
provided by the Analysis Framework.
The only client application provided by Sigmafine is the Sigmafine DataLoader. The
DataLoader provides the capabilities of writing transfers, updating case inputs or PI tags
according to their configuration defined in the Analysis Framework database. The DataLoader
is impacted by HA. The following sections describe the DataLoader behavior in HA context.
DataLoader Behavior When Connected to Primary
For the AF DataLoader, running under the time context, the default behavior for writing values
through the PI Point Data Reference is to write the values only to the primary. It is not possible
to configure an AF client to publish values to both the primary and its secondary.
Under transfer context, the default behavior for writing transfers is to write the values only to
the primary.
Under the case context, the default behavior for writing case inputs values is to write the input
values only to the primary.
DataLoader Behavior When Connected to Secondary
Under the time context, the default behavior for writing tag values is to fail over to the primary.
If that fails, the write fails. The DataLoader can modify the connection via the PI SDK to allow
writes to occur to a secondary.

Sigmafine
For the AF DataLoader, under transfer context, the default behavior for writing transfers is to
write the values only to the secondary. Under case context, the default behavior for writing case
inputs is to write the values only to the secondary. Physically, both transfers are case inputs and
are stored on the SQL Server configured to be used by the Analysis Framework Server.
Page 78
Appendix A: Glossary
automatic connection (failback)
If you are connected to a secondary but attempt an operation not supported on that server, the
PI SDK automatically attempts to make a transition to the primary server when it becomes
available. If it is not available you receive an error.
failover
When an application attached to a collective loses its connection (for example, due to network
failure, software crash, or hardware failure), you initiate a member switch with the PI
Connection Manager, or the server is shutdown, the PI System automatically attempts to
reconnect to another member. With the primary down, the secondary servers are tried in the
order of their configured priority and availability.
connection preference
The way an application connects to an HA PI Server. Connection preferences are set in the PI
Connection Manager of the PI SDK. The three types of connection preferences are:
RequirePrimary—Only the primary member server is acceptable. If it is unavailable,

return an error when trying to connect.
PreferPrimary—If the primary member server is available, connect to it. If not, any
secondary member server is acceptable.
Any—Any member server is fine. Use the locally configured priority to choose the
member for connection.

Sigmafine
collective
One or more PI Servers that together comprise an HA PI System. Servers within a collective
are commonly referred to as members.
HA server
A PI Server with the ability to make a transition to another PI Server in the event of planned
maintenance or an unexpected loss of connectivity.
Level 1
A PI System with an HA server, pre-HA SDK, and pre-HA client application.
Level 2
A PI System with an HA server, HA-aware SDK, and pre-HA client application.
Level 3
A PI System with an HA server, HA-aware SDK, and HA-aware client application. This level
of implementation takes full advantage of High Availability benefits.
non-replicated PI Server
A pre-HA release PI Server. Non-replicated PI Servers have no High Availability functionality

and can not be part of a collective.
primary server
The main server in a PI Collective where configuration changes are made. By default, this is
the only server that accepts non-buffered data.
Page 80
secondary server
secondary server
A server in a collective that is not primary. A collective can contain one or more secondaries,
but only one primary. Secondary servers automatically adopt configuration changes made on
the primary.

Appendix B: Technical Support and Resources
OSIsoft provides dedicated technical support internationally, 24 hours a day, 7 days a week.
You can read complete information about technical support options, and access all of the
following resources at the OSIsoft Technical Support Web site:
http://techsupport.osisoft.com
OSIsoft provides the following support options and resources.
Help Desk and Telephone Support
Telephone support is available 24 hours a day, 7 days a week. Direct service may not available
in some locations or during some hours; in this case, leave a message and your call will be
returned within 15 minutes.
USA and Canada: (510) 297-5828
Outside of North America: +01 510-297-5828
FAX: (510) 352-2349
E-mail Support
E-mail technical support inquiries, including the problem description and message logs, to
techsupport@osisoft.com. You will receive a response within 24 hours.
Personalized Online Technical Support
The Online Call Center allows you to create a support call, which will be responded to in 24
hours. It also allows you to review information from your previous support calls. Choose My
Support > My Calls (Online Support) in the Technical Support Web site. The My Support
menu allows you to review My Products, My Download History, and SRP Terms, which
covers Service Reliance Program (SRP) service agreements.

Sigmafine
Knowledge Center
The Knowledge Center provides a searchable library of documentation and technical data, as
well as a special collection of resources for system managers. For these options, click
Knowledge Center in the Technical Support Web site.
The Search feature allows you to search Support Solutions, Bulletins, Support Pages,
Known Issues, Enhancements, and Documentation (including user manuals, release notes,
and white papers).
System Manager Resources include tools and instructions that help you manage: archive
sizing, backup scripts, daily health checks, daylight savings time configuration, PI Server
security, PI system sizing and configuration, PI trusts for interface nodes, and more.
Remote Server Access
Technical support engineers can remotely access your PI server to provide diagnostics,
hands-on troubleshooting, and assistance. Choose Contact Us > Remote Access Options in
the Technical Support Web site.
On-site Technical Support
OSIsoft provides on-site service according to SRP service level agreements. To see current
SRP status, go to My Support > SRP Terms on the Technical Support Web site.
Before You Call or Write for Help
When you contact OSIsoft Technical Support, please provide:
Product name, version, and/or build numbers
Computer platform (CPU type, operating system, and version number)
The time that the difficulty started
The message log(s) at that time
Find the Version and Build Numbers
To find version and build numbers for each PI System subsystem (which vary depending on
installed upgrades, updates or patches) use either of the following methods:
Page 84
Before You Call or Write for Help
If you have PI System Management Tools (PI SMT) installed, choose Start > Programs >
PI System > PI System Management Tools. In PI SMT, select the server name, then
under System Management Plug-Ins, open Operation > PI Version. The PI Version tree
lists all versions.
If you do not have PI SMT installed, open a command prompt, change to the pi\adm
directory, and enter piversion -v. To see individual version numbers for each
subsystem, change to the pi\bin directory and type the subsystem name followed by the
option -v (for example, piarchss.exe –v).
View Computer Platform Information
To view platform specifications:
In Windows, right-click My Computer and choose Properties. For more detailed

information, choose Start > Run, and enter msinfo32.exe
In UNIX, use the command, uname -a

Index
PI ProcessBook • 49
A PI SQC • 57
about this manual • 1 PI System Management Tools (SMT) • 59
automatic connection • 16 RLINK • 61
RtReports Editor • 70
C RtReports Generator • 64
RtWebParts • 73
collective • 7
interfaces • 9
connection manager • 15
Control Monitor • 19 L
D Level 1 • 11
Level 2 • 12
DataSheet Control • 21
Level 3 • 12
initial connection • 21
transition to a new collective member • 21 O
H OSI Developers Network • 23
High Availability • 5
OSI OPC Server • 25
benefits of • 6
High Availablity architecture • 7
transition to a new collective member • 25
interface level failover • 9
multiple PI Servers • 7 P
PI SDK • 9
PI Servers • 7 PI ACE • 27
I transition to a new collective member • 29
PI ActiveView • 31
initial connection
PI AlarmView • 33
PI Analysis Framework • 35
HA PI Server • 13
PI BatchView • 39
OSI Developer Network • 23
PI DataLink • 41
PI ACE • 27
PI Analysis Framework • 35
PI DataLink • 41
PI Manual Logger • 45
PI OLEDB • 47

Index
sending archive data • 45 RtWebParts • 73

transition to a new collective member • 45 annotations • 74
PI OLEDB • 47 connection timeout • 74
intial connection • 47 initial connection • 73
transition to a new collective member • 47 module database • 74
write operations • 48 transition to a new collective member • 73
PI ProcessBook • 49, 50, 51, 52 updating with secondary data • 74
planned shutdown • 50 S
status report • 52 secondary PI Server • 7
trend • 50 limitations • 13
troubleshooting • 52 Sigmafine • 77
unexpected loss of connection • 50 DataLoader behavior • 77
xyplot • 51
PI ProfileView • 55 T
PI SDK • 9
PI Server • 7
automatic connection • 16
PI Server replication • 8
PI SQC • 57
OSI OPC Server • 25
PI ACE • 29
PI AnalysisFramework • 36
PI System Management Tools (SMT) • 59
PI DataLink • 41
planned shutdown • 15
PI SQC • 57
platform release one (PR1) • 6
planned shutdown • 5, 15
primary PI Server • 7
RLINK • 61
product behavior overview • 11
RtWebParts • 73
Level 1 • 11
SMT • 59
Level 2 • 11, 12
Level 3 • 11, 12
U
R unexpected loss of connection • 15
AnalysisFramework • 36
replication • 8
PI DataLink • 42
RLINK • 61
PI OLEDB • 48
PI SQC • 58
RtReports • 63
RtReports Editor • 70
RtReports Generator • 64
Page 88

High Availability User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

High Availability User Guide

Uploaded by

Copyright:

Available Formats

High Availability User Guide

© 1992-2006 OSIsoft, Inc. All rights reserved

OSIsoft Mexico S. De R.L. De C.V.

RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in

Chapter 1: About this Manual....................................................................................................1

Chapter 2: High Availability Explained.....................................................................................5

Chapter 3: Overview of Product Behavior .............................................................................11

Application Behavior with HA .....................................................................................................17

Chapter 4: Control Monitor......................................................................................................19

Chapter 5: DataSheet Control .................................................................................................21

Chapter 6: OSIsoft Developer Network ..................................................................................23

Chapter 7: OSI OPC Server......................................................................................................25

Chapter 8: PI Advanced Computing Engine (PIACE)............................................................27

High Availability User Guide Page iii

Transition to a New Collective Member...................................................................29

Chapter 9: PI ActiveView .........................................................................................................31

Chapter 10: PI AlarmView ..........................................................................................................33

Chapter 11: PI Analysis Framework (AF) .................................................................................35

Chapter 12: PI BatchView ..........................................................................................................39

Chapter 13: PI DataLink .............................................................................................................41

Chapter 14: PI Manual Logger...................................................................................................45

Chapter 15: PI OLEDB ................................................................................................................47

Chapter 16: PI ProcessBook .....................................................................................................49

Chapter 17: PI ProfileView .........................................................................................................55

Chapter 18: PI SQC.....................................................................................................................57

Chapter 19: PI System Management Tools (SMT)...................................................................59

Chapter 21: RtReports................................................................................................................63

Chapter 22: RtWebParts ............................................................................................................73

Chapter 23: Sigmafine................................................................................................................77

Appendix B: Technical Support and Resources ......................................................................83

High Availability User Guide Page v

Chapter 2 explains how HA works.

 Initial connection to an HA PI Server, and

 During transition to a secondary server following planned or unplanned loss of

High Availability User Guide Page 1

 High Availability Explained

 Overview of Product Behavior

High Availability User Guide Page 3

Here's how it works.

 Operating System Updates

High Availability User Guide Page 5

While occurring infrequently, unplanned downtime represents a greater risk.

Generally, exposure is similar to that of planned maintenance, with a couple of exceptions.

Benefits of High Availability and Platform Release One (PR1)

 Availability—A seamless connection and failover capability to replicated servers without

 Ease on Maintenance—Having HA facilitates maintenance of your system. You also

High Availability Architecture

 Primary—The main server in a collective where configuration changes are made. By

High Availability User Guide Page 7

Interface-level failover allows you to install redundant copies of an interface on separate

High Availability User Guide Page 9

 Level 1: HA PI Server, pre-HA PI SDK, pre-HA release client application

 Level 2: HA PI Server, HA PI SDK, pre-HA release client application

 Level 3: HA PI Server, HA PI SDK, HA-aware client application

HA PI Server HA PI SDK HA Client

Note: If you upgrade to an HA PI SDK or client application without upgrading to an HA

High Availability User Guide Page 11

Limitation of Secondary Servers

The limitations of secondary servers in a collective include:

 Writing configuration data is not supported. This limitation includes:

 Writing time-series data using the PI SDK is not supported by default.

High Availability User Guide Page 13

PI Connection Manager Dialog Box

Initial connection to an HA PI Server, and

During transition to a secondary server following planned or unplanned loss of

High Availability Explained

Overview of Product Behavior

Operating System Updates

Availability—A seamless connection and failover capability to replicated servers without

Ease on Maintenance—Having HA facilitates maintenance of your system. You also

Primary—The main server in a collective where configuration changes are made. By

Level 1: HA PI Server, pre-HA PI SDK, pre-HA release client application

Level 2: HA PI Server, HA PI SDK, pre-HA release client application

Level 3: HA PI Server, HA PI SDK, HA-aware client application

Writing configuration data is not supported. This limitation includes:

Writing time-series data using the PI SDK is not supported by default.

Planned server shutdown (for example, for planned maintenance)

An unexpected loss of connection

OSIsoft Developer Network

OSI OPC Server

PI Advanced Computing Engine

PI System Management Tools