4. PI Data Archive高可用架构模式
PI Data Archive 是 PI System 的数据中枢，所有接口、计算、事件框架和客户端最终都围绕它读写归档数据。一旦主归档不可用，即使采集端仍在缓存，历史数据也会出现缺口，实时画面和计算输出会中断。因此，高可用方案的选择直接决定了系统的数据完整性和可运维性。本节围绕四种主流模式展开：PI Collective、PI HA（PI High Availability）、Windows 故障转移集群，以及虚拟化层 HA，重点分析它们在 PI Data Archive 场景下的适用条件、数据一致性、故障切换行为和运维复杂度。
四种模式的本质差异
理解这些方案，关键要区分两个维度：一是数据副本由谁维护，二是故障切换由谁触发。PI Collective 由 PI Data Archive 自身维护多成员数据副本，切换由客户端和接口感知；PI HA 是 PI 官方提供的双机热备方案，由 PI 服务层管理主备角色；Windows 故障转移集群把 PI 作为集群资源，由操作系统仲裁切换；虚拟化 HA 则完全在虚拟机层面重启或迁移，PI 本身并不感知。
PI Collective：数据一致性最强的原生方案
PI Collective 是 PI Data Archive 原生的多成员架构。一个 Collective 通常包含 2～3 个成员，每个成员都持有完整的归档数据副本。写入时，接口将数据发送到 Primary 成员，Primary 再同步到其他成员；读取时，客户端可以连接到任意成员。当 Primary 失效时，剩余成员通过选举产生新的 Primary，接口和客户端重新连接即可继续工作。
它的最大优势是数据一致性由 PI 自身保证，且支持多副本冗余，适合对数据完整性要求极高的场景，例如电力调度、制药合规、长周期历史追溯。适用条件是：成员之间网络延迟低（建议同机房或低延迟专线）、时间同步严格（依赖 Windows 时间服务或 NTP）、归档文件大小和备份策略一致。需要注意的是，Collective 成员之间同步会带来额外网络和磁盘 I/O，成员数量不宜过多，通常 2～3 个即可。
PI HA：官方双机热备，兼顾一致性与切换速度
PI HA 是 OSIsoft 提供的双节点高可用方案，主节点处理读写，备节点通过镜像机制保持数据同步。当主节点故障时，备节点接管 PI 服务角色，接口和客户端重新连接到备节点。与 Collective 相比，PI HA 的节点数固定为 2，部署和授权更简单，但备节点在正常情况下不承担读负载，资源利用率较低。
PI HA 适合已有双机硬件、希望由 PI 层统一管理切换的场景。它的数据一致性较强，切换通常在秒级到分钟级。运维上需要关注镜像链路健康、备节点归档同步状态，以及切换后接口的自动重连配置。如果接口不支持自动重连，仍需人工干预或借助 PI Interface Configuration Utility 的故障转移配置。
Windows 故障转移集群：依赖共享存储的传统方案
Windows 故障转移集群把 PI Data Archive 作为集群资源，两个节点共享同一份归档存储（通常是 SAN 或共享磁盘）。活动节点挂载共享存储并运行 PI 服务，故障时集群服务将资源组切换到被动节点，由被动节点挂载存储并启动 PI。由于只有一份数据，不存在副本同步问题，但共享存储本身成为单点，必须配置 RAID 和冗余路径。
这种模式的切换时间通常在分钟级，期间接口可能缓存数据，但客户端会断开。它适合已有成熟 Windows 集群运维体系、且存储层具备高可靠保障的企业。运维复杂度较高：需要管理集群仲裁、共享存储、节点心跳、PI 服务资源依赖关系，任何一环配置不当都可能导致切换失败或脑裂。
虚拟化 HA：最易部署，但 PI 层无感知
虚拟化 HA（如 VMware HA、Hyper-V 故障转移）在 Hypervisor 层监控虚拟机状态，宿主机故障时将 VM 在另一台宿主机上重启。对 PI Data Archive 而言，它本质上是一次冷重启：PI 服务随操作系统重新启动，内存中的缓存丢失，切换期间的数据依赖接口缓存补传。
它的优势是部署简单、成本低，适合非关键业务或作为其他方案的补充。但数据一致性取决于底层存储（共享存储或 vSAN 等），切换时间较长，且 PI 本身不感知故障转移，无法主动触发接口重连或归档恢复。因此，虚拟化 HA 通常不作为 PI Data Archive 的唯一高可用手段，而是与 PI Collective 或 PI HA 结合使用。
选型建议与组合策略
如果追求最强数据一致性和多副本冗余，优先选择 PI Collective；如果希望由 PI 官方统一管理双机切换，PI HA 更合适；如果已有 Windows 集群和共享存储体系，可沿用故障转移集群；虚拟化 HA 适合作为基础保障层，但不建议单独承载核心归档。实际工程中常见组合是：虚拟化 HA 保障宿主机层可用，PI Collective 保障归档层数据一致，接口配置自动重连和缓存补传，形成多层防护。