信息通信运行数据自主采集、智能分析关键技术研究及应用

国网宁夏电力有限公司信通公司 刘思尧 李雪松

安徽继远软件有限公司 李 昂

1.项目概述

1.1 项目背景

随着公司“十三五”信息化规划的总体推进，公司逐步建成和完善“两级调控、三层检修、一体化运行、全业务支撑”的信息通信运维体系(SG-ITOM3.0)。同时，公司完成了运行维护-信息通信一体化调度运行支撑平台（I6000）（四期）的建设，为公司电力信息运维工作提供了强大的支撑，保障了电网信息系统的稳定运行、高效运转、全面支撑公司生产经营管理。在此期间，虽然电力信息通信技术得到了极快的发展，但是仍存在不足。支撑信息通信业务进一步融合发展，提升信息通信的运维管理水平，本项目在信息通信一体化调度运行支撑平台基础上，研究信息通信运行数据自主采集、故障检测、风险预警、自动化运维及辅助决策等关键技术，并开发原型系统，通过构建统一的信息通信融合模型和自主标准化采集框架，提出信息通信运行故障监测与风险预警算法，实现信息通信业务系统的智能运维和主动检修，提高信息运维水平、提高信息通信运检效率，保障信息通信系统的运行质量和服务质量。

1.2 项目目标

随着坚强智能电网建设深入开展，信息通信系统作为国家电网公司智能电网重要技术支撑和手段，面临着新的问题和挑战，业务应用需求主要表现在运行数据越来越繁杂多样，运行管理必须从被动向主动转变，提供科学智能的趋势预测和主动预警，研究信息通信运行主动辅助决策技术，实现信息系统运维及部署的自动化，特别是版本升级的部署自动化，将运维人员从机械的、枯燥的可自动化完成的工作中解放出来，有效提高信息系统运维效率，降低运维成本，提升运维服务的质量，减少信息系统版本升级时带来的风险。

通过本项目的实施，进一步支撑“两级调度、三层检修、一体化运行”的调运体系建设要求，实现对信息通信系统的集中管控、精益管理、高效运作，全面支撑坚强智能电网和“三集五大”管理体系建设。

1.3 项目研究内容

本课题主要研究业务系统智能化运维关键技术，包括研究信息系统版本自动升级的管理方法、技术规范；研究信息系统版本升级时数据库脚本自动传输、执行、回滚、执行成功验证技术；研究信息系统程序的自动传输、部署、回退、部署成功验证技术；研究支撑信息系统多级部署的集中式版本自动升级管理技术平台，集中管理各类信息通信系统的版本自动升级。

2.系统自动升级技术设计

2.1 总体架构

系统的总统架构如下图所示：

图2 -1 系统总体架构

通过系统的总体架构设计，利用好Docker容器技术、自动构建技术及Kubernetes技术实现应用系统从开发、测试、部署到升级的全过程自动化。系统研发人员利用Docker容器实现代码的快速更新和部署，测试人员利用Docker容器的易复制性，能时刻保持和开发环境的一致，及时反馈测试结果。利用自动代码构建工具保持代码的持续发布，通过搭建镜像服务器，将应用系统代码以镜像的方式存储在镜像仓库中，现场人员即可通过镜像仓库快速部署系统，并利用Kubernetes技术实现对容器的集群化管理，快速地更新应用、扩展应用节点，保持系统的高可用性。

2.2 数据架构

数据架构中数据技术分类和数据部署设计，分别解决每一方面的关键问题，同时又相互支撑，互为补充，形成一个统一、有机的整体数据架构。数据技术分类和数据部署设计在数据模型的基础上展开，按照不同的数据分类，结合系统架构的要求进行数据部署设计。

数据架构分类设计是基于信息系统版本的自动升级处理实践，从设计角度将信息系统升级所需要的数据进行具体分类，并针对不同设计类别的数据特性采用不同的存储方式和处理方式，以保证系统的处理性能、灵活性和可扩展性。

2.3 关键技术

在版本升级过程中，对于数据库和程序很显然需要考虑成功之后的验证，以及未成功时的回退，尤其是回退如果不成功，将会影响到系统的正常访问，这首先需要一套切实可行的规范的管理机制和流程，其次对于一个集中的版本管理平台而言，如何统一规划实现不同的信息通信系统通过数据库脚本实现自动传输、执行、回滚、执行成功验证，以及信息系统程序的自动传输、部署、回退、部署成功验证，这是本科技课题的研究重点之一。

2.3.1 容器技术

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。Docker 容器通过 Docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。

Docker采用 C/S架构 Docker daemon 作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。 客户端和服务端既可以运行在一个机器上，也可通过 socket 或者RESTful API 来进行通信。

Docker daemon 一般在宿主主机后台运行，等待接收来自客户端的消息。 Docker 客户端则为用户提供一系列可执行命令，用户用这些命令实现跟 Docker daemon 交互。

2.3.2 Linux Namespace

LXC所实现的隔离性主要是来自kernel的namespace, 其中pid,net, ipc, mnt, uts 等namespace将container的进程, 网络, 消息, 文件系统和hostname 隔离开。

2.3.3 Control Groups

cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单，提供类似文件的接口，在 /cgroup目录下新建一个文件夹即可新建一个group，在此文件夹中新建task文件，并将pid写入该文件，即可实现对该进程的资源控制。

2.3.4 AUFS

AUFS (AnotherUnionFS) 是一种 Union FS, 简单来说就是支持将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)的文件系统，更进一步地，AUFS支持为每一个成员目录(AKA branch)设定'readonly', 'readwrite' 和 'whiteout-able' 权限,同时AUFS里有一个类似分层的概念, 对 readonly 权限的branch可以逻辑上进行修改(增量地，不影响readonly部分的)。通常 Union FS有两个用途, 一方面可以实现不借助 LVM， RAID 将多个disk和挂在到一个目录下，另一个更常用的就是将一个readonly的branch和一个writeable的branch联合在一起，Live CD正是基于此可以允许在OS image不变的基础上允许用户在其上进行一些写操作。

3.系统自动升级技术实现

3.1 基础镜像管理

Docker是Docker.Inc公司开源的一个基于轻量级虚拟化技术的容器引擎项目，整个项目基于Go语言开发，并遵从Apache 2.0协议。通过分层镜像标准化和内核虚拟化技术，Docker使得应用开发者和运维工程师可以以统一的方式跨平台发布应用，并且以几乎没有额外开销的情况下提供资源隔离的应用运行环境。

镜像（Image）就是一堆只读层（read-only layer）的统一视角，下面的这张图展示了镜像的定义。

图3 -1 镜像示意图

从左边我们看到了多个只读层，它们重叠在一起。除了最下面一层，其它层都会有一个指针指向下一层。这些层是Docker内部的实现细节，并且能够在主机（注：运行Docker的机器）的文件系统上访问到。统一文件系统（union file system）技术能够将不同的层整合成一个文件系统，为这些层提供了一个统一的视角，这样就隐藏了多层的存在，在用户的角度看来，只存在一个文件系统。 我们可以在图片的右边看到这个视角的形式。

3.2 应用镜像管理

（1）应用封装

应用封装采用Docker做为应用容器引擎，Docker是轻量级虚拟化技术，它在标准的LXC之上融合AUFS分层镜像管理机制，并以应用为单元进行“集装封箱”，实现的相关应用封装能力如下：

1）Docker容器技术可以部署应用到可移植的的容器中，这些容器独立于硬件、语言、框架、打包系统，帮助实现持续集成与部署。一个标准的Docker容器包含一个软件组件及其所有的依赖，包括二进制文件、库、配置文件、脚本等。

2）Docker容器可以封装任何有效负载，可以在任何服务器之间进行一致性运行。开发者构建的应用只需一次构建即可多平台运行。

（2）应用镜像管理

将应用进行封装后，得到应用镜像，和基础镜像类似，需要对应用镜像进行统一的管理。

3.3 镜像仓库管理

Docker镜像（Image）类似于虚拟机的镜像，可以将他理解为一个面向Docker引擎的只读模板，包含了文件系统。镜像是创建Docker容器的基础，通过版本管理和增量的文件系统，Docker提供了一套十分简单的机制来创建和更新现有的镜像。镜像仓库是Docker集中存放镜像文件的场所。

3.4 应用发布管理

用户直接指定相关版本的应用镜像进行部署或升级，成功后，对应用的发布结果进行验证，对验证不通过的应用直接指定原版本镜像进行回滚和还原。整个升级过程就是对应用镜像的复制和运行，从而实现信息系统的快速部署，保证生产环境、测试环境和开发环境的一致。

3.5 应用升级/回滚管理

应用发布完成后，用户可根据应用的版本进行升级或回滚，所用的kubernetes的命令为kubectl rolling-update。

kubectl rolling-update是一个非常重要的命令，对于已经部署并且正在运行的业务，rolling-update提供了不中断业务的更新方式。rolling-update每次起一个新的pod，等新pod完全起来后删除一个旧的pod，然后再起一个新的pod替换旧的pod，直到替换掉所有的pod。rolling-update需要确保新的版本有不同的name，Version和label，否则会报错 。

3.6 应用扩容/缩容管理

应用发布完成后，应用的节点可根据需要或资源负荷进行调节，即为应用的扩容/缩容。所用的kubernetes的命令为kubectl scale。

Kubectl scale用于程序在负载加重或缩小时副本进行扩容或缩小，如前面创建的nginx有两个副本，可以轻松的使用scale命令对副本数进行扩展或缩小。

图3 -8 与I6000系统的集成

3.7 数据库升级管理

信息系统版本自动升级完成后，若需要对数据库进行相关升级，可首先对数据库进行备份，然后执行升级脚本，对升级后的数据库进行验证，若升级失败，则利用数据库备份文件进行还原，实现数据库的远程自动化升级。

3.8 应用集成（图3-8）

由于自动化部署系统采用B/S结构，产品本身提供丰富的Webservice接口/JMS接口，通过接口调用的方式，可实现与I6000系统的数据集成。自动化部署系统还提供Webservice接口/JMS接口来提取/发布包括应用系统信息、数据库信息等在内的数据，自动化部署系统可通过调用相关接口来读取I6000系统的基础数据来实现同步与更新。

自动化部署系统对设备的管理有其自身的特点，初次进行设备纳管时需以I6000系统中资源管理模块（CMDB）为准提取IP、OS/IOS版本等基本配置信息。在日常运维中，系统定时进行设备信息采集，则以系统所搜集设备信息为准，对I6000中资源管理模块（CMDB）进行同步与更新，对其数据项进行补充与更新，从而保证信息的完整与准确。

3.9 接口清单

对基础镜像和应用镜像进行版本管理。基础镜像主要用于存储信息系统运行所需的运行时库（如JRE、.NETFramework等）和中间件（Tomcat、Weblogic等）的镜像文件；应用镜像主要用于存储信息系统软件的镜像文件。

4.结论及建议

4.1 结论

实现信息系统运维及部署的版本自动化升级部署，将运维人员从机械的、枯燥的可自动化完成的工作中解放出来，有效提高信息系统运维效率，降低运维成本，提升运维服务的质量，减少信息系统版本升级时带来的风险。

4.2 建议

工具化和标准化的运用程度是运维自动化发展水平提升的重要体现，逐步构建物理设备层、操作系统层、应用服务层、运维操作层的标准运维体系，实现以下目标∶

（1）运维自动化发展工具化：设计和利用各种小工具，促进标准化的实施，将可重复的操作简单化，将多次操作流程化，减少人为操作的低效，降低故障率。

（2）运维自动化发展web化：设计研发完善的运维工作平台，具备完善的权限控制，完备的日志记录，弱化流程，实现统一平台，标准化作业。

（3）运维自动化发展服务化（api化）：根据4层标准化运维体系，逐步设计和完善API，实现运维操作API化。

（4）运维自动化发展智能化：建立和完善触发机制和决策系统（网络神经系统），初步实现智能化的自动扩容、缩容、故障自愈等。

版本自动化升级仅仅是运维自动化发展的其中一点，更多的是以此为起点探索运维自动化发展的广阔前景。运维自动化未来的发展方向是智能运维，随着智能化技术的发展，智能运维的呼声越来越高，目前国内智能运维发展还处于一个探索阶段，要想尽快在智能运维领域有所突破，首先要主抓好监控系统和告警系统，并利用机器学习算法进行快速监控和排障。智能运维的发展一定是一个长期演进的过程，需要大量的投入和学习。