4. PI高可用架构设计
PI System 在流程工业中承担实时数据采集、存储与分发的中枢角色，一旦 PI Server 不可用，历史数据断档、实时画面失效、上层分析停摆，损失往往以分钟计。因此高可用架构设计不是“锦上添花”，而是 PI 系统落地时必须前置规划的核心工程问题。本节围绕 PI Server 集群、PI Collective、HA 节点、故障转移、负载均衡与跨站点部署模式，梳理一套可落地的设计思路。
一、核心原理：从“单点”到“多副本”
PI Server 的高可用本质上是解决三类单点：数据存储单点、接口连接单点和站点级单点。PI System 提供了两条主要技术路径：
- PI Collective：多个 PI Data Archive 节点组成一个逻辑集合，成员之间通过 PI Collective 复制机制同步历史数据和实时数据。客户端连接 Collective 时，可指定主节点或通过 PI Collective 成员列表实现自动切换。
- PI HA 节点（High Availability Node）：通常指在 Windows 集群或虚拟化层面配置的备用 PI Server 节点，配合共享存储或存储复制，实现主机级故障转移。
两者并非互斥：Collective 解决 PI Data Archive 层的数据冗余与读扩展，HA 节点解决操作系统与主机层的高可用，实际项目中常组合使用。理解它们的边界，是设计架构的第一步。
二、PI Collective 的成员角色与数据流
一个 PI Collective 通常包含 2～4 个成员，每个成员都是一台独立的 PI Data Archive。成员之间存在主从关系：Primary 负责接收接口写入，Secondary 通过复制队列同步数据。当 Primary 故障时，可手动或自动将某个 Secondary 提升为 Primary，接口重新指向新 Primary 即可继续写入。
Collective 的复制是异步的，存在秒级延迟。因此设计时要关注：复制队列长度、网络带宽、成员间时钟同步，以及 PI Buffer Subsystem 在接口侧的缓存能力。接口侧缓冲区是 Collective 切换期间不丢数据的关键保障。
三、HA 节点与故障转移机制
HA 节点通常基于 Windows Server Failover Cluster 或虚拟化平台的高可用能力实现。PI Server 的 HA 配置需要关注以下要点：
- 共享存储或存储复制：PI Data Archive 的数据文件、队列文件必须对主备节点可见，或通过存储级复制保持同步。
- 虚拟主机名与 IP：客户端和接口连接的是集群虚拟名称，而非物理节点名，这样切换后连接字符串无需修改。
- 服务依赖顺序：PI Data Archive、PI AF Server、PI Analysis 等服务需按依赖关系启动，避免切换后服务起不来。
- 切换时间目标：明确 RTO（恢复时间目标）与 RPO（恢复点目标），据此选择共享存储、同步复制或异步复制方案。
四、负载均衡与跨站点部署模式
负载均衡在 PI 架构中主要体现在两个层面：接口写入的负载分担和客户端读取的分流。接口侧可通过多接口节点分别连接不同 Collective 成员，实现写入分散；客户端侧可通过 PI Collective 成员列表或网络层负载均衡，将读取请求分发到多个成员。
跨站点部署常见三种模式：
| 模式 | 结构 | 适用场景 | 注意事项 |
|---|---|---|---|
| 主备站点 | 站点 A 主 Collective，站点 B 远程成员 | 灾备要求高、预算有限 | 跨站点复制延迟，需评估带宽 |
| 双活站点 | 两站点各含 Collective 成员，互为备份 | 两地生产、读取本地化 | 复制拓扑复杂，需统一命名与时钟 |
| 边缘汇聚 | 边缘 PI 节点缓存，中心 Collective 汇聚 | 多工厂、网络不稳定 | 边缘 Buffer 容量与回补策略 |
五、典型场景与配置示例
某炼化企业要求 PI 系统 RTO 小于 5 分钟、RPO 接近零。设计方案为：站点 A 部署两台 PI Data Archive 组成 Collective，Primary 运行在 HA 集群节点上；站点 B 部署一台远程 Collective 成员作为灾备。接口侧启用 PI Buffer Subsystem，缓冲区大小按 8 小时数据量设计。
# PI Collective 成员配置示例（PI System Explorer）
Collective Name: PLANT_A_COLLECTIVE
Members:
- PIDA01.plant.local (Primary)
- PIDA02.plant.local (Secondary)
- PIDA-DR.siteb.local (Secondary, 跨站点)
# 接口连接配置
PI Server: PIDA01.plant.local
Buffer Subsystem: Enabled
Buffer Size: 8h
Failover: Automatic to PIDA02切换验证时，可手动停止 Primary 的 PI Data Archive 服务，观察 Secondary 是否被提升、接口是否自动重连、Buffer 是否开始回补。日志中应关注 PI Collective 与 PI Buffer 相关条目。
六、常见误区与复盘
- 误区一：只做 Collective 不做 HA。Collective 解决数据副本，但主机宕机后成员恢复仍需时间，HA 节点可缩短主机层恢复窗口。
- 误区二：忽略接口 Buffer。切换期间接口若没有缓冲，数据直接丢失，Collective 再强也无法回补。
- 误区三：跨站点复制带宽不足。复制队列积压会导致 Secondary 长期落后，灾备切换时数据缺口大。
- 误区四：切换后未验证服务依赖。PI AF、PI Analysis 等服务未随 PI Data Archive 一起恢复，导致上层应用不可用。
综上，PI 高可用架构设计应围绕“数据副本、主机冗余、接口缓冲、跨站点复制”四条主线展开，结合业务 RTO/RPO 要求选择 Collective 与 HA 节点的组合方式，并通过演练持续验证。只有把故障转移路径设计清楚，PI 系统才能在真实故障中保持连续可用。