周晨曦，張弛，王升杰，郭駿，宮帥

（1.南京南瑞信息通信科技有限公司，南京 210037；2.國(guó)網(wǎng)安徽省電力有限公司信息通信分公司，合肥 230061）

0 引言

電力行業(yè)采用單云多Region技術(shù)領(lǐng)先，架構(gòu)復(fù)雜，全網(wǎng)聯(lián)動(dòng)［1］，對(duì)后續(xù)整體云平臺(tái)管控運(yùn)維工作提出了新的挑戰(zhàn)。云平臺(tái)的技術(shù)領(lǐng)先對(duì)于運(yùn)維人員的技術(shù)深度提出了更高的要求［2］，單云多region技術(shù)領(lǐng)先，短時(shí)期內(nèi)需要大量的運(yùn)維人員技術(shù)支撐，來確保運(yùn)維團(tuán)隊(duì)的技術(shù)深度［3］。用戶長(zhǎng)期的基于云平臺(tái)的技術(shù)支撐能力沉淀。運(yùn)維支持團(tuán)隊(duì)包括總部側(cè)及網(wǎng)省側(cè)，較為分散，很難形成統(tǒng)一有效的知識(shí)技術(shù)體系。影響有效解決運(yùn)維過程中的問題［4］。

基于云平臺(tái)架構(gòu)的復(fù)雜度給平臺(tái)穩(wěn)定性帶來的挑戰(zhàn)［5］，主要表現(xiàn)在以下幾個(gè)方面。日常運(yùn)維過程中，峰值訪問期，將對(duì)中心管控節(jié)點(diǎn)造成壓力。中心管控節(jié)點(diǎn)癱瘓后，將直接影響中心化產(chǎn)品及混合部署產(chǎn)品在全網(wǎng)的使用［6］。中心節(jié)點(diǎn)及各個(gè)單元節(jié)點(diǎn)擴(kuò)容時(shí)，對(duì)中心管控節(jié)點(diǎn)也有所影響，云產(chǎn)品擴(kuò)容前，需要針對(duì)中心管控節(jié)點(diǎn)的現(xiàn)有負(fù)載進(jìn)行評(píng)估［7］。

云產(chǎn)品版本的統(tǒng)一性及一致性的挑戰(zhàn)，根據(jù)一朵云特性［8］，要求全網(wǎng)部署云產(chǎn)品保持相同產(chǎn)品版本。產(chǎn)品版本正偏離或逆偏離的偏差，都將有幾率影響該云產(chǎn)品全網(wǎng)平臺(tái)使用的穩(wěn)定性。

中心節(jié)點(diǎn)與單元節(jié)點(diǎn)的平臺(tái)穩(wěn)定性運(yùn)維責(zé)任劃分的挑戰(zhàn)［9］，全網(wǎng)一朵云，產(chǎn)品部署形態(tài)復(fù)雜，運(yùn)維責(zé)任方眾多，導(dǎo)致日常工作中，總部與網(wǎng)省的工作協(xié)同需要大量溝通，應(yīng)制定統(tǒng)一聯(lián)動(dòng)的運(yùn)維服務(wù)管理流程，做到權(quán)責(zé)利明確劃分。

一云多Region架構(gòu)下云平臺(tái)運(yùn)維的應(yīng)對(duì)，面對(duì)已知的運(yùn)維復(fù)雜度和挑戰(zhàn)［10］，提升云平臺(tái)和數(shù)據(jù)中臺(tái)一體化運(yùn)維效率和整體運(yùn)行穩(wěn)定性，建立有效的總部/網(wǎng)省聯(lián)動(dòng)的一體化運(yùn)維機(jī)制勢(shì)在必行。

1 云平臺(tái)技術(shù)

云平臺(tái)一體化運(yùn)維體系設(shè)計(jì)需要結(jié)合云平臺(tái)的技術(shù)架構(gòu)，云平臺(tái)技術(shù)架構(gòu)主要采用一云多re?gion架構(gòu)。一朵云多區(qū)域（Region）的架構(gòu)設(shè)計(jì)是為了滿足多區(qū)域部署一朵專有云的需求，在架構(gòu)設(shè)計(jì)上分為中心Region和普通Region。一朵云多Region架構(gòu)如圖1所示。

圖1 一朵云多Region架構(gòu)

一朵云，提供統(tǒng)一管控，統(tǒng)一運(yùn)維，以及統(tǒng)一監(jiān)控的能力。一致性，與阿里公共云的架構(gòu)保持一致。

可用性，故障域隔離，當(dāng)中心Region出現(xiàn)故障時(shí)，不影響云平臺(tái)已申請(qǐng)?jiān)茖?shí)例資源的使用。當(dāng)普通Region出現(xiàn)問題的情況下，不影響其他Region的使用。云平臺(tái)提供一套自動(dòng)化數(shù)據(jù)中心管理系統(tǒng)，管理數(shù)據(jù)中心的硬件生命周期與各類靜態(tài)資源，為各種云產(chǎn)品應(yīng)用及服務(wù)提供通用的版本管理、部署、熱升級(jí)方案。每個(gè)Region部署一套管理服務(wù)，管理服務(wù)會(huì)同步中心Region的服務(wù)變量，以供普通Region上的產(chǎn)品或者服務(wù)引用。

2 一體化框架設(shè)計(jì)

依托國(guó)網(wǎng)云平臺(tái)，復(fù)用已有組件能力，構(gòu)建邏輯集中、物理分散、動(dòng)態(tài)分配、統(tǒng)籌利用的研發(fā)仿真環(huán)境，并實(shí)現(xiàn)與生產(chǎn)環(huán)境自動(dòng)化部署。在現(xiàn)有云平臺(tái)劃出部分空間構(gòu)建開發(fā)集成環(huán)境、仿真環(huán)境，因?yàn)榕c生產(chǎn)環(huán)境共用云和數(shù)據(jù)中臺(tái)底座，可以直接使用云和數(shù)據(jù)中臺(tái)的技術(shù)組件，但每個(gè)環(huán)境單獨(dú)生成自己獨(dú)立的實(shí)例，網(wǎng)絡(luò)上與生產(chǎn)環(huán)境相互隔離避免干擾。從資源使用角度看，測(cè)試環(huán)境的節(jié)點(diǎn)消耗與生產(chǎn)環(huán)境消耗比例為1∶8左右，一體化DevOps架構(gòu)圖如圖2所示。

圖2 一體化DevOps架構(gòu)

在現(xiàn)有云平臺(tái)資源中構(gòu)建開發(fā)集成環(huán)境、仿真環(huán)境，生產(chǎn)環(huán)境。開發(fā)集成環(huán)境供開發(fā)團(tuán)隊(duì)開發(fā)及單元測(cè)試、接口測(cè)試、自動(dòng)化聯(lián)調(diào)測(cè)試；仿真環(huán)境支撐第三方測(cè)試、網(wǎng)絡(luò)安全仿真驗(yàn)證（靶場(chǎng)）、基層用戶體驗(yàn)管控測(cè)試及用戶仿真培訓(xùn)；研發(fā)集成環(huán)境及仿真環(huán)境與生產(chǎn)環(huán)境進(jìn)行安全隔離。一體化研發(fā)管控平臺(tái)對(duì)項(xiàng)目開發(fā)提供靈活的接入支撐方式和協(xié)作模式，支持人員集中式開發(fā)、異地分布式協(xié)同開發(fā)、現(xiàn)場(chǎng)駐場(chǎng)開發(fā)等項(xiàng)目組織模式。

2.1 網(wǎng)絡(luò)和資源劃分

對(duì)專有云的VPC進(jìn)行自行定義劃分，每個(gè)VPC都有一個(gè)路由器、至少一個(gè)私網(wǎng)網(wǎng)段和至少一個(gè)交換機(jī)組成。可自行選擇IP地址范圍、配置路由表和網(wǎng)關(guān)等。

在專有云劃分出部分資源進(jìn)行開發(fā)仿真環(huán)境建設(shè)，同時(shí)為了保障生產(chǎn)系統(tǒng)的安全，給開發(fā)仿真環(huán)境劃分一個(gè)專用的VPC，將所有的研發(fā)仿真資源放入該專用VPC中。這樣可以通過對(duì)VPC的路由設(shè)置，隔斷開發(fā)仿真環(huán)境與生產(chǎn)環(huán)境的網(wǎng)絡(luò)訪問，VPC劃分架構(gòu)如圖3所示。

圖3 VPC劃分架構(gòu)

劃分出VPC后，可以將專有網(wǎng)絡(luò)連接到研發(fā)測(cè)試團(tuán)隊(duì)所在本地網(wǎng)絡(luò)，形成一個(gè)按需定制的網(wǎng)絡(luò)環(huán)境，實(shí)現(xiàn)各地開發(fā)人員對(duì)網(wǎng)上統(tǒng)一開發(fā)集成環(huán)境的遠(yuǎn)程訪問。

2.2 資源調(diào)度框架

云計(jì)算平臺(tái)內(nèi)部具有大量的計(jì)算節(jié)點(diǎn)，可以將整個(gè)云計(jì)算平臺(tái)抽象為一個(gè)連接了所有計(jì)算機(jī)的無阻塞大型交換機(jī)。這個(gè)大型交換機(jī)的入口端口對(duì)應(yīng)于服務(wù)器的出口鏈路，而出口端口則對(duì)應(yīng)于服務(wù)器的入口鏈路。通過這種抽象，該模型的優(yōu)勢(shì)在于只需要考慮入口端口和出口端口，便于對(duì)Coflow流量的調(diào)度進(jìn)行分析，且在簡(jiǎn)單且全平分帶寬拓?fù)浣Y(jié)構(gòu)下具有很高的實(shí)用性。E-Aalo資源調(diào)度架構(gòu)如圖4所示，主要包括全局協(xié)調(diào)器和本地守護(hù)進(jìn)程兩個(gè)部分。

圖4 E-Aalo資源調(diào)度架構(gòu)

資源調(diào)度架構(gòu)包括全局協(xié)調(diào)器和本地守護(hù)進(jìn)程，其中全局協(xié)調(diào)器負(fù)責(zé)監(jiān)測(cè)每個(gè)作業(yè)是否產(chǎn)生通信數(shù)據(jù)流，對(duì)產(chǎn)生通信數(shù)據(jù)流的作業(yè)利用流量放置策略，選擇合適的計(jì)算節(jié)點(diǎn)處理每個(gè)通信數(shù)據(jù)流中的流量并生成對(duì)應(yīng)的策略，接著通知發(fā)送節(jié)點(diǎn)將通信數(shù)據(jù)流中的流量從送發(fā)送到選擇的接收節(jié)點(diǎn)。另外，全局協(xié)調(diào)器還接收發(fā)送節(jié)點(diǎn)發(fā)送來的每個(gè)通信數(shù)據(jù)流已發(fā)送的數(shù)據(jù)流相關(guān)的參數(shù)，根據(jù)這些參數(shù)確定不同通信數(shù)據(jù)流的優(yōu)先級(jí)并發(fā)送給本地的守護(hù)進(jìn)程。本地守護(hù)進(jìn)程用來接收全局協(xié)調(diào)器發(fā)送來的通信數(shù)據(jù)流優(yōu)先級(jí)信息，然后在本地的多級(jí)隊(duì)列中對(duì)通信數(shù)據(jù)流進(jìn)行調(diào)度。

2.3 算法實(shí)現(xiàn)

云計(jì)算平臺(tái)將各類任務(wù)分成多個(gè)子任務(wù)進(jìn)行處理，每個(gè)子任務(wù)將被分派放置到不同的主機(jī)上執(zhí)行，相應(yīng)的數(shù)據(jù)也被傳輸?shù)綀?zhí)行任務(wù)的主機(jī)節(jié)點(diǎn)上，帶來更多的數(shù)據(jù)流量傳輸，也導(dǎo)致更大的開銷。若該主機(jī)上原本就存在相應(yīng)的數(shù)據(jù)，就可避免額外的數(shù)據(jù)傳輸開銷，通過對(duì)通信數(shù)據(jù)流中的流量進(jìn)行不同的放置可對(duì)子任務(wù)在不同的主機(jī)上進(jìn)行分配，合理的分配也將會(huì)減少數(shù)據(jù)的傳輸量，降低時(shí)間開銷，提高云數(shù)據(jù)中心的性能，具體云計(jì)算平臺(tái)流量放置調(diào)度如算法1所示。

算法1云計(jì)算平臺(tái)流量放置調(diào)度

輸入:集合Q1,…,Qk對(duì)應(yīng)Cn的k個(gè)數(shù)據(jù)流

輸出:Cn的放置方案M1,…,Mk對(duì)應(yīng)的k個(gè)數(shù)據(jù)量的放置方案

1:for all i from 1 to k do

2:for all j from 1 to m do

4: Qi.push（j）

5: end

6: end

7:end

8:for all i from 1 to k do

9:for all j in Qido

10: Mi←arg minj(Accutj)

11:end

12:end

13:return M1,…,Mk

其中，m表示m個(gè)待選擇的任務(wù)分配計(jì)算節(jié)點(diǎn)；前七行代碼對(duì)通信數(shù)據(jù)流C n中的每個(gè)數(shù)據(jù)流f in篩選出潛在的可以直接執(zhí)行該任務(wù)的計(jì)算節(jié)點(diǎn)；后面代碼則從每個(gè)數(shù)據(jù)流f in的潛在可選節(jié)點(diǎn)中選出網(wǎng)絡(luò)負(fù)載最小的計(jì)算節(jié)點(diǎn)。

3 實(shí)驗(yàn)及結(jié)果

為驗(yàn)證云平臺(tái)一體化框架模型的合理性和有效性，選取故障處理調(diào)度、資源調(diào)度效率兩個(gè)場(chǎng)景進(jìn)行實(shí)驗(yàn)驗(yàn)證。

3.1 故障處理驗(yàn)證

本文選取普通事件處理作為應(yīng)用場(chǎng)景，保障云平臺(tái)團(tuán)隊(duì)對(duì)事件快速高效的響應(yīng)、診斷、定位制定了包括資源分配調(diào)度對(duì)應(yīng)的事件管理流程。確?？焖俑咝У慕鉀Q事件問題，最大限度地減少對(duì)專有云平臺(tái)及云平臺(tái)業(yè)務(wù)的影響，提高整體的服務(wù)質(zhì)量。制定的了事件管理的相應(yīng)流程。具體處理流程如圖5所示。

圖5 云平臺(tái)事件流程

詳細(xì)流程操作如下：服務(wù)臺(tái)接口人負(fù)責(zé)發(fā)起事件處理請(qǐng)求、在工單系統(tǒng)中提交事件、參照產(chǎn)品布署形態(tài)及省份，分派網(wǎng)省側(cè)工單、關(guān)閉此次事件處理流程；網(wǎng)省側(cè)技術(shù)工程師1線負(fù)責(zé)日常監(jiān)控/巡檢，向服務(wù)臺(tái)發(fā)起普通事件處理請(qǐng)求、針對(duì)配置類事件，觸發(fā)網(wǎng)省側(cè)技術(shù)工程師1線普通事件處理流程、參照產(chǎn)品布署形態(tài)及省份，將工單系統(tǒng)中的需求工單分派到網(wǎng)省側(cè)工單；總部需求接口人負(fù)責(zé)需求類事件，觸發(fā)需求處理流程；總部技術(shù)工程師2線負(fù)責(zé)BUG類事件觸發(fā)BUG處理流程；總部版本接口人負(fù)責(zé)在有a-one號(hào)和工單號(hào)的前提下，啟動(dòng)版本處理流程、收到版本經(jīng)理匯總的出包信息后，觸發(fā)版本處理流程依照配置方案進(jìn)行配置更改操作。

3.2 資源調(diào)度算法驗(yàn)證

E-Aalo調(diào)度主要包括通信數(shù)據(jù)流流量放置和在端口閑置時(shí)提前調(diào)度低優(yōu)先級(jí)隊(duì)列流量，所以設(shè)置的實(shí)驗(yàn)主要包E-Aalo方法和其他通信數(shù)據(jù)流調(diào)度方法的完成時(shí)間對(duì)比。實(shí)驗(yàn)數(shù)據(jù)選取阿里云公開數(shù)據(jù)集進(jìn)行測(cè)試驗(yàn)證，實(shí)驗(yàn)結(jié)果如圖6所示。

圖6 不同調(diào)度算法的完成時(shí)間

通過不同的通信數(shù)據(jù)流調(diào)度方法得到的平均完成時(shí)間對(duì)比可以得出，Varys調(diào)度完數(shù)據(jù)集中1000個(gè)通信數(shù)據(jù)流之后，平均完成時(shí)間為38929.05 ms，是所有對(duì)比方法中效率最優(yōu)的方法，其算法將Aalo中多級(jí)隊(duì)列調(diào)度中的閑置空間加以利用，從而降低平均完成時(shí)間。

4 結(jié)語

本文設(shè)計(jì)一種適應(yīng)電力行業(yè)的云平臺(tái)一體化開發(fā)和資源調(diào)度框架，設(shè)計(jì)了開發(fā)一體化架構(gòu)，給出了網(wǎng)絡(luò)和資源分配方法，結(jié)合云平臺(tái)框架設(shè)計(jì)了通信流量資源調(diào)度算法，通過實(shí)驗(yàn)驗(yàn)證了模型方法額可行性和有效性，下一步將繼續(xù)優(yōu)化完善云平臺(tái)一體化運(yùn)維體系，提升云平臺(tái)運(yùn)維效率。