趙宇峰，雷 晟，張國(guó)鋼，耿英三

（西安交通大學(xué) 電力設(shè)備電氣絕緣國(guó)家重點(diǎn)實(shí)驗(yàn)室，西安 710049）

0 概述

隨著電力系統(tǒng)的規(guī)模不斷擴(kuò)大，電網(wǎng)智能化程度不斷提高，對(duì)電力設(shè)備產(chǎn)品的創(chuàng)新也有了更高的要求［1］。新形勢(shì)下，傳統(tǒng)電力設(shè)備設(shè)計(jì)仿真面臨諸多方面的挑戰(zhàn)，而云計(jì)算技術(shù)和虛擬化技術(shù)能較好地解決傳統(tǒng)單機(jī)模式下進(jìn)行仿真所存在的各種問(wèn)題［2-4］?；谠朴?jì)算技術(shù)，云仿真將仿真過(guò)程中使用的計(jì)算資源、存儲(chǔ)資源進(jìn)行虛擬化并放入云端［5］，用戶可以通過(guò)多種設(shè)備接入云仿真平臺(tái)進(jìn)行各項(xiàng)操作，仿真用戶按照計(jì)算時(shí)間來(lái)付費(fèi)，避免產(chǎn)生高性能計(jì)算機(jī)的購(gòu)置費(fèi)用。同時(shí)，云計(jì)算平臺(tái)可以充分發(fā)揮多核處理器的優(yōu)勢(shì)，并根據(jù)集群中的負(fù)載情況自動(dòng)擴(kuò)容和縮容，提高主機(jī)計(jì)算資源的利用效率［6-7］。

國(guó)內(nèi)外學(xué)者對(duì)云計(jì)算進(jìn)行仿真的實(shí)現(xiàn)方法做了很多研究。文獻(xiàn)［8］以云計(jì)算理念為基礎(chǔ)，提出一種網(wǎng)絡(luò)化建模與仿真平臺(tái)——云仿真平臺(tái)。文獻(xiàn)［9］研究虛擬化技術(shù)下云仿真運(yùn)行環(huán)境動(dòng)態(tài)構(gòu)建技術(shù)，提出動(dòng)態(tài)構(gòu)建的三層映射算法。文獻(xiàn)［10］提出一種基于高級(jí)架構(gòu)（High-Level Architecture，HLA）的仿真框架，并通過(guò)軟件即服務(wù)（Software-as-a-Service，SaaS）向用戶提供復(fù)雜系統(tǒng)仿真的支持。文獻(xiàn)［11］研究多租戶架構(gòu)（Multi-Tenancy Architecture，MTA）的云仿真相關(guān)問(wèn)題，并構(gòu)建一個(gè)可以滿足租戶特定要求靈活的云仿真架構(gòu)。文獻(xiàn)［12］將云計(jì)算應(yīng)用到電力仿真之上，設(shè)計(jì)并構(gòu)建高性能的電力仿真平臺(tái)——CloudPSS。

近年來(lái)，云計(jì)算中容器化技術(shù)和容器編排技術(shù)得到了突飛猛進(jìn)的發(fā)展。以Docker 為代表的容器化已逐漸取代傳統(tǒng)使用虛擬機(jī)進(jìn)行操作系統(tǒng)級(jí)別的虛擬，成為虛擬化技術(shù)中新的代表技術(shù)［13-14］。與容器化技術(shù)相對(duì)應(yīng)的容器編排技術(shù)也得到逐步提高，特別是谷歌公司于2014 年開(kāi)源Kubernetes 以來(lái)，該應(yīng)用具有強(qiáng)大的容器管理能力，已成為容器管理領(lǐng)域的事實(shí)標(biāo)準(zhǔn)［15］。Docker 與Kubernetes 的結(jié)合在各領(lǐng)域中得到了應(yīng)用，如氣象［16］、通信［17］等。

隨著相關(guān)技術(shù)的普及，近年來(lái)基于容器化技術(shù)和容器編排技術(shù)的仿真平臺(tái)研究發(fā)展迅速，但在發(fā)展過(guò)程中也同樣存在著許多問(wèn)題。例如，由于底層的物理資源性能條件差異、用戶需求不定，仿真平臺(tái)需要合理分配現(xiàn)有資源，做好資源管理、調(diào)度和動(dòng)態(tài)構(gòu)建的工作。文獻(xiàn)［18］提出基于聚類和改進(jìn)共生演算法的任務(wù)調(diào)度策略，相比傳統(tǒng)的啟發(fā)式調(diào)度算法，其調(diào)度成本更低，但用戶滿意度更高。文獻(xiàn)［19］提出改進(jìn)的協(xié)同優(yōu)化文化基因任務(wù)調(diào)度算法，在循環(huán)中加入?yún)f(xié)同進(jìn)化操作，有效地提高算法的運(yùn)行效率。

除此之外，由于不同行業(yè)中使用的專業(yè)軟件不同，需進(jìn)行仿真的仿真任務(wù)特性也各有差異，云仿真平臺(tái)在具體行業(yè)領(lǐng)域的應(yīng)用過(guò)程中存在問(wèn)題。研究者將云仿真平臺(tái)與已有的TMSR-SF1 工程仿真機(jī)相結(jié)合，實(shí)現(xiàn)了適用于核電仿真的云仿真平臺(tái)［20］。

為解決傳統(tǒng)單機(jī)模式下仿真中存在的問(wèn)題，本文基于Docker 容器技術(shù)和Kubernetes 容器編排技術(shù)，設(shè)計(jì)并開(kāi)發(fā)專用于電力設(shè)備仿真的電力仿真云平臺(tái)，研究該云平臺(tái)的運(yùn)行流程和優(yōu)化調(diào)度策略，提高云平臺(tái)的整體性能和集群主機(jī)計(jì)算資源的利用效率。

1 需求分析

電力設(shè)備仿真云平臺(tái)的功能需求主要有以下5 個(gè)方面：

1）用戶管理。用戶可以進(jìn)行注冊(cè)、登錄等操作，并由云平臺(tái)負(fù)責(zé)進(jìn)行身份驗(yàn)證。用戶在登錄賬戶成功后，即可保持登錄狀態(tài)。除非清除瀏覽器緩存或更換瀏覽器，用戶無(wú)需再次登錄。

2）仿真任務(wù)提交流程管理。云平臺(tái)應(yīng)保證用戶提交的仿真參數(shù)可以準(zhǔn)確無(wú)誤地被應(yīng)用到模板中，并生成用于執(zhí)行仿真任務(wù)的代碼，最終啟動(dòng)仿真進(jìn)程運(yùn)行仿真。

3）仿真進(jìn)程生命周期管理。從仿真進(jìn)程的創(chuàng)建、運(yùn)行和實(shí)時(shí)輸出進(jìn)度日志，再到最終仿真進(jìn)程的結(jié)束并輸出結(jié)果信息或報(bào)錯(cuò)信息，云平臺(tái)都應(yīng)采取合理有效的措施進(jìn)行相關(guān)處理。在整個(gè)流程中，保證可以脫離用戶的參與，完全自主地進(jìn)行生命周期管理，做好隨時(shí)可以供用戶查看仿真進(jìn)度的準(zhǔn)備。

4）仿真日志和結(jié)果文件持久化。仿真云平臺(tái)中應(yīng)存在可以持久化保存數(shù)據(jù)的模塊，用于仿真進(jìn)程運(yùn)行中和之后保存相關(guān)數(shù)據(jù)。

5）用戶交互。用戶通過(guò)用戶界面進(jìn)行各種操作，是用戶與電力設(shè)備仿真云平臺(tái)進(jìn)行交互的唯一接口。

此外，在確保實(shí)現(xiàn)各項(xiàng)功能不受影響的情況下，應(yīng)該充分地運(yùn)用合理的調(diào)度算法，采用合適的架構(gòu)設(shè)計(jì)，保證云平臺(tái)可以高效、穩(wěn)定地實(shí)現(xiàn)功能。

2 模塊設(shè)計(jì)與構(gòu)建

2.1 模塊設(shè)計(jì)

電力設(shè)備仿真云平臺(tái)在設(shè)計(jì)過(guò)程中采用模塊化的思想，將具有不同功能的組件單獨(dú)劃分出來(lái)構(gòu)建模塊，并以Docker 容器鏡像的形式應(yīng)用到Kubernetes 所構(gòu)建的云平臺(tái)中。各模塊之間交互主要通過(guò)Kubernetes 提供的Service 資源對(duì)象進(jìn)行通信，并通過(guò)XML-RPC 的數(shù)據(jù)交互協(xié)議對(duì)數(shù)據(jù)交互格式進(jìn)行約定。

經(jīng)過(guò)對(duì)整體功能需求的分析，為保證各模塊之間的高聚合、低耦合關(guān)系，將整個(gè)云平臺(tái)分為4 個(gè)功能模塊，各模塊的功能及交互關(guān)系如圖1 所示。

圖1 云平臺(tái)模塊功能及交互關(guān)系Fig.1 Module functions and interaction relationship of cloud platform

云平臺(tái)模塊主要有：

1）服務(wù)端模塊。服務(wù)端模塊中運(yùn)行Web Service的服務(wù)端程序，該模塊向通過(guò)認(rèn)證的用戶生成并提供用戶界面。此外，服務(wù)端模塊還可以將仿真任務(wù)的參數(shù)傳遞給電力設(shè)備仿真云平臺(tái)的仿真端模塊，并向用戶提供仿真進(jìn)度的查看和仿真結(jié)果的傳回。

2）仿真端模塊。仿真端模塊可以從電力設(shè)備仿真云平臺(tái)的服務(wù)端模塊中接收新建仿真任務(wù)的參數(shù)，并根據(jù)參數(shù)生成仿真任務(wù)。同時(shí)，該模塊還可以監(jiān)聽(tīng)所有正在被運(yùn)行的仿真進(jìn)程，實(shí)時(shí)獲取其仿真狀態(tài)并存入數(shù)據(jù)庫(kù)中。

3）數(shù)據(jù)庫(kù)端模塊。數(shù)據(jù)庫(kù)端模塊中運(yùn)行用于存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)庫(kù)程序。該模塊對(duì)云平臺(tái)運(yùn)行中一些必要信息進(jìn)行存儲(chǔ)，包括用戶的認(rèn)證信息，仿真任務(wù)所處的Pod、狀態(tài)、結(jié)果等仿真信息，以供其他模塊的程序進(jìn)行查詢與記錄。

4）用戶端模塊。仿真用戶在用戶端模塊進(jìn)行注冊(cè)和登錄操作，已通過(guò)身份驗(yàn)證的仿真用戶進(jìn)行仿真任務(wù)的新建、進(jìn)度查詢和結(jié)果查看。

2.2 模塊構(gòu)建

服務(wù)端模塊、仿真端模塊和數(shù)據(jù)庫(kù)端模塊的構(gòu)建流程如圖2 所示。

圖2 云平臺(tái)模塊構(gòu)建流程Fig.2 Construction procedure of cloud platform module

2.2.1 模塊功能實(shí)現(xiàn)與鏡像構(gòu)建

在模塊功能實(shí)現(xiàn)的步驟中，主要是結(jié)合前文中所敘述的需求分析，對(duì)每個(gè)需求條目進(jìn)行開(kāi)發(fā)，并進(jìn)行充分測(cè)試以保證功能可以正常實(shí)現(xiàn)。在模塊鏡像構(gòu)建的步驟中，通過(guò)分析模塊程序運(yùn)行過(guò)程中所需要的依賴、與其他模塊交互方式等，設(shè)計(jì)模塊需要加載的外部卷、需要暴露的端口等，并編寫(xiě)Dockerfile 以生成容器，并通過(guò)容器鏡像倉(cāng)庫(kù)對(duì)容器鏡像進(jìn)行托管。

考慮到電力設(shè)備仿真過(guò)程中獨(dú)有的特點(diǎn)，在模塊功能實(shí)現(xiàn)與鏡像構(gòu)建的步驟中也做了各種優(yōu)化措施。以仿真端模塊為例，由于在日常的電力設(shè)備仿真中，Ansys、Matlab 等仿真軟件被廣泛地應(yīng)用，因此有必要在仿真端模塊中集成此類軟件。在集成過(guò)程中，云平臺(tái)采用將軟件主體作為系統(tǒng)服務(wù)，僅在容器鏡像中安裝軟件運(yùn)行所需依賴的方法，如圖3 所示。

圖3 仿真端模塊中仿真軟件的解決方案Fig.3 The solution of simulation software in simulation module

通過(guò)此方法構(gòu)建仿真端鏡像，保證仿真軟件在仿真端模塊中可用的同時(shí)大幅減小容器鏡像體積，進(jìn)而加快云平臺(tái)的構(gòu)建速度。

2.2.2 云平臺(tái)架構(gòu)實(shí)現(xiàn)

對(duì)于服務(wù)端模塊、仿真端模塊和數(shù)據(jù)庫(kù)端模塊的云平臺(tái)架構(gòu)，均可使用如圖4 所示的架構(gòu)設(shè)計(jì)。

圖4 模塊的云平臺(tái)架構(gòu)實(shí)現(xiàn)Fig.4 Cloud platform architecture implementation of module

單個(gè)模塊的云平臺(tái)架構(gòu)主要由Pod、Deployment、Service、Secret 4 類資源對(duì)象組成。

最底層的是承載有容器鏡像的Pod 對(duì)象。作為Kubernetes 中執(zhí)行功能的最基本單位，Pod 使用前一節(jié)中所構(gòu)建的鏡像文件，并運(yùn)行著對(duì)應(yīng)的程序。與僅有一個(gè)的Deployment 控制器和Service 對(duì)象不同，為了充分利用云平臺(tái)的集群優(yōu)勢(shì)，并充分發(fā)揮集群主機(jī)的性能，Pod 通常會(huì)有多個(gè)副本，每個(gè)副本中都運(yùn)行著相同的程序，并由上層的Deployment 控制器進(jìn)行統(tǒng)一調(diào)度和負(fù)載均衡。

Pod 的上層是一個(gè)Deployment 控制器，用于管理其下屬的Pod 資源對(duì)象。Deployment 控制器通過(guò)重啟因錯(cuò)誤而停止的Pod，在配置文件被修改時(shí)對(duì)Pod 進(jìn)行滾動(dòng)更新等方法來(lái)確保其所管理的Pod 處于被期望的狀態(tài)。

Service對(duì)象用于將外部請(qǐng)求進(jìn)行負(fù)載均衡并分發(fā)至不同Pod 對(duì)象中。對(duì)于服務(wù)端模塊，由于其需要對(duì)集群外部的用戶提供服務(wù)，因此使用可被集群外部訪問(wèn)的NodePort 類型的Service 對(duì)象。而仿真端模塊和數(shù)據(jù)庫(kù)端模塊由于只需要對(duì)集群內(nèi)部提供服務(wù)，所以只使用默認(rèn)的ClusterIP 類型的Service 對(duì)象。

除具有層次結(jié)構(gòu)的Pod、Deployment、Service 資源對(duì)象之外，云平臺(tái)架構(gòu)還使用Secret 對(duì)象來(lái)保存敏感數(shù)據(jù)。由于服務(wù)端模塊和仿真端模塊在運(yùn)行時(shí)都需要密碼對(duì)數(shù)據(jù)庫(kù)進(jìn)行訪問(wèn)，數(shù)據(jù)庫(kù)端模塊在運(yùn)行時(shí)也需要密碼進(jìn)行數(shù)據(jù)庫(kù)啟動(dòng)，因此使用Secret對(duì)象用于儲(chǔ)存訪問(wèn)數(shù)據(jù)庫(kù)的密碼。

云平臺(tái)架構(gòu)中集群的每個(gè)主機(jī)都會(huì)被抽象為node 資源對(duì)象。每個(gè)Pod 都會(huì)在某一個(gè)node 上面運(yùn)行，使用node 資源對(duì)象底層的物理機(jī)計(jì)算資源。

根據(jù)以上云平臺(tái)架構(gòu)設(shè)計(jì)思路，保證各主機(jī)在同一網(wǎng)絡(luò)下編寫(xiě)yaml 配置文件并將其應(yīng)用至Kubernetes 中，即可成功啟動(dòng)電力設(shè)備仿真云平臺(tái)。

3 電力設(shè)備仿真云平臺(tái)的運(yùn)行

3.1 仿真任務(wù)的提交流程

在電力設(shè)備仿真云平臺(tái)啟動(dòng)、身份認(rèn)證成功后，用戶可選擇模板、填入?yún)?shù)進(jìn)行仿真任務(wù)提交。仿真任務(wù)提交流程如圖5 所示。

圖5 仿真任務(wù)提交流程Fig.5 Submission procedure of simulation task

在仿真任務(wù)的提交流程中，用戶提交的參數(shù)共經(jīng)歷兩次負(fù)載均衡，并根據(jù)實(shí)時(shí)負(fù)載情況分別被分配到較適合的服務(wù)端和仿真端進(jìn)行處理。服務(wù)端對(duì)用戶端發(fā)送的仿真參數(shù)進(jìn)行進(jìn)一步驗(yàn)證，并在驗(yàn)證通過(guò)后將參數(shù)發(fā)送到仿真端。而在仿真端中，則會(huì)根據(jù)服務(wù)端發(fā)送的參數(shù)生成對(duì)應(yīng)的仿真任務(wù)，調(diào)用一個(gè)新的仿真進(jìn)程運(yùn)行仿真，同時(shí)將相關(guān)的仿真信息記錄到數(shù)據(jù)庫(kù)中。

在整個(gè)流程中，服務(wù)端會(huì)將用戶的身份信息以session 的形式予以記錄，從而使用戶的登錄狀態(tài)得以維持。同時(shí)，也采用粘滯會(huì)話的策略，盡力保證用戶在整個(gè)會(huì)話周期內(nèi)所有請(qǐng)求都在負(fù)載均衡中被轉(zhuǎn)發(fā)到同一個(gè)服務(wù)端Pod 上。在session 和粘滯會(huì)話的共同作用下，用戶可以在一定時(shí)間內(nèi)無(wú)需再次登錄，用戶體驗(yàn)也得以提升。

3.2 仿真任務(wù)的運(yùn)行與輪詢

由于電力設(shè)備的仿真任務(wù)所需時(shí)間不同，很多情況下并不能實(shí)時(shí)返回計(jì)算結(jié)果，因此在仿真任務(wù)的提交流程后，服務(wù)端和仿真端的連接將會(huì)被中斷。仿真端會(huì)將仿真任務(wù)的仿真信息和結(jié)果實(shí)時(shí)更新到數(shù)據(jù)庫(kù)端中，等待新的服務(wù)端直接從數(shù)據(jù)庫(kù)端獲取仿真數(shù)據(jù)。

在單個(gè)仿真端內(nèi)部，將采用一個(gè)仿真任務(wù)隊(duì)列來(lái)對(duì)當(dāng)前所有的仿真任務(wù)進(jìn)行管理。仿真任務(wù)隊(duì)列中的每項(xiàng)均代表一個(gè)仿真任務(wù)，其背后均有一個(gè)仿真進(jìn)程在對(duì)其進(jìn)行仿真。仿真端主進(jìn)程會(huì)通過(guò)不斷輪詢?cè)摲抡嫒蝿?wù)隊(duì)列獲得仿真任務(wù)運(yùn)行的最新信息，輪詢的流程如圖6 所示。

圖6 仿真任務(wù)隊(duì)列輪詢流程Fig.6 Polling procedure of simulation task queue

在仿真任務(wù)隊(duì)列的輪詢過(guò)程中，會(huì)逐個(gè)查詢隊(duì)列中仿真任務(wù)的運(yùn)行狀態(tài)。對(duì)于正在運(yùn)行的仿真任務(wù)，獲取其實(shí)時(shí)輸出、運(yùn)行狀態(tài)等信息，并記錄于數(shù)據(jù)庫(kù)中。對(duì)于已經(jīng)結(jié)束運(yùn)行的仿真任務(wù)，則根據(jù)其退出碼判斷進(jìn)程是否正常結(jié)束，并讀取仿真結(jié)果，記錄于數(shù)據(jù)庫(kù)，最后從仿真任務(wù)隊(duì)列中將該仿真任務(wù)移除。

4 電力設(shè)備仿真云平臺(tái)的優(yōu)化

4.1 云平臺(tái)動(dòng)態(tài)構(gòu)建

電力設(shè)備仿真云平臺(tái)的核心在于“云計(jì)算”，即使用主機(jī)集群對(duì)大量仿真任務(wù)進(jìn)行處理，從而完成傳統(tǒng)的單機(jī)環(huán)境下無(wú)法完成或者需要很長(zhǎng)時(shí)間才能完成的工作。因此，合理規(guī)劃主機(jī)集群中的計(jì)算單位，以及將不同的仿真任務(wù)分發(fā)到不同的計(jì)算單位上，是設(shè)計(jì)和實(shí)現(xiàn)云平臺(tái)的關(guān)鍵步驟。在云平臺(tái)上，主機(jī)集群中各部分關(guān)系如圖7 所示。

圖7 主機(jī)集群中各部分關(guān)系Fig.7 Relationship between the parts in the host cluster

在云平臺(tái)的主機(jī)集群，一般會(huì)存在多個(gè)物理機(jī)，用于提供進(jìn)行仿真任務(wù)所需要的計(jì)算資源。而這些物理機(jī)上的計(jì)算資源常通過(guò)劃分為多個(gè)虛擬機(jī)或采用容器化的方式進(jìn)行虛擬化，從而分割成一個(gè)或多個(gè)計(jì)算單位。計(jì)算單位是直接對(duì)仿真任務(wù)進(jìn)行承載的單位，其對(duì)內(nèi)部運(yùn)行的仿真任務(wù)表現(xiàn)為一個(gè)具有完整CPU、內(nèi)存、I/O、網(wǎng)絡(luò)等資源的實(shí)體，對(duì)外則接受來(lái)自于管理系統(tǒng)的資源調(diào)度，與同一個(gè)物理機(jī)內(nèi)的不同計(jì)算單位共同分配并使用物理機(jī)的計(jì)算資源。

此外，為實(shí)時(shí)獲取到各單位的資源空閑程度，進(jìn)而合理分配調(diào)度已有資源，管理系統(tǒng)會(huì)通過(guò)資源監(jiān)聽(tīng)模塊對(duì)每個(gè)計(jì)算單位和物理機(jī)上的CPU、內(nèi)存等計(jì)算資源使用情況進(jìn)行監(jiān)聽(tīng)。資源調(diào)度與任務(wù)分配模塊則會(huì)根據(jù)資源監(jiān)聽(tīng)模塊所監(jiān)聽(tīng)到的資源使用情況，再根據(jù)仿真任務(wù)自身的特點(diǎn)，采用特定的算法將仿真任務(wù)進(jìn)行分配。資源監(jiān)聽(tīng)模塊還會(huì)在某些需要的條件下增加或刪除物理機(jī)中的計(jì)算單位，從而保證計(jì)算資源最高效使用。

本文使用Kubernetes 管理的電力設(shè)備仿真云平臺(tái)系統(tǒng)，上述的物理機(jī)被抽象為Kubernetes 中的node 資源對(duì)象，而計(jì)算單位為node 之下的Pod 資源對(duì)象。Kubernetes 作為容器管理工具，其內(nèi)部進(jìn)行了很多優(yōu)化，從而可以適應(yīng)較通用的云平臺(tái)構(gòu)建，例如Deployment 中Pod 的自動(dòng)擴(kuò)容。

4.2 仿真任務(wù)特性與運(yùn)行主機(jī)特性相匹配

對(duì)于電力設(shè)備仿真任務(wù)，不同的仿真類型、網(wǎng)格劃分方式或劃分密度都可能影響其在仿真過(guò)程中所需要的計(jì)算資源。同樣，集群中不同的主機(jī)也可能具有不同的配置，如有的主機(jī)CPU 性能相較于其內(nèi)存容量更占優(yōu)勢(shì)，或者有的主機(jī)CPU 性能較為低下，但是具有相對(duì)比較大的內(nèi)存。因此，若在仿真任務(wù)的提交流程中，將合適的仿真任務(wù)提交到合適的集群主機(jī)中，則可以充分利用集群主機(jī)中CPU 和內(nèi)存資源，進(jìn)而提高整體運(yùn)行效率。

為實(shí)現(xiàn)仿真任務(wù)特性與運(yùn)行主機(jī)特性相匹配，首先對(duì)云平臺(tái)架構(gòu)進(jìn)行改造。將架構(gòu)中的node資源對(duì)象分為內(nèi)存優(yōu)勢(shì)型主機(jī)和CPU 優(yōu)勢(shì)型主機(jī)。與node 的改動(dòng)相適應(yīng)，在Deployment資源對(duì)象的設(shè)計(jì)中，同樣將原本單個(gè)Deployment 改造為內(nèi)存優(yōu)勢(shì)型Deployment和CPU 優(yōu)勢(shì)型Deployment，并通過(guò)親和調(diào)度策略分別分配到對(duì)應(yīng)的node 主機(jī)上。最終是Service 資源對(duì)象的改造，分為內(nèi)存型、CPU 型和自動(dòng)分配型，其中內(nèi)存型Service 將請(qǐng)求發(fā)送至內(nèi)存優(yōu)勢(shì)型Deployment，CPU型Service 將請(qǐng)求發(fā)送至CPU 優(yōu)勢(shì)型Deployment，自動(dòng)分配型Service 則根據(jù)仿真系統(tǒng)中整體的負(fù)載情況進(jìn)行自動(dòng)分配。經(jīng)過(guò)如上改造，最終云平臺(tái)架構(gòu)中各資源對(duì)象的對(duì)應(yīng)關(guān)系如圖8 所示。

圖8 不同資源對(duì)象的對(duì)應(yīng)關(guān)系Fig.8 Correspondence between different resource objects

從圖8 可以看出，每個(gè)Deployment 均與其管理的Pod 用實(shí)線相連，每個(gè)Service 與可能被分配仿真任務(wù)的Pod 用虛線相連。用戶在新建仿真任務(wù)時(shí)，根據(jù)其選擇的參數(shù)，估算出仿真任務(wù)的資源使用特性，并選擇合適的Service 來(lái)提交仿真任務(wù)。對(duì)于難以估算資源特性的仿真任務(wù)，使用默認(rèn)auto 類型的Service，云平臺(tái)根據(jù)所有Pod 的負(fù)載情況進(jìn)行仿真任務(wù)分發(fā)。

4.3 云平臺(tái)中仿真任務(wù)與Pod 之間的映射

相比傳統(tǒng)的單機(jī)平臺(tái)，云平臺(tái)利用靈活的負(fù)載均衡算法，將多個(gè)仿真任務(wù)分配到不同的Pod 上，從而使云平臺(tái)整體的計(jì)算資源得到充分利用。在仿真任務(wù)和Pod 資源對(duì)象之間的映射算法中，采用預(yù)選、優(yōu)選、選定來(lái)確定最終要執(zhí)行仿真任務(wù)的Pod。

1）預(yù)選

從多個(gè)角度對(duì)Service 所相連的Pod 資源對(duì)象進(jìn)行評(píng)價(jià)，并排除硬性條件上無(wú)法進(jìn)行仿真任務(wù)新建的Pod 資源對(duì)象。在預(yù)選步驟中，程序?qū)⑦M(jìn)行如下評(píng)價(jià)：當(dāng)前Pod 是否可被連接；當(dāng)前Pod 中內(nèi)存使用量與其內(nèi)存限制之間的差值是否小于閾值；當(dāng)前Pod中內(nèi)存使用率和CPU 使用率是否大于閾值等。只有上述條件全部評(píng)價(jià)通過(guò)，才能通過(guò)預(yù)選環(huán)節(jié)，進(jìn)入優(yōu)選階段。

2）優(yōu)選

將對(duì)Pod 中各計(jì)算資源的使用率進(jìn)行排名。每個(gè)Pod 有4 個(gè)資源指標(biāo)，分別為CPU、內(nèi)存、網(wǎng)絡(luò)和I/O。對(duì)于電力仿真任務(wù)，使用的資源主要是CPU 和內(nèi)存。因此，在進(jìn)行資源使用率的排名中，對(duì)CPU 和內(nèi)存設(shè)置了相對(duì)比較大的權(quán)重，而對(duì)網(wǎng)絡(luò)和I/O 設(shè)置了相對(duì)比較小的權(quán)重。

假設(shè)第d號(hào)Pod 資源對(duì)象，其CPU 的使用限制為NCPU，內(nèi)存的使用限制為Nmemory，網(wǎng)絡(luò)的使用限制為NNet，I/O 的使用限制為NI/O，其對(duì)應(yīng)的使用量分別為nCPU、nmemory、nNet、nI/O，則該P(yáng)od 的評(píng)分如式（1）所示：

其中：K1、K2、K3、K4分別為CPU、內(nèi)存、網(wǎng)絡(luò)和I/O 資源對(duì)象的權(quán)重，且K1和K2大于K3和K4。

將所有通過(guò)預(yù)選的Pod 資源對(duì)象按照式（1）計(jì)算，即可得出每個(gè)Pod 對(duì)應(yīng)的評(píng)分。至此，優(yōu)選部分結(jié)束。

3）選定

使用優(yōu)選步驟中得出的評(píng)分序列，根據(jù)式（2）計(jì)算最終要使用的Pod。

其中：x*為采用映射算法得出的最優(yōu)Pod，其通過(guò)選取資源使用率最低的Pod 而得出。

4.4 擴(kuò)容機(jī)制與擴(kuò)容映射算法

若所有Service 對(duì)應(yīng)Pod 均達(dá)到內(nèi)存使用量的閾值等條件而無(wú)法通過(guò)預(yù)選，則說(shuō)明當(dāng)前云平臺(tái)內(nèi)的仿真任務(wù)較繁重，需要進(jìn)行Pod 擴(kuò)容。在擴(kuò)容過(guò)程中，新增加的Pod 通過(guò)一個(gè)映射算法來(lái)決定其被分配到哪臺(tái)主機(jī)上，即需要確定新增Pod 對(duì)象與node對(duì)象的對(duì)應(yīng)關(guān)系。

由于Pod 對(duì)象與node 對(duì)象之間的關(guān)系和仿真任務(wù)與Pod 對(duì)象之間的關(guān)系十分相似，因此采用對(duì)node 進(jìn)行預(yù)選、優(yōu)選和選定，并最終確定新的Pod 所屬node 對(duì)象。當(dāng)node 中負(fù)載過(guò)大時(shí)，集群主機(jī)的擴(kuò)容無(wú)法保證實(shí)時(shí)性。因此，當(dāng)云平臺(tái)處于滿負(fù)荷運(yùn)行時(shí)，需要將此時(shí)新加入的仿真任務(wù)加入一個(gè)隊(duì)列中，等待資源空閑時(shí)再開(kāi)始執(zhí)行仿真。

5 應(yīng)用實(shí)例

5.1 測(cè)試環(huán)境

使用由3 臺(tái)主機(jī)構(gòu)成的集群進(jìn)行測(cè)試，集群主機(jī)的軟硬件配置采用CPU Intel i7-9700K、內(nèi)存64 GB，硬盤(pán)500 GB SSD，操作系統(tǒng)Ubuntu 18.04。

將其中1 臺(tái)主機(jī)設(shè)置為Master 節(jié)點(diǎn)，另外2 臺(tái)設(shè)置為工作節(jié)點(diǎn)。對(duì)主機(jī)進(jìn)行相關(guān)配置，并進(jìn)行Docker、Kubernetes 等必備軟件安裝。在配置過(guò)程中，將Ansys、Matlab 作為系統(tǒng)服務(wù)供仿真端Docker調(diào)用，從而大幅減小仿真端鏡像體積。同時(shí)，使用容器鏡像服務(wù)對(duì)服務(wù)端模塊、仿真端模塊和數(shù)據(jù)庫(kù)端模塊的容器鏡像進(jìn)行托管，使Pod 資源對(duì)象被首次構(gòu)建時(shí)可自動(dòng)從鏡像托管服務(wù)處下載并應(yīng)用容器鏡像。

5.2 功能性測(cè)試

以變壓器鐵芯內(nèi)部磁場(chǎng)分布的仿真為例，對(duì)電力設(shè)備仿真云平臺(tái)進(jìn)行功能性測(cè)試。云平臺(tái)正常啟動(dòng)后，仿真用戶可以在瀏覽器中輸入Master 節(jié)點(diǎn)的IP 地址以及服務(wù)端模塊的Service 對(duì)象所指定的NodePort 端口來(lái)接受服務(wù)。用戶可以在云平臺(tái)所提供的用戶界面中登錄或注冊(cè)，如圖9 所示。

圖9 云平臺(tái)的用戶登錄界面Fig.9 User login interface of cloud platform

注冊(cè)成功并登錄賬戶后，選取模板并輸入?yún)?shù)進(jìn)行仿真任務(wù)提交。仿真任務(wù)的參數(shù)設(shè)置和提交界面如圖10 所示。使用空載變壓器的Ansys 仿真模型如圖11 所示。

圖10 云平臺(tái)的仿真任務(wù)提交界面Fig.10 Simulation task submission interface of cloud platform

圖11 空載變壓器仿真模型Fig.11 Simulation model of no-load transformer

設(shè)置鐵芯相對(duì)磁導(dǎo)率為2 000 H/m，電流密度為1 000 A/m2。由于該仿真任務(wù)的模型結(jié)構(gòu)比較簡(jiǎn)單，仿真平臺(tái)能很快得出并返回仿真結(jié)果，返回的結(jié)果如圖12 所示。從圖12 可以看出，云平臺(tái)已成功應(yīng)用參數(shù)在模板之中，調(diào)用仿真進(jìn)程執(zhí)行仿真，并返回正確的仿真結(jié)果。

圖12 變壓器鐵芯內(nèi)部磁場(chǎng)分布的仿真結(jié)果Fig.12 Simulation results of magnetic field distribution inside transformer core

為驗(yàn)證云平臺(tái)的仿真結(jié)果持久化功能，退出目前云平臺(tái)的登錄并將設(shè)備更換為其他設(shè)備。重新登錄后發(fā)現(xiàn)仿真結(jié)果仍然可以被查看，由此驗(yàn)證云平臺(tái)的數(shù)據(jù)持久化功能。

在以上實(shí)例中，云平臺(tái)按照預(yù)期實(shí)現(xiàn)了需求分析中的用戶管理、提交流程管理、仿真任務(wù)管理、仿真日志和結(jié)果文件持久化、用戶交互等功能，完成電力設(shè)備仿真云平臺(tái)的功能性測(cè)試。

6 結(jié)束語(yǔ)

本文采用Docker 容器化技術(shù)和Kubernetes 容器編排技術(shù)，結(jié)合模塊化思想，搭建基于容器的電力設(shè)備仿真云平臺(tái)。通過(guò)仿真特性匹配和兩個(gè)映射算法對(duì)電力設(shè)備仿真云平臺(tái)的運(yùn)行進(jìn)行優(yōu)化。應(yīng)用實(shí)例結(jié)果表明，該電力設(shè)備仿真云平臺(tái)利用云平臺(tái)優(yōu)勢(shì)可完成用戶提出的仿真要求，并滿足需求分析中的各項(xiàng)功能要求。后續(xù)將在云平臺(tái)上開(kāi)發(fā)基于遺傳算法等啟發(fā)式算法的仿真模型參數(shù)優(yōu)化功能，進(jìn)一步發(fā)揮云平臺(tái)的優(yōu)勢(shì)。