AVEVA™ PI Vision™

High availability options for PI Vision

Save PDF

High availability options for PI Vision

Save PDF

Last UpdatedFeb 05, 2025
3 minute read

The high availability (HA) solutions described here are independent of AVEVA PI Vision. These strategies are recommendations, but all systems have unique requirements; therefore, you should discuss these strategies with your database administrator and Internet Information Services (IIS) administrator while planning your architecture.

HA options are available for AVEVA PI Vision at both the database and application server levels. Each of these options has its own benefits.

Database options include:

Clustering
Mirroring
AlwaysOn Availability Groups
Transactional replication

AVEVA PI Vision application server options include:

Network load balancing (NLB)
Application request routing (ARR)
NLB and ARR in an active/passive failover configuration
NLB and ARR in an active/active failover configuration

Database level options

Employing HA at the database level prevents the AVEVA PI Vision database in Microsoft SQL Server from becoming a single point of failure.

You should implement HA for the AVEVA PI Vision database in the same way as applying HA to any other SQL Server database. Microsoft provides a general description of their HA implementation options for MS SQL Server in the article Business continuity and database recovery - SQL Server.

After connection, a replicated database acts in the same way as the database it replaces, therefore the only configuration change required is to make the AVEVA PI Vision application aware of the replicated database. You do this when you specify the connection string for the application. For example:

connectionString = "Data Source=myPrimaryServer;Failover Partner=mySecondaryServer;
Initial Catalog=myDataBase;Integrated Security=True;
Application Name=&quotPIVision Web Service&quot"

The connection string can be edited in the web.config for the AVEVA PI Vision web application directly, or through the Connection Strings module in IIS Manager when you have the AVEVA PI Vision web application selected. The web.config file is located in the following directory:

%pihome64%\PIVision

The following table summarizes the benefits and disadvantages of each SQL Server HA option.

SQL Server HA option	Advantages	Disadvantages
Clustering	Allows full-time read-write access to the AVEVA PI Vision database. No re-synchronization required. Cluster members always use the latest shared copy of the database.	Requires a significant initial investment in cluster hardware. Can be slow to failover between cluster members (compared to mirroring). Only one copy of the database. Distance between nodes is limited to a few meters, because they share a physical drive.
Mirroring	Allows full-time read-write access to the AVEVA PI Vision database. Fast failover time (compared to SQL clustering). Two copies of the database on independent hardware. The members can be physically separated by a long distance.	Requires a third "witness server" for hot failover. If run in asynchronous mode, the mirror database may not always be up to date.
AlwaysOn Availability Groups	Allows full-time read-write access to the AVEVA PI Vision database. Fast failover time (compared to SQL clustering). Two copies of the database on independent hardware. No witness server required.	SQL Enterprise is required to utilize Availability Groups.
Transactional replication	Two copies of the data on independent hardware.	Failover is not supported. Load balancing is not supported. No protection from replicated data being changed.

AVEVA PI Vision application server HA options

HA at the application server level can provide load balancing and fault tolerance.

The following table outlines some of the pros and cons for different network load balancing (NLB) and application request routing (ARR) implementations.

The following table summarizes the benefits and disadvantages of each AVEVA PI Vision application server HA option.

AVEVA PI Vision Application Server HA options	Advantages	Disadvantages
Application request routing (ARR)	Divides the data access load on the application server. Other features are available that allow ARR to act as a reverse proxy, if needed.	Does not provide true HA, because the ARR node remains a single point of failure. Limited scalability, because the traffic is channeled through a single node.
Network load balancing (NLB)	Divides the data access load on the application server.
NLB and ARR (active/passive)	Provides true HA since there is no single point of failure. Other features are available that allow ARR to act as a reverse proxy, if needed.	Larger investment required, in terms of setup and number of available machines required.
NLB and ARR (active/active)	Provides true HA since there is no single point of failure. Provides true scalability since traffic is not channeled through a single node. Other features are available that allow ARR to act as a reverse proxy, if needed.

For further information, see the PI Server topic Asset Framework (PI AF) high availability.

AVEVA™ PI Vision™