2. AVEVA工业平台典型架构解析
在讨论高可用与灾备之前，必须先看清 AVEVA 工业平台“长什么样”。很多现场的高可用方案之所以失效，并不是因为集群软件配置错误，而是因为设计者没有识别出真正的单点依赖——例如把注意力全放在 SCADA 服务器冗余上，却忽略了历史库、许可服务器或统一身份认证这些“看不见但一断就全停”的组件。本节从系统组成、服务分层、数据流三条线索切入，最后落到高可用灾备的关键依赖点上。
一、系统组成：从现场到企业级的四类角色
一个典型的 AVEVA 工业平台（以 System Platform + Historian + 可视化客户端为主干）可以按角色划分为四类组件：
- 采集与边缘层：现场 PLC/DCS/RTU 通过 OPC UA、Modbus TCP、EtherNet/IP 等协议接入，由通信驱动（如 OI Server、DI Server）或边缘网关完成协议转换与数据缓存。
- 平台服务层：包括 Galaxy Repository（GR，对象与模型仓库）、Application Server（对象引擎与脚本执行）、View Engine（图形渲染）、Alarm Server（报警与事件）、Historian（历史数据存储与检索）。
- 客户端与展示层：Operations 客户端、Web 客户端、移动端，以及报表与仪表板工具。
- 支撑服务层：SQL Server（GR 与 Historian 的元数据/事件存储）、Active Directory 或 AVEVA 统一身份、License Server、时间同步源（NTP/PTP）。
这四类角色在物理上可能分布在多台服务器上，也可能部分合并部署。理解它们之间的调用关系，是判断“哪些组件必须冗余、哪些可以降级”的前提。
二、服务分层：谁依赖谁
从依赖方向看，平台呈现明显的分层结构：底层是操作系统、SQL Server、AD、License 与时间源；中间是 GR、Application Server、Historian 等平台服务；上层是 View Engine、Web 服务与客户端。上层依赖下层，下层故障会向上放大。例如 License Server 不可用，Application Server 可能在宽限期后停止运行；AD 不可用，客户端登录与权限校验会失败；时间源漂移，会导致报警与历史数据时间戳错乱，进而影响事件顺序分析。
因此，高可用设计不能只盯着“最显眼”的 SCADA 节点，而应按依赖链逐层识别冗余需求。下面这张图给出了典型部署下的分层与数据流关系，并标注了关键依赖点。
三、数据流：从现场值到历史趋势
以一路温度信号为例，其典型数据流为：PLC 寄存器 → OI Server 扫描（示例扫描周期 500 ms）→ Application Server 对象属性更新 → Alarm Server 比较报警限值 → Historian 按死区（示例 0.5 ℃）与采样周期（示例 1 s）决定是否落库 → View Engine 从内存或 Historian 读取并渲染趋势。这条链路上任何一环中断，都会导致“画面还在动但历史断档”或“历史正常但报警不触发”等局部失效。高可用设计需要针对每一环明确：是否允许短暂中断、中断后如何补数、切换时是否丢点。
四、高可用灾备关键依赖点
结合上面的分层与数据流，可以把关键依赖点归纳为以下几类：
| 依赖点 | 故障影响 | 冗余/容错建议 |
|---|---|---|
| SQL Server（GR/Historian 元数据） | GR 无法签出、Historian 无法写入、报警事件丢失 | AlwaysOn 可用性组或故障转移集群；独立实例避免与平台服务争抢资源 |
| Active Directory / 统一身份 | 客户端无法登录、权限校验失败、服务账户认证中断 | 多域控部署；本地缓存凭据作为降级手段；服务账户使用托管账户 |
| License Server | 宽限期后 Application Server 停止、客户端无法连接 | 冗余许可服务器；离线许可作为应急；监控许可到期与占用 |
| 时间源（NTP/PTP） | 报警与历史时间戳错乱、事件顺序不可信 | 双时间源；平台内统一指向同一层级；定期校验偏差 |
| Galaxy Repository 主节点 | 无法部署对象、无法签出、模型变更停滞 | GR 冗余（主备/集群）；定期备份 Galaxy 并验证恢复 |
| Historian 主节点 | 历史数据断档、趋势不可用、报表缺失 | Historian 冗余（采集端缓存+存储复制）；明确切换时的数据补传策略 |
常见误区：只对 Application Server 做冗余，却让 GR、Historian、License、AD 保持单实例。结果是主节点切换成功，但平台整体仍不可用。高可用必须沿依赖链逐层检查，而不是只冗余“最显眼”的那一层。
五、一个可执行的依赖检查清单
在实际项目中，可以用下面这份清单快速核对关键依赖是否已覆盖。字段可根据项目规模裁剪，但建议至少保留“组件、当前部署方式、是否单点、冗余方式、切换验证结果”五项。
AVEVA 平台高可用依赖检查表（示例）
组件 当前部署 是否单点 冗余方式 切换验证
SQL Server 单实例 是 AlwaysOn AG 待验证
Active Directory 双域控 否 — 已通过
License Server 单实例 是 备用许可服务器 待验证
NTP 时间源 单源 是 双上游源 待验证
Galaxy Repository 单节点 是 主备 GR 待验证
Application Server 双节点 否 故障转移集群 已通过
Historian 单节点 是 冗余 Historian 待验证
View Engine 双节点 否 负载均衡 已通过
填写时要注意：“是否单点”与“冗余方式”必须成对判断。例如 AD 部署了两台域控，但两台虚拟机在同一台物理主机上，逻辑上不是单点，物理上仍是单点。灾备设计必须同时考虑逻辑冗余与物理隔离，否则机房级故障仍会导致全停。