趙宇峰，雷 晟，張國鋼，耿英三

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

0 概述

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

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

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

隨著相關(guān)技術(shù)的普及，近年來基于容器化技術(shù)和容器編排技術(shù)的仿真平臺研究發(fā)展迅速，但在發(fā)展過程中也同樣存在著許多問題。例如，由于底層的物理資源性能條件差異、用戶需求不定，仿真平臺需要合理分配現(xiàn)有資源，做好資源管理、調(diào)度和動態(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ù)特性也各有差異，云仿真平臺在具體行業(yè)領(lǐng)域的應(yīng)用過程中存在問題。研究者將云仿真平臺與已有的TMSR-SF1 工程仿真機(jī)相結(jié)合，實(shí)現(xiàn)了適用于核電仿真的云仿真平臺［20］。

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

1 需求分析

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

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

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

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

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

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

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

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

2.1 模塊設(shè)計

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

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

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

云平臺模塊主要有：

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

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

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

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

2.2 模塊構(gòu)建

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在電力設(shè)備仿真云平臺啟動、身份認(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í)時負(fù)載情況分別被分配到較適合的服務(wù)端和仿真端進(jìn)行處理。服務(wù)端對用戶端發(fā)送的仿真參數(shù)進(jìn)行進(jìn)一步驗(yàn)證，并在驗(yàn)證通過后將參數(shù)發(fā)送到仿真端。而在仿真端中，則會根據(jù)服務(wù)端發(fā)送的參數(shù)生成對應(yīng)的仿真任務(wù)，調(diào)用一個新的仿真進(jìn)程運(yùn)行仿真，同時將相關(guān)的仿真信息記錄到數(shù)據(jù)庫中。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）預(yù)選

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

2）優(yōu)選

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

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

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

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

3）選定

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

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

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

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

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

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

5.1 測試環(huán)境

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

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

5.2 功能性測試

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

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

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

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

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

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

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

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

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

6 結(jié)束語

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