As a Centre of Excellence engineer, a part of my job is helping our enterprise customers deploy PI using OSIsoft best practices. I was recently asked to provide a Highly-available PI Vision Architecture for a customer and realised it may be helpful to others. What better place to share it than on PI Square!

 

As PI Vision Matures and is adopted by more users, providing a highly-available, fault-tolerant solution is key in a modern PI system. Whilst PI Vision does not have a native HA feature like PI Collectives within the PI Data Archive, it's relatively straight-forward to implement a highly-available solution using common industry methodologies.

 

PI Vision consists of the PI Vision Application Server, PI WebAPI (and indexer/crawler) and the PI Vision SQL Database. It also makes connections to the PI Data Archive and PI AF Servers (which should also be in a HA configuration). Each one of these components can be a single point of failure, so we will need to implement redundancy for each and a method to failover between the two.

 

The general approach is to use a Load Balancer to provide failover at the Application server level and a highly available SQL Instance.

 

PI Vision Overview.png
Figure1: Highly-available PI Vision overview.

 

 

 

PI Vision Application Failover options

PI Vision stores its displays and configuration within the PI Vision SQL database, so if you point multiple PI Vison Application Servers at the same DB, each instance will behave alike. That is, each instance will share the same displays, configuration etc. This provides us with the desired level of redundancy, but we still need to implement failover. To do this, the common solution is to use a network load balancer, a software-level failover (like Application Request Routing in IIS) or a combination of both.

 

With multiple instances of PI Vision behind a load balancer, client connections are made to the load balancer which in turn forwards the requests to any available PI Vision instance. Should a server become unavailable, the load balancer can stop sending requests to that host. As Load Balancers are primarily used to share load across a number of resources, we can also take advantage of that with our PI Vision implementation!

 

You will need to enable "sticky sessions" or the equivalent on your Load Balancer as PI Vision is not stateless. There will also be a few more steps required to get Kerberos Delegation setup as you'll need to create SPN's for the Load Balancer virtual hostname.

 

The PI Vision Documentation available from the Live Library provides an in-depth comparison of the types of Load Balancing and Application Request Routing available and also provides a few external resources that will also help decide on the best strategy.

 

Database Level failover

As the PI Vision database is shared by all instances of the PI Vision application server, we need to make sure that it is available, fault-tolerant and can continue to serve requests should an incident occur. As Database mirroring is being removed from the SQL Server product, the preferred solution for a highly-available Database instance is to use SQL Server "Always On" Clustering/Availability groups. Again, the Live Library PI Vision documentation compares the various options for a highly available Database configuration.

 

The PI AF Server has similar requirements for database failover/high-availability and we recommend that you use the same instance of SQL for both AF and PI Vision.

 

When we piece it all together, we end up with something like this:

PI Vision.png
Figure 2: PI Vision Highly-available Architecture: Detail

 

 

 

So, by using a Load Balancer configuration and a highly-available database, you can achieve a high level of availability, redundancy and failover. This configuration will work well over multiple sites if the connectivity to the Database and PI Data Archive/AF Server is sufficient. Another advantage of this configuration is that modern Load Balancers have advanced features that open up additional desirable functionality. As an example, the Load Balancer may also be used as a reverse proxy which can enable external access to your PI vision Instance.

 

Every system is different, so you might find that you have unique requirements. You should discuss the various options with your IT team to work out what is best for your organisation. Your networking team may be able to advise you on their preference and capabilities around Load Balancing and will be vital in designing the finer details and configuration.

 

There are a few configuration requirements at both the Load Balancer and Database level that you will need to be aware of and you can find the details within the documentation. If you run into problems, you can always contact PI Technical Support (Or your EPM/CoE if you're an Enterprise customer!). I've attached the visio doagrams I used to make the images in this post, just in case they might be useful.

 

Hopefully this has been helpful. Please let me know in the comments below if you have any questions or would like clarification.