云平臺一體化開發框架及資源調度

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

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

0 引言

電力行業采用單云多Region技術領先，架構復雜，全網聯動［1］，對后續整體云平臺管控運維工作提出了新的挑戰。云平臺的技術領先對于運維人員的技術深度提出了更高的要求［2］，單云多region技術領先，短時期內需要大量的運維人員技術支撐，來確保運維團隊的技術深度［3］。用戶長期的基于云平臺的技術支撐能力沉淀。運維支持團隊包括總部側及網省側，較為分散，很難形成統一有效的知識技術體系。影響有效解決運維過程中的問題［4］。

基于云平臺架構的復雜度給平臺穩定性帶來的挑戰［5］，主要表現在以下幾個方面。日常運維過程中，峰值訪問期，將對中心管控節點造成壓力。中心管控節點癱瘓后，將直接影響中心化產品及混合部署產品在全網的使用［6］。中心節點及各個單元節點擴容時，對中心管控節點也有所影響，云產品擴容前，需要針對中心管控節點的現有負載進行評估［7］。

云產品版本的統一性及一致性的挑戰，根據一朵云特性［8］，要求全網部署云產品保持相同產品版本。產品版本正偏離或逆偏離的偏差，都將有幾率影響該云產品全網平臺使用的穩定性。

中心節點與單元節點的平臺穩定性運維責任劃分的挑戰［9］，全網一朵云，產品部署形態復雜，運維責任方眾多，導致日常工作中，總部與網省的工作協同需要大量溝通，應制定統一聯動的運維服務管理流程，做到權責利明確劃分。

一云多Region架構下云平臺運維的應對，面對已知的運維復雜度和挑戰［10］，提升云平臺和數據中臺一體化運維效率和整體運行穩定性，建立有效的總部/網省聯動的一體化運維機制勢在必行。

1 云平臺技術

云平臺一體化運維體系設計需要結合云平臺的技術架構，云平臺技術架構主要采用一云多re?gion架構。一朵云多區域（Region）的架構設計是為了滿足多區域部署一朵專有云的需求，在架構設計上分為中心Region和普通Region。一朵云多Region架構如圖1所示。

圖1 一朵云多Region架構

一朵云，提供統一管控，統一運維，以及統一監控的能力。一致性，與阿里公共云的架構保持一致。

可用性，故障域隔離，當中心Region出現故障時，不影響云平臺已申請云實例資源的使用。當普通Region出現問題的情況下，不影響其他Region的使用。云平臺提供一套自動化數據中心管理系統，管理數據中心的硬件生命周期與各類靜態資源，為各種云產品應用及服務提供通用的版本管理、部署、熱升級方案。每個Region部署一套管理服務，管理服務會同步中心Region的服務變量，以供普通Region上的產品或者服務引用。

2 一體化框架設計

依托國網云平臺，復用已有組件能力，構建邏輯集中、物理分散、動態分配、統籌利用的研發仿真環境，并實現與生產環境自動化部署。在現有云平臺劃出部分空間構建開發集成環境、仿真環境，因為與生產環境共用云和數據中臺底座，可以直接使用云和數據中臺的技術組件，但每個環境單獨生成自己獨立的實例，網絡上與生產環境相互隔離避免干擾。從資源使用角度看，測試環境的節點消耗與生產環境消耗比例為1∶8左右，一體化DevOps架構圖如圖2所示。

圖2 一體化DevOps架構

在現有云平臺資源中構建開發集成環境、仿真環境，生產環境。開發集成環境供開發團隊開發及單元測試、接口測試、自動化聯調測試；仿真環境支撐第三方測試、網絡安全仿真驗證（靶場）、基層用戶體驗管控測試及用戶仿真培訓；研發集成環境及仿真環境與生產環境進行安全隔離。一體化研發管控平臺對項目開發提供靈活的接入支撐方式和協作模式，支持人員集中式開發、異地分布式協同開發、現場駐場開發等項目組織模式。

2.1 網絡和資源劃分

對專有云的VPC進行自行定義劃分，每個VPC都有一個路由器、至少一個私網網段和至少一個交換機組成。可自行選擇IP地址范圍、配置路由表和網關等。

在專有云劃分出部分資源進行開發仿真環境建設，同時為了保障生產系統的安全，給開發仿真環境劃分一個專用的VPC，將所有的研發仿真資源放入該專用VPC中。這樣可以通過對VPC的路由設置，隔斷開發仿真環境與生產環境的網絡訪問，VPC劃分架構如圖3所示。

圖3 VPC劃分架構

劃分出VPC后，可以將專有網絡連接到研發測試團隊所在本地網絡，形成一個按需定制的網絡環境，實現各地開發人員對網上統一開發集成環境的遠程訪問。

2.2 資源調度框架

云計算平臺內部具有大量的計算節點，可以將整個云計算平臺抽象為一個連接了所有計算機的無阻塞大型交換機。這個大型交換機的入口端口對應于服務器的出口鏈路，而出口端口則對應于服務器的入口鏈路。通過這種抽象，該模型的優勢在于只需要考慮入口端口和出口端口，便于對Coflow流量的調度進行分析，且在簡單且全平分帶寬拓撲結構下具有很高的實用性。E-Aalo資源調度架構如圖4所示，主要包括全局協調器和本地守護進程兩個部分。

圖4 E-Aalo資源調度架構

資源調度架構包括全局協調器和本地守護進程，其中全局協調器負責監測每個作業是否產生通信數據流，對產生通信數據流的作業利用流量放置策略，選擇合適的計算節點處理每個通信數據流中的流量并生成對應的策略，接著通知發送節點將通信數據流中的流量從送發送到選擇的接收節點。另外，全局協調器還接收發送節點發送來的每個通信數據流已發送的數據流相關的參數，根據這些參數確定不同通信數據流的優先級并發送給本地的守護進程。本地守護進程用來接收全局協調器發送來的通信數據流優先級信息，然后在本地的多級隊列中對通信數據流進行調度。

2.3 算法實現

云計算平臺將各類任務分成多個子任務進行處理，每個子任務將被分派放置到不同的主機上執行，相應的數據也被傳輸到執行任務的主機節點上，帶來更多的數據流量傳輸，也導致更大的開銷。若該主機上原本就存在相應的數據，就可避免額外的數據傳輸開銷，通過對通信數據流中的流量進行不同的放置可對子任務在不同的主機上進行分配，合理的分配也將會減少數據的傳輸量，降低時間開銷，提高云數據中心的性能，具體云計算平臺流量放置調度如算法1所示。

算法1云計算平臺流量放置調度

輸入:集合Q1,…,Qk對應Cn的k個數據流

輸出:Cn的放置方案M1,…,Mk對應的k個數據量的放置方案

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個待選擇的任務分配計算節點；前七行代碼對通信數據流C n中的每個數據流f in篩選出潛在的可以直接執行該任務的計算節點；后面代碼則從每個數據流f in的潛在可選節點中選出網絡負載最小的計算節點。

3 實驗及結果

為驗證云平臺一體化框架模型的合理性和有效性，選取故障處理調度、資源調度效率兩個場景進行實驗驗證。

3.1 故障處理驗證

本文選取普通事件處理作為應用場景，保障云平臺團隊對事件快速高效的響應、診斷、定位制定了包括資源分配調度對應的事件管理流程。確保快速高效的解決事件問題，最大限度地減少對專有云平臺及云平臺業務的影響，提高整體的服務質量。制定的了事件管理的相應流程。具體處理流程如圖5所示。

圖5 云平臺事件流程

詳細流程操作如下：服務臺接口人負責發起事件處理請求、在工單系統中提交事件、參照產品布署形態及省份，分派網省側工單、關閉此次事件處理流程；網省側技術工程師1線負責日常監控/巡檢，向服務臺發起普通事件處理請求、針對配置類事件，觸發網省側技術工程師1線普通事件處理流程、參照產品布署形態及省份，將工單系統中的需求工單分派到網省側工單；總部需求接口人負責需求類事件，觸發需求處理流程；總部技術工程師2線負責BUG類事件觸發BUG處理流程；總部版本接口人負責在有a-one號和工單號的前提下，啟動版本處理流程、收到版本經理匯總的出包信息后，觸發版本處理流程依照配置方案進行配置更改操作。

3.2 資源調度算法驗證

E-Aalo調度主要包括通信數據流流量放置和在端口閑置時提前調度低優先級隊列流量，所以設置的實驗主要包E-Aalo方法和其他通信數據流調度方法的完成時間對比。實驗數據選取阿里云公開數據集進行測試驗證，實驗結果如圖6所示。

圖6 不同調度算法的完成時間

通過不同的通信數據流調度方法得到的平均完成時間對比可以得出，Varys調度完數據集中1000個通信數據流之后，平均完成時間為38929.05 ms，是所有對比方法中效率最優的方法，其算法將Aalo中多級隊列調度中的閑置空間加以利用，從而降低平均完成時間。

4 結語

本文設計一種適應電力行業的云平臺一體化開發和資源調度框架，設計了開發一體化架構，給出了網絡和資源分配方法，結合云平臺框架設計了通信流量資源調度算法，通過實驗驗證了模型方法額可行性和有效性，下一步將繼續優化完善云平臺一體化運維體系，提升云平臺運維效率。