Pros, Cons, and Gotchas of Using Load Balancers with PI Data Archive

In the world of PI System architecture, ensuring high availability and load management is a crucial aspect of system design. A frequent consideration for system architects is whether to place a PI Data Archive behind a load balancer to balance incoming requests and provide redundancy. However, such an implementation comes with its own share of pros, cons, and unexpected pitfalls. This blog aims to unpack these elements and provide some insights for those considering this architectural approach.

Understanding Load Balancers

Load balancers are networking devices that distribute incoming network traffic across multiple servers. By using a virtual IP address, load balancers can hide the actual destination IP(s) of servers, forwarding requests to whichever server is most available. This ensures that no single server is overwhelmed, thereby improving the system's overall performance and reliability.

Pros of Load Balancing PI Data Archives

1. Improved Resource Utilization: Distributing client requests evenly among multiple archives can lead to more efficient utilization of server resources.

2. Potential for Redundancy and Failover: In theory, load balancing can offer failover capabilities by redirecting traffic from unavailable servers to those that are operational.

3. Scalability: As demand grows, additional servers can be added behind the load balancer to handle increased load, theoretically providing a linear path to scaling up.

Cons and Gotchas

Despite these advantages, placing a PI Data Archive behind a load balancer presents several challenges and is generally not recommended or supported by OSIsoft:

1. Compatibility Issues: The PI System, particularly the PI Data Archive, does not support load balancing because changes are typically made on the primary Data Archive server. The incompatibility essentially negates the benefits of load balancing in this context.

2. Data Inconsistency and Integrity Risks: Because each PI Data Archive server maintains its own configuration and data sets, a client connecting through a load balancer may see data from only one server's perspective, leading to potential inconsistencies.

3. Complication with Collectives: The PI SDK handles collectives by communicating directly with known servers. Load balancers can obscure this connection, causing issues with the SDK's ability to correctly manage data across nodes.

4. Failure to Achieve True High Availability (HA): High Availability in PI Systems is managed through PI Collectives, which are specifically designed to ensure data redundancy and minimize downtime. Load balancers conflict with DAS's HA objectives, as they can neither fully account for nor replicate the collective behavior.

Design Considerations and Alternatives

If you are considering load balancers for redundancy or disaster recovery outputs, it's critical to examine the underlying architecture and design principles:

• Collective Nodes: Utilize PI Collectives for true HA. Establishting nodes in separate locations not only ensures redundancy but also meets disaster recovery requirements.

• Direct Interface Connections: Instead of routing through a load balancer, maintain direct connections for interfaces and data clients to the Data Archives in the collective.

• DNS Aliases: For some scenarios, DNS aliases might offer a simpler solution without the complexities and limitations of load balancers.

Conclusion

While load balancers are instrumental in managing traffic for many enterprise applications, their application within PI System architecture should be approached with caution. The nuances of data management, redundancy, and especially HA within the PI ecosystem require adherence to designed and supported strategies — primarily utilizing PI Collectives.

Considering these factors, make informed decisions aligned to your organizational needs, technical capabilities, and the specific requirements of your PI infrastructure.