國網(wǎng)寧夏電力有限公司信通公司 劉思堯 李雪松

安徽繼遠(yuǎn)軟件有限公司 李 昂

1.項(xiàng)目概述

1.1 項(xiàng)目背景

隨著公司“十三五”信息化規(guī)劃的總體推進(jìn)，公司逐步建成和完善“兩級(jí)調(diào)控、三層檢修、一體化運(yùn)行、全業(yè)務(wù)支撐”的信息通信運(yùn)維體系(SG-ITOM3.0)。同時(shí)，公司完成了運(yùn)行維護(hù)-信息通信一體化調(diào)度運(yùn)行支撐平臺(tái)（I6000）（四期）的建設(shè)，為公司電力信息運(yùn)維工作提供了強(qiáng)大的支撐，保障了電網(wǎng)信息系統(tǒng)的穩(wěn)定運(yùn)行、高效運(yùn)轉(zhuǎn)、全面支撐公司生產(chǎn)經(jīng)營管理。在此期間，雖然電力信息通信技術(shù)得到了極快的發(fā)展，但是仍存在不足。支撐信息通信業(yè)務(wù)進(jìn)一步融合發(fā)展，提升信息通信的運(yùn)維管理水平，本項(xiàng)目在信息通信一體化調(diào)度運(yùn)行支撐平臺(tái)基礎(chǔ)上，研究信息通信運(yùn)行數(shù)據(jù)自主采集、故障檢測、風(fēng)險(xiǎn)預(yù)警、自動(dòng)化運(yùn)維及輔助決策等關(guān)鍵技術(shù)，并開發(fā)原型系統(tǒng)，通過構(gòu)建統(tǒng)一的信息通信融合模型和自主標(biāo)準(zhǔn)化采集框架，提出信息通信運(yùn)行故障監(jiān)測與風(fēng)險(xiǎn)預(yù)警算法，實(shí)現(xiàn)信息通信業(yè)務(wù)系統(tǒng)的智能運(yùn)維和主動(dòng)檢修，提高信息運(yùn)維水平、提高信息通信運(yùn)檢效率，保障信息通信系統(tǒng)的運(yùn)行質(zhì)量和服務(wù)質(zhì)量。

1.2 項(xiàng)目目標(biāo)

隨著堅(jiān)強(qiáng)智能電網(wǎng)建設(shè)深入開展，信息通信系統(tǒng)作為國家電網(wǎng)公司智能電網(wǎng)重要技術(shù)支撐和手段，面臨著新的問題和挑戰(zhàn)，業(yè)務(wù)應(yīng)用需求主要表現(xiàn)在運(yùn)行數(shù)據(jù)越來越繁雜多樣，運(yùn)行管理必須從被動(dòng)向主動(dòng)轉(zhuǎn)變，提供科學(xué)智能的趨勢預(yù)測和主動(dòng)預(yù)警，研究信息通信運(yùn)行主動(dòng)輔助決策技術(shù)，實(shí)現(xiàn)信息系統(tǒng)運(yùn)維及部署的自動(dòng)化，特別是版本升級(jí)的部署自動(dòng)化，將運(yùn)維人員從機(jī)械的、枯燥的可自動(dòng)化完成的工作中解放出來，有效提高信息系統(tǒng)運(yùn)維效率，降低運(yùn)維成本，提升運(yùn)維服務(wù)的質(zhì)量，減少信息系統(tǒng)版本升級(jí)時(shí)帶來的風(fēng)險(xiǎn)。

通過本項(xiàng)目的實(shí)施，進(jìn)一步支撐“兩級(jí)調(diào)度、三層檢修、一體化運(yùn)行”的調(diào)運(yùn)體系建設(shè)要求，實(shí)現(xiàn)對信息通信系統(tǒng)的集中管控、精益管理、高效運(yùn)作，全面支撐堅(jiān)強(qiáng)智能電網(wǎng)和“三集五大”管理體系建設(shè)。

1.3 項(xiàng)目研究內(nèi)容

本課題主要研究業(yè)務(wù)系統(tǒng)智能化運(yùn)維關(guān)鍵技術(shù)，包括研究信息系統(tǒng)版本自動(dòng)升級(jí)的管理方法、技術(shù)規(guī)范；研究信息系統(tǒng)版本升級(jí)時(shí)數(shù)據(jù)庫腳本自動(dòng)傳輸、執(zhí)行、回滾、執(zhí)行成功驗(yàn)證技術(shù)；研究信息系統(tǒng)程序的自動(dòng)傳輸、部署、回退、部署成功驗(yàn)證技術(shù)；研究支撐信息系統(tǒng)多級(jí)部署的集中式版本自動(dòng)升級(jí)管理技術(shù)平臺(tái)，集中管理各類信息通信系統(tǒng)的版本自動(dòng)升級(jí)。

2.系統(tǒng)自動(dòng)升級(jí)技術(shù)設(shè)計(jì)

2.1 總體架構(gòu)

系統(tǒng)的總統(tǒng)架構(gòu)如下圖所示：

圖2 -1 系統(tǒng)總體架構(gòu)

通過系統(tǒng)的總體架構(gòu)設(shè)計(jì)，利用好Docker容器技術(shù)、自動(dòng)構(gòu)建技術(shù)及Kubernetes技術(shù)實(shí)現(xiàn)應(yīng)用系統(tǒng)從開發(fā)、測試、部署到升級(jí)的全過程自動(dòng)化。系統(tǒng)研發(fā)人員利用Docker容器實(shí)現(xiàn)代碼的快速更新和部署，測試人員利用Docker容器的易復(fù)制性，能時(shí)刻保持和開發(fā)環(huán)境的一致，及時(shí)反饋測試結(jié)果。利用自動(dòng)代碼構(gòu)建工具保持代碼的持續(xù)發(fā)布，通過搭建鏡像服務(wù)器，將應(yīng)用系統(tǒng)代碼以鏡像的方式存儲(chǔ)在鏡像倉庫中，現(xiàn)場人員即可通過鏡像倉庫快速部署系統(tǒng)，并利用Kubernetes技術(shù)實(shí)現(xiàn)對容器的集群化管理，快速地更新應(yīng)用、擴(kuò)展應(yīng)用節(jié)點(diǎn)，保持系統(tǒng)的高可用性。

2.2 數(shù)據(jù)架構(gòu)

數(shù)據(jù)架構(gòu)中數(shù)據(jù)技術(shù)分類和數(shù)據(jù)部署設(shè)計(jì)，分別解決每一方面的關(guān)鍵問題，同時(shí)又相互支撐，互為補(bǔ)充，形成一個(gè)統(tǒng)一、有機(jī)的整體數(shù)據(jù)架構(gòu)。數(shù)據(jù)技術(shù)分類和數(shù)據(jù)部署設(shè)計(jì)在數(shù)據(jù)模型的基礎(chǔ)上展開，按照不同的數(shù)據(jù)分類，結(jié)合系統(tǒng)架構(gòu)的要求進(jìn)行數(shù)據(jù)部署設(shè)計(jì)。

數(shù)據(jù)架構(gòu)分類設(shè)計(jì)是基于信息系統(tǒng)版本的自動(dòng)升級(jí)處理實(shí)踐，從設(shè)計(jì)角度將信息系統(tǒng)升級(jí)所需要的數(shù)據(jù)進(jìn)行具體分類，并針對不同設(shè)計(jì)類別的數(shù)據(jù)特性采用不同的存儲(chǔ)方式和處理方式，以保證系統(tǒng)的處理性能、靈活性和可擴(kuò)展性。

2.3 關(guān)鍵技術(shù)

在版本升級(jí)過程中，對于數(shù)據(jù)庫和程序很顯然需要考慮成功之后的驗(yàn)證，以及未成功時(shí)的回退，尤其是回退如果不成功，將會(huì)影響到系統(tǒng)的正常訪問，這首先需要一套切實(shí)可行的規(guī)范的管理機(jī)制和流程，其次對于一個(gè)集中的版本管理平臺(tái)而言，如何統(tǒng)一規(guī)劃實(shí)現(xiàn)不同的信息通信系統(tǒng)通過數(shù)據(jù)庫腳本實(shí)現(xiàn)自動(dòng)傳輸、執(zhí)行、回滾、執(zhí)行成功驗(yàn)證，以及信息系統(tǒng)程序的自動(dòng)傳輸、部署、回退、部署成功驗(yàn)證，這是本科技課題的研究重點(diǎn)之一。

2.3.1 容器技術(shù)

Docker 是一個(gè)開源的應(yīng)用容器引擎，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個(gè)可移植的容器中，然后發(fā)布到任何流行的Linux 機(jī)器上，也可以實(shí)現(xiàn)虛擬化。容器是完全使用沙箱機(jī)制，相互之間不會(huì)有任何接口。

Docker 使用客戶端-服務(wù)器 (C/S) 架構(gòu)模式，使用遠(yuǎn)程API來管理和創(chuàng)建Docker容器。Docker 容器通過 Docker 鏡像來創(chuàng)建。容器與鏡像的關(guān)系類似于面向?qū)ο缶幊讨械膶ο笈c類。

Docker采用 C/S架構(gòu) Docker daemon 作為服務(wù)端接受來自客戶的請求，并處理這些請求（創(chuàng)建、運(yùn)行、分發(fā)容器）。 客戶端和服務(wù)端既可以運(yùn)行在一個(gè)機(jī)器上，也可通過 socket 或者RESTful API 來進(jìn)行通信。

Docker daemon 一般在宿主主機(jī)后臺(tái)運(yùn)行，等待接收來自客戶端的消息。 Docker 客戶端則為用戶提供一系列可執(zhí)行命令，用戶用這些命令實(shí)現(xiàn)跟 Docker daemon 交互。

2.3.2 Linux Namespace

LXC所實(shí)現(xiàn)的隔離性主要是來自kernel的namespace, 其中pid,net, ipc, mnt, uts 等namespace將container的進(jìn)程, 網(wǎng)絡(luò), 消息, 文件系統(tǒng)和hostname 隔離開。

2.3.3 Control Groups

cgroups 實(shí)現(xiàn)了對資源的配額和度量。 cgroups 的使用非常簡單，提供類似文件的接口，在 /cgroup目錄下新建一個(gè)文件夾即可新建一個(gè)group，在此文件夾中新建task文件，并將pid寫入該文件，即可實(shí)現(xiàn)對該進(jìn)程的資源控制。

2.3.4 AUFS

AUFS (AnotherUnionFS) 是一種 Union FS, 簡單來說就是支持將不同目錄掛載到同一個(gè)虛擬文件系統(tǒng)下(unite several directories into a single virtual filesystem)的文件系統(tǒng)，更進(jìn)一步地，AUFS支持為每一個(gè)成員目錄(AKA branch)設(shè)定'readonly', 'readwrite' 和 'whiteout-able' 權(quán)限,同時(shí)AUFS里有一個(gè)類似分層的概念, 對 readonly 權(quán)限的branch可以邏輯上進(jìn)行修改(增量地，不影響readonly部分的)。通常 Union FS有兩個(gè)用途, 一方面可以實(shí)現(xiàn)不借助 LVM， RAID 將多個(gè)disk和掛在到一個(gè)目錄下，另一個(gè)更常用的就是將一個(gè)readonly的branch和一個(gè)writeable的branch聯(lián)合在一起，Live CD正是基于此可以允許在OS image不變的基礎(chǔ)上允許用戶在其上進(jìn)行一些寫操作。

3.系統(tǒng)自動(dòng)升級(jí)技術(shù)實(shí)現(xiàn)

3.1 基礎(chǔ)鏡像管理

Docker是Docker.Inc公司開源的一個(gè)基于輕量級(jí)虛擬化技術(shù)的容器引擎項(xiàng)目，整個(gè)項(xiàng)目基于Go語言開發(fā)，并遵從Apache 2.0協(xié)議。通過分層鏡像標(biāo)準(zhǔn)化和內(nèi)核虛擬化技術(shù)，Docker使得應(yīng)用開發(fā)者和運(yùn)維工程師可以以統(tǒng)一的方式跨平臺(tái)發(fā)布應(yīng)用，并且以幾乎沒有額外開銷的情況下提供資源隔離的應(yīng)用運(yùn)行環(huán)境。

鏡像（Image）就是一堆只讀層（read-only layer）的統(tǒng)一視角，下面的這張圖展示了鏡像的定義。

圖3 -1 鏡像示意圖

從左邊我們看到了多個(gè)只讀層，它們重疊在一起。除了最下面一層，其它層都會(huì)有一個(gè)指針指向下一層。這些層是Docker內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)，并且能夠在主機(jī)（注：運(yùn)行Docker的機(jī)器）的文件系統(tǒng)上訪問到。統(tǒng)一文件系統(tǒng)（union file system）技術(shù)能夠?qū)⒉煌膶诱铣梢粋€(gè)文件系統(tǒng)，為這些層提供了一個(gè)統(tǒng)一的視角，這樣就隱藏了多層的存在，在用戶的角度看來，只存在一個(gè)文件系統(tǒng)。 我們可以在圖片的右邊看到這個(gè)視角的形式。

3.2 應(yīng)用鏡像管理

（1）應(yīng)用封裝

應(yīng)用封裝采用Docker做為應(yīng)用容器引擎，Docker是輕量級(jí)虛擬化技術(shù)，它在標(biāo)準(zhǔn)的LXC之上融合AUFS分層鏡像管理機(jī)制，并以應(yīng)用為單元進(jìn)行“集裝封箱”，實(shí)現(xiàn)的相關(guān)應(yīng)用封裝能力如下：

1）Docker容器技術(shù)可以部署應(yīng)用到可移植的的容器中，這些容器獨(dú)立于硬件、語言、框架、打包系統(tǒng)，幫助實(shí)現(xiàn)持續(xù)集成與部署。一個(gè)標(biāo)準(zhǔn)的Docker容器包含一個(gè)軟件組件及其所有的依賴，包括二進(jìn)制文件、庫、配置文件、腳本等。

2）Docker容器可以封裝任何有效負(fù)載，可以在任何服務(wù)器之間進(jìn)行一致性運(yùn)行。開發(fā)者構(gòu)建的應(yīng)用只需一次構(gòu)建即可多平臺(tái)運(yùn)行。

（2）應(yīng)用鏡像管理

將應(yīng)用進(jìn)行封裝后，得到應(yīng)用鏡像，和基礎(chǔ)鏡像類似，需要對應(yīng)用鏡像進(jìn)行統(tǒng)一的管理。

3.3 鏡像倉庫管理

Docker鏡像（Image）類似于虛擬機(jī)的鏡像，可以將他理解為一個(gè)面向Docker引擎的只讀模板，包含了文件系統(tǒng)。鏡像是創(chuàng)建Docker容器的基礎(chǔ)，通過版本管理和增量的文件系統(tǒng)，Docker提供了一套十分簡單的機(jī)制來創(chuàng)建和更新現(xiàn)有的鏡像。鏡像倉庫是Docker集中存放鏡像文件的場所。

3.4 應(yīng)用發(fā)布管理

用戶直接指定相關(guān)版本的應(yīng)用鏡像進(jìn)行部署或升級(jí)，成功后，對應(yīng)用的發(fā)布結(jié)果進(jìn)行驗(yàn)證，對驗(yàn)證不通過的應(yīng)用直接指定原版本鏡像進(jìn)行回滾和還原。整個(gè)升級(jí)過程就是對應(yīng)用鏡像的復(fù)制和運(yùn)行，從而實(shí)現(xiàn)信息系統(tǒng)的快速部署，保證生產(chǎn)環(huán)境、測試環(huán)境和開發(fā)環(huán)境的一致。

3.5 應(yīng)用升級(jí)/回滾管理

應(yīng)用發(fā)布完成后，用戶可根據(jù)應(yīng)用的版本進(jìn)行升級(jí)或回滾，所用的kubernetes的命令為kubectl rolling-update。

kubectl rolling-update是一個(gè)非常重要的命令，對于已經(jīng)部署并且正在運(yùn)行的業(yè)務(wù)，rolling-update提供了不中斷業(yè)務(wù)的更新方式。rolling-update每次起一個(gè)新的pod，等新pod完全起來后刪除一個(gè)舊的pod，然后再起一個(gè)新的pod替換舊的pod，直到替換掉所有的pod。rolling-update需要確保新的版本有不同的name，Version和label，否則會(huì)報(bào)錯(cuò) 。

3.6 應(yīng)用擴(kuò)容/縮容管理

應(yīng)用發(fā)布完成后，應(yīng)用的節(jié)點(diǎn)可根據(jù)需要或資源負(fù)荷進(jìn)行調(diào)節(jié)，即為應(yīng)用的擴(kuò)容/縮容。所用的kubernetes的命令為kubectl scale。

Kubectl scale用于程序在負(fù)載加重或縮小時(shí)副本進(jìn)行擴(kuò)容或縮小，如前面創(chuàng)建的nginx有兩個(gè)副本，可以輕松的使用scale命令對副本數(shù)進(jìn)行擴(kuò)展或縮小。

圖3 -8 與I6000系統(tǒng)的集成

3.7 數(shù)據(jù)庫升級(jí)管理

信息系統(tǒng)版本自動(dòng)升級(jí)完成后，若需要對數(shù)據(jù)庫進(jìn)行相關(guān)升級(jí)，可首先對數(shù)據(jù)庫進(jìn)行備份，然后執(zhí)行升級(jí)腳本，對升級(jí)后的數(shù)據(jù)庫進(jìn)行驗(yàn)證，若升級(jí)失敗，則利用數(shù)據(jù)庫備份文件進(jìn)行還原，實(shí)現(xiàn)數(shù)據(jù)庫的遠(yuǎn)程自動(dòng)化升級(jí)。

3.8 應(yīng)用集成（圖3-8）

由于自動(dòng)化部署系統(tǒng)采用B/S結(jié)構(gòu)，產(chǎn)品本身提供豐富的Webservice接口/JMS接口，通過接口調(diào)用的方式，可實(shí)現(xiàn)與I6000系統(tǒng)的數(shù)據(jù)集成。自動(dòng)化部署系統(tǒng)還提供Webservice接口/JMS接口來提取/發(fā)布包括應(yīng)用系統(tǒng)信息、數(shù)據(jù)庫信息等在內(nèi)的數(shù)據(jù)，自動(dòng)化部署系統(tǒng)可通過調(diào)用相關(guān)接口來讀取I6000系統(tǒng)的基礎(chǔ)數(shù)據(jù)來實(shí)現(xiàn)同步與更新。

自動(dòng)化部署系統(tǒng)對設(shè)備的管理有其自身的特點(diǎn)，初次進(jìn)行設(shè)備納管時(shí)需以I6000系統(tǒng)中資源管理模塊（CMDB）為準(zhǔn)提取IP、OS/IOS版本等基本配置信息。在日常運(yùn)維中，系統(tǒng)定時(shí)進(jìn)行設(shè)備信息采集，則以系統(tǒng)所搜集設(shè)備信息為準(zhǔn)，對I6000中資源管理模塊（CMDB）進(jìn)行同步與更新，對其數(shù)據(jù)項(xiàng)進(jìn)行補(bǔ)充與更新，從而保證信息的完整與準(zhǔn)確。

3.9 接口清單

對基礎(chǔ)鏡像和應(yīng)用鏡像進(jìn)行版本管理?；A(chǔ)鏡像主要用于存儲(chǔ)信息系統(tǒng)運(yùn)行所需的運(yùn)行時(shí)庫（如JRE、.NETFramework等）和中間件（Tomcat、Weblogic等）的鏡像文件；應(yīng)用鏡像主要用于存儲(chǔ)信息系統(tǒng)軟件的鏡像文件。

4.結(jié)論及建議

4.1 結(jié)論

實(shí)現(xiàn)信息系統(tǒng)運(yùn)維及部署的版本自動(dòng)化升級(jí)部署，將運(yùn)維人員從機(jī)械的、枯燥的可自動(dòng)化完成的工作中解放出來，有效提高信息系統(tǒng)運(yùn)維效率，降低運(yùn)維成本，提升運(yùn)維服務(wù)的質(zhì)量，減少信息系統(tǒng)版本升級(jí)時(shí)帶來的風(fēng)險(xiǎn)。

4.2 建議

工具化和標(biāo)準(zhǔn)化的運(yùn)用程度是運(yùn)維自動(dòng)化發(fā)展水平提升的重要體現(xiàn)，逐步構(gòu)建物理設(shè)備層、操作系統(tǒng)層、應(yīng)用服務(wù)層、運(yùn)維操作層的標(biāo)準(zhǔn)運(yùn)維體系，實(shí)現(xiàn)以下目標(biāo)∶

（1）運(yùn)維自動(dòng)化發(fā)展工具化：設(shè)計(jì)和利用各種小工具，促進(jìn)標(biāo)準(zhǔn)化的實(shí)施，將可重復(fù)的操作簡單化，將多次操作流程化，減少人為操作的低效，降低故障率。

（2）運(yùn)維自動(dòng)化發(fā)展web化：設(shè)計(jì)研發(fā)完善的運(yùn)維工作平臺(tái)，具備完善的權(quán)限控制，完備的日志記錄，弱化流程，實(shí)現(xiàn)統(tǒng)一平臺(tái)，標(biāo)準(zhǔn)化作業(yè)。

（3）運(yùn)維自動(dòng)化發(fā)展服務(wù)化（api化）：根據(jù)4層標(biāo)準(zhǔn)化運(yùn)維體系，逐步設(shè)計(jì)和完善API，實(shí)現(xiàn)運(yùn)維操作API化。

（4）運(yùn)維自動(dòng)化發(fā)展智能化：建立和完善觸發(fā)機(jī)制和決策系統(tǒng)（網(wǎng)絡(luò)神經(jīng)系統(tǒng)），初步實(shí)現(xiàn)智能化的自動(dòng)擴(kuò)容、縮容、故障自愈等。

版本自動(dòng)化升級(jí)僅僅是運(yùn)維自動(dòng)化發(fā)展的其中一點(diǎn)，更多的是以此為起點(diǎn)探索運(yùn)維自動(dòng)化發(fā)展的廣闊前景。運(yùn)維自動(dòng)化未來的發(fā)展方向是智能運(yùn)維，隨著智能化技術(shù)的發(fā)展，智能運(yùn)維的呼聲越來越高，目前國內(nèi)智能運(yùn)維發(fā)展還處于一個(gè)探索階段，要想盡快在智能運(yùn)維領(lǐng)域有所突破，首先要主抓好監(jiān)控系統(tǒng)和告警系統(tǒng)，并利用機(jī)器學(xué)習(xí)算法進(jìn)行快速監(jiān)控和排障。智能運(yùn)維的發(fā)展一定是一個(gè)長期演進(jìn)的過程，需要大量的投入和學(xué)習(xí)。