WinCC OA NGA历史归档
1.1 NGA基本概念
WinCC OA在3.17版本以前提供了三种不同的历史归档解决方案:
· WinCC OA Value Archive(“HDB”;使用基于ETM公司自己研发的文件历史归档文件机制)
· WinCC OA RDB Manager(基于Oracle的中央归档解决方案)
· RAIMA存档(RAIMA事件归档库的当前版本已经停止更新和支持,但仍可继续使用。RAIMA报警归档继续在3.17版本提供支持。在使用Value Archive时仍需要RAIMA归档数据库用于报警存档)。
ValueArchive(+RAIMA)和RDB归档用于存储基于Tag的事件(历史数据)和基于时间戳的报警(实时/历史报警),并支持检索。Value Archive适用于规模较小的单机版/冗余系统对历史归档文件不太大的应用场景,通常认为设计容量<10G历史库文件大小属于规模较小;RDB Manager针对的是历史库容量较大(比如>10G的设计容量)与大型分布式网络系统的应用环境。
从WinCC OA 3.17开始,用于WinCC OA的NextGen归档(NGA)是一种新的归档解决方案,提供更加灵活的历史归档架构。
新的NGA归档解决方案特性主要功能包括:
· 使用与现有WinCC OA归档解决方案,兼容以往的DP配置归档事件和报警
· 兼容的历史读取接口(dpGetPeriod、dpGetAsynch、dpQuery with TIMERANGE、alert GetPeriod)
· 支持直接读取,直接从CTRL代码访问底层数据库,如用户界面,CTRL管理器的脚本可以直接访问历史库
· 模块化DB后端概念,可用于用户自定义创建DB后端接口
· 将来可以支持多种不同数据库软件的并行归档
· 集成先进的时间序列数据库InfluxDB®作为默认后端
· 减少历史归档文件占用硬盘存储容量
· 与Oracle数据库兼容的数据库空间定义
· 支持多个WinCC OA系统共用一个数据库
· 由WinCC OA面板和脚本控制的数据库维护(备份、恢复等)
· 支持冗余历史数据库特性
图:NextGen存档体系结构
1.2 InfluxDB®
InfluxDB®是InfluxData注册的商标,不属于WinCC OA软件的原生数据库。
系统架构包括:
· WinCC OA提供一个前端管理器接口(初始化过程、配置与组态、读写接口)
· 包含数据库InfluxDB®特定部分的后端;后端可以独立的服务进程来运行,也可以通过前端调用的库()来运行。
· 用于保存历史数据的不同品牌的数据库
2 安装需求
2.1 架构与部署方案
图:NGA部署-后台本地进程
本章阐述WinCC OA NextGen Archiver的不同部署架构。
2.1.1 本地后端部署
后端与前端在一台主机,后端作为 DLL调用。
2.1.2 后端作为服务部署
后端作为独立服务启动,接受前端的启动停止控制,后端与数据库运行在同一台主机。这种模式下,“Direct Read”功能不能使用。
2.1.3 后端本地运行,数据库远程部署
后端作为独立服务运行在相同主机,数据库运行在远程的一个主机。
2.1.4 两个后端同时运行
两个后端运行在相同的主机,一个数据库运行在本地,另一个数据库远程。
2.1.5 分布式架构
对于分布式系统架构:
仅需要在一个WinCC OA节点配置NGA,其他节点的自带的NGA服务必须停止。
可以为分布式系统配置共享的归档组,接受各个子节点的同时访问。
带有数据库的服务器主机必须时刻处于运行状态,或随其主机开机自启动。
只有在配置成共享DB的时候才可以使用直接读的功能。如果未在后端配置远程DB,NGA不能直接读的方式访问远程DB。例如,两个WinCC OA,各自都配置了本地(非远程)DB,后端也配置成读写本地的DB,这种情况无法使用直接读远程DB的功能。
2.2 创建项目
3.17版本WinCC OA会自动安装NGA的功能。创建新项目时,可以选择使用Value Archive(HDB)历史归档功能或使用NextGen Archiver历史归档功能。
若选择后者,配置文件会增加如下的内容:
[general]
useNGA = 1
此外,将在<projectdir>/db/winccoa/Influx中创建一个空Influx®数据库,PARA模块的归档面板将是不同的面板(见下文)。系统管理中的数据库配置面板也会有所不同。此外,progs文件将反映NextGen Archiver的用法:
选择NGA存档时,系统内置默认需要归档的内部DP数据点将存储在默认存档组(“Event”)中。
2.2.1 InfluxDB®安装
WinCC OA安装包中包含了InfluxDB®的安装。注意,有一个特定于DB的配置文件influxdb.conf,被添加到目录<projectdir>/config。InfluxDB®数据文件的位置是特定于项目的(<projectdir>/db/wincc_oa/influx)。该文件将自动调整以匹配所创建项目的位置。
如果您在分布式系统(即多个WinCC OA系统写入单个数据库)上使用InfluxDB®,则必须编辑此文件。
bind-address = "127.0.0.1:8088”
修改为
bind-address = "191.168.0.1:8088”
其中191.168.0.1应替换为influxDB®的计算机的真实IP地址
InfluxDB®的启动和关闭由NextGen Archiver InfluxDB®后端处理。DB将在项目启动时启动,在项目停止时关闭。
还可以安装一个通用的InfluxDB®用于本地或多个远程项目,这些项目应在系统启动时启动,在系统关闭时停止。本地是指“混合访问”的项目,远程项目可以访问本地的InfluxDB。
随WinCC OA一起安装的Influx®数据库提供默认用户名和密码:
DB username: etm
DB password: etm#123
出于安全原因,强烈建议在首次有效使用数据库之前更改密码。按以下步骤进行:
1. 打开操作系统命令行提示行
2. 打开influx cli工具(位于<winccoa installation dir>/bin/influx中)
3. 输入以下命令(每行用<Enter> 确认)
auth
username: etm
password: etm#123
set password for "etm" = '<your new password here>'
quit
4. 打开NGA配置面板->后端选项卡
l 从列表中选择后端。
l 单击配置图标。
转到“数据库”选项卡。
l 输入新密码。
l 单击应用或确定。
使用新密码,数据库将恢复正常运行。
2.2.2 InfluxDB®加密通讯
InfluxDB®可以配置为在后端和数据库实例之间使用加密传输(SSL/HTTPS)。默认情况下,不启用加密。如果数据库运行在与WinCC OA不同的节点上,则建议启用加密。加密传输会损失一些计算力。
使用加密通信,系统自签名证书(密钥文件位于<winccoa installation dir>/config)连同WinCC OA(NGA)一起安装,使用nga_influx.crt, nga_influx.key这两个密钥文件。请注意,所提供的证书是自签名的,不能防止m-i-m攻击。建议用户将它们更改为您自己的安全证书。
可以按以下方式启用HTTPS加密:
5. 编辑文件<projdir>/config influxdb.conf
6. 将启用https的行从false更改为true:
#Determines whether HTTPS is enabled.
https-enabled = false -> 改为 true
7. 保存文件。
8. 使用NGA配置面板停止并重新启动InfluxDB。
9. 打开SysMgm->Database Engineering->Backend。
10. 选择Backend,然后在Basic Configuration下选择连接字符串。
11. 更改连接字符串http://127.0.0.1:8086至https://127.0.0.1:8086
12. 单击应用
13. 重新启动后端(独立数据库进程)或NGA(内嵌进程)
要测试SSL是否正常工作,请在WinCC OA安装目录的bin子文件夹中打开一个命令窗口,然后输入:
influx -sll -unsafeSsl
在启用https重新启动数据库后,WinCC OA日志中可能会显示错误消息,直到在配置面板中正确设置连接字符串。
如果需要分析数据库的问题,启用InfluxDB®中的日志功能将信息文本写入日志文件。请打开influXDB配置文件influxdb.conf(位于<projdir>/config中),搜索行“logging-enabled”并将其从false更改为true:
logging-enabled = false -> 改成 true
下次重新启动InfluxDB数据库后,日志输出<proj dir>/log/influxtxt.
除了InfluxDB®的日志记录之外,数据库必须在NextGen Archiver启动之前手动启动,而不是由NGA后端启动。
此文件没有大小限制。为了避免磁盘溢出,必须重置设置(改回false),并且在不再需要日志记录时重新启动数据库。可以在数据库停止时删除日志文件。
3 NGA冗余
3.1 冗余归档架构
WinCC OA可以在冗余模式下运行,其中使用两台WinCC OA服务器(在以下上下文中称为“左”和“右”),其中一个系统的故障由另一个系统接管。其中一台服务器始终是“激活”服务器,向外部设备发送数据并处理用户界面,另一台服务器是“备用”服务器,保持激活服务器的实时副本。
NGA冗余的主要作用是避免由于单个硬件或软件故障而丢失历史数据。该实现旨在能够处理单个故障,而不是多个故障(例如,两台服务器上的硬盘崩溃)。NGA冗余的另一个作用是当其中一个冗余节点关机的时候,仍然可以为远程用户接口提供历史访问。
还有一个称为“分离模式(Split Mode)”的特殊冗余选项,其中两台服务器都将处于激活状态,当结束分离模式时,其中一台将保持激活状态,另一台将重新启动并进行同步(这是服务器项目重新启动时标准的WinCC OA冗余功能)。NextGen Archiver(当前)不支持此选项。
每个冗余服务器都有一个“错误状态”(也称为“健康状态”),正常情况下两个服务器上的代码应该是相同的。如果不相同,则“运行状况”较好的服务器将变为激活服务器,可能导致主动服务器和被动服务器之间的“切换”。如果服务器已停止,则必须在下次重新启动时对其进行同步,以便与当前运行的服务器具有相同的“状态”(数据点值、警报状态等)。这就是所谓的恢复。
为了将现有的基于NGA的项目转换为冗余项目,除了与NGA无关的步骤(参见Redundancy,basics)外,NGA前端和后端也必须转换为冗余。通过单击按钮“创建冗余NGA数据”(“NGA配置”面板上的“常规”选项卡,请参阅配置-存档组)完成此操作。
对于在冗余系统中使用NextGen Archiver,可以使用两种不同的模式(取决于所用数据库的冗余支持):
1. 如果数据库本身不能进行冗余(例如InfluxDB的开源版本),则数据库必须在两个相互独立的节点上运行(就数据库而言)
2. 如果数据库能够进行冗余操作(即Oracle RAC),则两个冗余NGA实例都可以与一个公共数据库实例通信,该实例将自行执行冗余操作(切换、恢复)。
3.1.1 NGA冗余架构——对于数据库本身不能实现冗余的情况
如果数据库不具备冗余能力,NextGen Archiver遵循如下规则:
l 保持备用数据库与激活的主机数据库同步
l 可实现冗余主备之间的切换
l 备机在重启后会与主机进行一次数据库同步(注意数据库的大小)
l 在系统总览图中的“系统健康”中包括数据库/连接状态
执行此操作的基本思想是在每个冗余节点上使用两个相同的后端,一个连接到本地数据库,另一个连接到冗余伙伴上的数据库。激活的服务器写入两个后端,备用服务器只是缓冲数据块,直到激活的后端成功地将其写入数据库,然后丢弃这些数据。
如果是冗余系统,NGA前端会将所有数据额外发送到后端,并写入另一个系统(上图中的“后端2”)。切换之后,以前的被动服务器开始将现有缓冲区(以前的激活的服务器尚未提交这些缓冲区)写入数据库(本地和远程)。
如果另一台服务器(或者至少是数据库)已关闭或者无法访问,则写入此主机的后端将缓冲数据。为了在冗余环境中覆盖更长的时间范围,必须相应地设置缓冲方法(缓冲到磁盘)。
在被动服务器/数据库重新启动后,激活的服务器的后端写入被动数据库将自动检测数据库的可用性并开始写入缓冲数据(恢复)。被动系统必须删除任何本地存储的缓冲区。
所有从用户界面读取历史值/警报(dpGetPeriod、dpGetAsynch、alertGetPeriod、dpQuery)的请求都将由事件管理器自动路由到活动系统。必须使用命令行参数“-connectToRedundantHosts”启动控制管理器,以便自动路由到激活的主机。
如上图所示,冗余NGA项目的WinCC OA系统概览面板
NextGen Archiver也显示在WinCC OA的系统总览面板上。生成使用NGA的项目时,会为两个冗余节点显示标准后端(“InfluxDB”),错误状态计算包括NGA管理器(而不是值存档或RDB管理器),权重是根据后端到数据库的连接计算的(bad=未连接到到数据库)。
3.1.2 NGA冗余架构——对于数据库本身可以实现冗余的情况
对于能够实现冗余的数据库(即提供单个虚拟节点进行通信,并且能够在内部管理冗余数据库节点的写入/读取/同步),可以使用类似但简化的体系结构。注:这通常要求数据库位于不同的节点或与运行WinCC OA的计算机不相同的计算机上。
此冗余选项尚不可用,因为InfluxDB®后端尚无此选项。
冗余数据库的NGA冗余体系结构
每个冗余WinCC OA节点上只需要一个NGA DB后端,每个都连接到同一个虚拟DB实例。激活的服务器上的NGA将数据写入数据库,备用的服务器缓冲并在激活的端提交数据时丢弃缓冲区。此解决方案与WinCC OA的RDB管理器中使用的冗余架构非常相似。
由于冗余数据库可能自己进行冗余切换,活动后端必须能够处理中止的事务(由数据库冗余切换引起)并恢复。这是由NGA的缓冲算法提供的,该算法重复写入缓冲区,直到操作成功或达到重试次数。
所有读取操作(非直接和直接)始终发送到同一虚拟数据库节点。因此,不需要为直接查询“寻址”活动节点。