High Availability in PI Vision: Architecture, Administration, and Best Practices

As PI System engineers and administrators, ensuring High Availability (HA) for critical visualization platforms like PI Vision is a top priority. While much official documentation emphasizes the need for HA in core data infrastructure—such as Asset Framework (AF) and Data Archive (DA)—there's considerably less direct guidance when it comes to deploying PI Vision in a highly available, enterprise-ready manner. In this post, we clarify common questions regarding HA architectures for PI Vision and provide practical advice on database sharing, redundancy, and configuration management.

PI Vision HA Basics: Drawing Parallels with Asset Framework

Typical Architecture

For most PI Vision HA deployments, the tried-and-true pattern is:

• Multiple PI Vision Web/Application Servers: Each installs the PI Vision application and is hosted behind a Network Load Balancer (NLB) or Application Request Routing (ARR) for traffic distribution and failover.
• Shared SQL Server Database: All PI Vision instances point to a single SQL Server database, ideally hosted in a clustered or AlwaysOn Availability Group configuration.

This mirrors the common Asset Framework (AF) HA deployment pattern, giving confidence that similar principles apply.

Why a Shared Database?

PI Vision stores display definitions, user preferences, folder structures, and similar content in its backend SQL database. For true continuity and load balancing, every PI Vision node should read and write from the same database. This ensures:

• User actions (e.g., creating/editing displays) are immediately available on all nodes.
• Roles, security, and data are consistent regardless of which server the NLB directs users to.
• Failover is seamless; a lost node doesn't impact the user's access to their visualizations.

The Admin Challenge: Configuration Drift and the Admin Tool

A persistent gray area in PI Vision's HA story is how administrative settings are managed. Specifically:

• Is the PI Vision Admin tool HA-aware?
• Do changes made via the Admin tool replicate automatically across all web servers?

Short answer: No, PI Vision Admin is not fully HA-aware in the sense that all configuration changes made via its GUI automatically synchronize between all instances.

Why?

Many administrative settings altered in the Admin tool (notably things like allowed PI or AF Servers and other environment-specific values) are stored in the local web.config file of each PI Vision server. These do not get written back to the SQL backend. As a result, changes made on one node do not automatically propagate to others.

What This Means Practically

• Manual Replication Required: Any change you make through Admin (e.g., updating the list of AF servers, enabling/disabling certain behaviors) must be applied to every web server instance. If not, behavior can diverge between nodes, causing inconsistent user experiences depending on load balancer routing.
• Config Drift is a Risk: Over time, manual steps can lead to configuration drift, undermining your HA strategy.

Best Practices for PI Vision HA Administration

1. Shared Database is a Must: All PI Vision servers in an HA setup should point to the same SQL database, itself made highly available using SQL clustering or AlwaysOn Availability Groups.

2. Synchronize Web Configurations: Changes made via the Admin tool (or directly to web.config) must be manually replicated to all PI Vision servers.

   • Use configuration management tools (e.g., scripts, Group Policy, enterprise deployment tools) to automate and audit this process.
   • Maintain a golden copy/source-controlled version of web.config for consistency.

3. Document Your Procedures: Since official docs are limited, detail your internal change procedures for reference and onboarding.

4. Monitor for Configuration Drift: Periodically check that all PI Vision nodes have equivalent configuration files and are pointing to the same backend resources.

5. Engage with the Community: OSIsoft PI Square and related forums are the best sources for current practices and peer validation while documentation catches up.

Wish List: Better Documentation

There's a clear call for OSIsoft/AVEVA to clarify these aspects in the official guidance:

• Explicit diagrams showing PI Vision HA with shared databases
• Administration change propagation and best practices
• Tooling for centralizing configuration (similar to AF)

Conclusion

PI Vision can absolutely be deployed in a robust, HA configuration, but care must be taken to ensure web application configuration is manually and consistently propagated across all nodes. While display data and user content synchronize via a shared SQL backend, administrative configuration does not—so manual processes or automation must fill the gap.

Have you streamlined PI Vision configuration management or built tools for automating these changes? Share your tips and stories below!