2. PI System架构回顾与单点故障分析
在讨论高可用与灾备之前，必须先把 PI System 的典型部署拓扑摊开来看。PI System 并不是一个单一软件，而是一组协同工作的角色：PI Data Archive 负责时序数据的存储与检索，PI AF Server 承载资产模型与计算上下文，SQL Server 为 AF 提供配置数据库，接口节点（PI Interface / PI Connector）从控制系统采集数据，客户端与分析工具消费数据。高可用工程的第一步，就是识别这些角色中哪些一旦失效会导致整条数据链断裂。
典型部署拓扑与数据流
一个中等规模工厂的典型拓扑通常包含：两台接口节点分别连接 DCS 与 PLC，通过 PI Buffer Subsystem 缓存数据后写入 PI Data Archive 集群；PI AF Server 与 SQL Server 部署在应用层；客户端通过 PI Vision、PI DataLink 或第三方系统访问。数据从现场到消费端的路径是：控制系统 → 接口节点 → PI Buffer → PI Data Archive → PI AF Server → 客户端。这条链上任何一环失效，都会造成数据丢失或服务中断。
单点故障识别与故障模式分析
单点故障（SPOF）是指系统中一旦失效就会导致整体服务中断的组件。在 PI System 中，最容易被忽视的 SPOF 往往不是服务器本身，而是接口节点的采集通道和PI Buffer 的落盘位置。如果接口节点与 PI Data Archive 之间的网络中断，而 Buffer 又配置在本地磁盘且磁盘故障，那么这段时间的现场数据将永久丢失。
下面给出一份可直接用于现场排查的故障模式与影响分析（FMEA）清单示例。严重度（S）、发生度（O）、可探测度（D）按 1～5 分评估，风险优先数 RPN = S × O × D，RPN 越高越需要优先处理。
| 组件 | 故障模式 | 影响 | S | O | D | RPN | 建议措施 |
|---|---|---|---|---|---|---|---|
| 接口节点 | 单节点宕机 | 该通道数据中断，Buffer 停止写入 | 4 | 3 | 2 | 24 | 部署冗余接口节点，配置自动故障转移 |
| PI Data Archive | 主节点服务停止 | 所有写入与查询中断 | 5 | 2 | 1 | 10 | 配置 PI Collective，主备自动切换 |
| PI AF Server | 服务崩溃或主机故障 | 资产模型与计算不可用 | 4 | 2 | 2 | 16 | AF 高可用集群或虚拟机 HA |
| SQL Server | 数据库不可访问 | AF 配置无法加载，新模型无法发布 | 4 | 2 | 2 | 16 | SQL AlwaysOn 可用性组 |
| 共享存储 | LUN 或阵列故障 | 归档文件损坏，历史数据丢失 | 5 | 1 | 3 | 15 | RAID + 异地备份 + 归档复制 |
| 网络链路 | 核心交换机故障 | 接口与服务器之间全部断连 | 5 | 2 | 1 | 10 | 双上联、堆叠或 VPC 冗余 |
从拓扑到冗余设计的判断逻辑
识别 SPOF 之后，需要判断哪些组件必须做冗余、哪些可以接受短时中断。判断依据通常有三条：数据是否可重采、中断是否影响安全或合规、恢复时间目标（RTO）与恢复点目标（RPO）。例如，DCS 的历史数据如果 Buffer 未落盘且接口宕机，数据无法重采，RPO 实际为无穷大，这类节点必须做冗余。而 PI AF Server 短时不可用通常只影响展示与计算，若业务允许 15 分钟恢复，则可用虚拟机 HA 而非完整集群。
常见误区与检查要点
- 只关注服务器冗余，忽略接口层。 PI Data Archive 做了 Collective，但接口节点仍是单机，采集侧依然是 SPOF。
- Buffer 与接口同机同盘。 接口主机磁盘故障时，Buffer 文件与采集程序一起丢失，缓存机制形同虚设。
- AF 与 SQL 部署在同一台物理机。 主机故障时两者同时不可用，且 SQL 的恢复往往比 AF 更慢。
- 未验证故障转移。 配置了 Collective 或 AlwaysOn，但从未做过切换演练，实际切换时间与数据一致性未知。
- 忽略时间同步。 多节点架构中，若各服务器时间偏差过大，故障切换后会出现数据时间戳错乱，影响后续分析。
完成本节分析后，应形成一份属于自己环境的 SPOF 清单，并标注每个故障模式的 RPN 与建议措施。这份清单将直接作为后续高可用方案设计与灾备演练的输入。