異構(gòu)私有云管平臺通用適配器的研究與實現(xiàn)

王一盟

文章編號： 2095-2163（2018）03-0026-07中圖分類號： 文獻標志碼： A

摘要： 關(guān)鍵詞： for heterogeneous private Cloud Management Platform

（School of Computer Science and Technology， Donghua University， Shanghai 201620， China）

Abstract： Driven by the growing maturity of cloud computing technology and increasing volume of business， IDC of enterprises has deployed a variety of heterogeneous private cloud platforms to support different business scenarios. There are many kinds of CMP， which are difficult to centrally manage. Management objects of the existing cloud management tools are lacking of domestic cloud computing products， and the price is high. The universal adapter model based on heterogeneous private cloud platform is proposed in this paper. It has low cost， deep customization and excellent scalability and so on. This paper selects some representative private cloud platforms such as HuaWei， Redhat OpenStack， CloudStack and VMware vSphere， and uses adapter， factory methods and other design patterns to transform the original API of the cloud platform as an unified adapter interface. The integration of adapter model， hardware infrastructure and CMP， which can achieve centralized management， simplify the multiple management system， and improve the utilization of resources and work efficiency.

Key words：

1概述

1.1研究背景

自谷歌提出云計算概念至今，十年內(nèi)互聯(lián)網(wǎng)信息技術(shù)革命性發(fā)展推動著云計算相關(guān)研究日趨成熟。各企業(yè)充分利用云計算技術(shù)資源快速池化、超大規(guī)模虛擬化的應(yīng)用價值和發(fā)展前景推動傳統(tǒng)商業(yè)模式轉(zhuǎn)型，用云計算技術(shù)管理龐大的數(shù)據(jù)中心。在云計算平臺云集，業(yè)務(wù)范圍迅速擴張，基礎(chǔ)設(shè)施更新?lián)Q代頻繁，災(zāi)備、安全、隔離、性能等需求層出的大背景下，企業(yè)會與多家云平臺廠商合作，將應(yīng)用程序及運行產(chǎn)生的數(shù)據(jù)分散部署和存儲于不同技術(shù)支持的云平臺中，而同一云平臺也會伴隨升級出現(xiàn)階段性部署多版本的情況。又因不同架構(gòu)下的云計算平臺配有各自專屬的管理系統(tǒng)，由此便引發(fā)多云平臺亟需集中管理的迫切需求。

1.2研究現(xiàn)狀

較國內(nèi)而言，國外的云計算技術(shù)發(fā)展較早、成熟度較高，因此也先期面臨了多云管理這一資源整合性問題。在云管理領(lǐng)域具有突出地位的RightScale、CliQr等廠商，各自旗下產(chǎn)品的納管對象是國外知名大型云服務(wù)廠商的云計算平臺（例如Amazon、Google、Microsoft、IBM的云平臺，以及本文提及的3類私有云平臺）。無論是從技術(shù)精湛度，還是從功能廣泛性方面評估，RightScale的云管理平臺（Cloud Management Platform，CMP）解決方案都具有絕對的世界領(lǐng)先水平，但其成本也是十分昂貴的。對國內(nèi)企業(yè)而言，國外的云管理產(chǎn)品并不能完全適用，原因在于國內(nèi)企業(yè)IDC部署的本土云計算平臺產(chǎn)品未被上述管理工具納管（如阿里云、騰訊云、華為、qingcloud、Ucloud、EasyStack等）。

2017年7月，云星數(shù)據(jù)（深圳）有限公司成為國內(nèi)首個獲得了RightScale授權(quán)的云管理服務(wù)商，未來將提供公有、私有、以及混合云的多云編排管理方案。H3C、華為、浪潮是中國有著與云星相似業(yè)務(wù)的公司，且是國內(nèi)領(lǐng)先的混合云管理平臺軟件供應(yīng)商。又如FIT2CLOUD，除支持基礎(chǔ)設(shè)施資源的全面管理外，還將云計算技術(shù)與容器技術(shù)相結(jié)合，向DevOps集開發(fā)、測試、運維為一體的PaaS層面發(fā)展。CCW Research2017年發(fā)布的最新研究結(jié)果顯示，未來5年國內(nèi)私有云發(fā)展勢頭迅猛，帶動云管理軟件高速進步，國產(chǎn)化趨勢將更加明顯[1]。

1.3研究內(nèi)容

本文基于企業(yè)部署率較高的4種異構(gòu)私有云平臺，研究將異構(gòu)云平臺的大量接口如何轉(zhuǎn)換為對外提供服務(wù)的統(tǒng)一接口，設(shè)計并實現(xiàn)出一套對任意云平臺都通用的適配器模型。通過使用GOF設(shè)計模式中的2種創(chuàng)建型和1種結(jié)構(gòu)型模式來規(guī)范代碼設(shè)計，提高項目的業(yè)內(nèi)規(guī)范性和質(zhì)量可靠性。該模型適用于納管多個異構(gòu)的云平臺，使彼此分散、互不相通的計算、存儲等資源池能在同一軟件系統(tǒng)內(nèi)實現(xiàn)全局集中式管理。適配器的設(shè)計能夠直觀地展現(xiàn)各類資源用量，減輕維護大量云管系統(tǒng)的壓力，提高運作效率和資源利用率。本文模型較前文所述的商用云管理平臺而言更輕量級，可擴展性和移植性強，云平臺似可插拔組件般加入或移出模型。適配器項目定制導(dǎo)出為JAR文件，方便第三方云管理系統(tǒng)導(dǎo)入使用。篇章重點介紹模型的中間層，即適配器接口層的設(shè)計思路和實現(xiàn)要點，為多云管理系統(tǒng)提供基礎(chǔ)支持。

2私有云平臺

私有云是企業(yè)用戶或個人用戶獨立構(gòu)建的云計算平臺，平臺與外網(wǎng)隔斷，僅能通過組織機構(gòu)內(nèi)部的局域網(wǎng)控制訪問。因此，私有云計算平臺的安全性級別較高，可有效地防止信息泄露和外部入侵。私有云平臺中運行的是企業(yè)內(nèi)部應(yīng)用或個人的應(yīng)用程序，資源對內(nèi)部而言公開、透明、不涉及個人隱私，云平臺可全面監(jiān)控用戶及應(yīng)用行為。本文設(shè)計的通用適配器模型，其應(yīng)用場景為企業(yè)數(shù)據(jù)中心，主要用于管理企業(yè)已存的各類私有云計算平臺。

2.1OpenStack云計算平臺

OpenStack發(fā)起于2010年，是由NASA和RackSpace共同研發(fā)的IaaS開源解決方案，為管理企業(yè)數(shù)據(jù)中心計算、存儲、網(wǎng)絡(luò)等資源池而構(gòu)建的開源云計算平臺。OpenStack包含一系列內(nèi)部服務(wù)組件，服務(wù)組件通過API相互關(guān)聯(lián)，各司其職，用戶可根據(jù)實際需要選擇性地安裝，最終組成功能豐富的云操作系統(tǒng)。OpenStack的概念架構(gòu)如圖1所示，該架構(gòu)描繪出各服務(wù)組件之間的關(guān)聯(lián)關(guān)系[2]。

由圖1可知，架構(gòu)內(nèi)Nova計算服務(wù)是OpenStack項目中位居基礎(chǔ)的單元組件，最常使用的虛擬化技術(shù)是KVM和Xen[3]，就是重點管理云計算平臺中虛擬機實例的計算資源自創(chuàng)建至結(jié)束的全生命周期。Neutron是OpenStack的虛擬網(wǎng)絡(luò)服務(wù)組件，其功能是為Nova提供IP地址和網(wǎng)絡(luò)連接等常規(guī)服務(wù)，以及負載均衡、創(chuàng)建防火墻、VPN（Virtual Private Network）等高級服務(wù)。OpenStack中的存儲服務(wù)包括Cinder（塊存儲服務(wù)組件）和Swift（對象存儲服務(wù)組件）。該存儲服務(wù)均為持久性存儲，且采用冗余的存儲方案，具有高可用、低風險的特點。

2.2VMware vSphere 虛擬化平臺

在VMware眾多虛擬化與云計算的產(chǎn)品中，VMware vSphere是側(cè)重于基礎(chǔ)架構(gòu)服務(wù)器虛擬化的一款企業(yè)級虛擬化平臺。VMware公司的產(chǎn)品因穩(wěn)定性和兼容性好、性能和可靠性以及市場占有率高而著稱，常被大型企業(yè)選用在數(shù)據(jù)中心的IaaS層配備虛擬化運行功能。

vSphere包含vCenter Server等管理服務(wù)和ESXi等大量功能性組件[4]?？蛻舳藇Sphere Client能夠全局統(tǒng)籌對ESXi的基本管理，并且包括處理虛擬機的相關(guān)操作。vCenter虛擬化管理平臺具有豐富的API，本文的私有云管平臺通用適配器就是基于這些接口獲得實現(xiàn)[5]。

2.3CloudStack 云計算平臺

CloudStack 是一個開源的云操作系統(tǒng)，能夠管理大部分主流的hypervisors，如KVM、 XenServer、VMware、Oracle VM、Xen等[6]。CloudStack使存儲、網(wǎng)絡(luò)、計算資源協(xié)同工作，方便用戶在現(xiàn)有架構(gòu)上快速搭建IaaS服務(wù)層。

如圖2所示，終端用戶通過 CloudStack API 和 CloudStack 編排引擎對接計算控制器、網(wǎng)絡(luò)控制器和存儲控制器，通過控制器操控底層的物理資源為用戶提供所需服務(wù)。

3通用適配器模型

3.1模型架構(gòu)設(shè)計

通用適配器模型是一個實現(xiàn)異構(gòu)私有云平臺集中管理的有效解決方案，模型的研究終態(tài)是一套可工作在不同IaaS方案之間的Java類庫，提供對異構(gòu)云計算環(huán)境的API接口執(zhí)行方法，協(xié)助程序設(shè)計者進行云計算應(yīng)用的開發(fā)。本模型的設(shè)計范圍可解析整定為接口和類的設(shè)計工作，并秉承著3項規(guī)范：最大化滿足云平臺功能需要、保持原生態(tài)服務(wù)接口、符合GOF設(shè)計模式思路，代碼盡量靈活簡明。

宏觀上該模型主要分為3層，如圖3所示，自上而下分別為：應(yīng)用服務(wù)層（例如CMP，及其它需調(diào)用適配器統(tǒng)一接口的應(yīng)用服務(wù)）、適配器層（通用適配器統(tǒng)一接口）、IaaS層（多個異構(gòu)的私有云平臺），3.3節(jié)將專門探討通用適配器統(tǒng)一接口的設(shè)計與實現(xiàn)。

3.2通用適配器的API調(diào)用

OpenStack云操作系統(tǒng)整合了大量的API供YOUR APPLICATIONS（客戶應(yīng)用程序）、Dashboard（儀表盤）、Monitoring & Tools（監(jiān)控&管理工具）使用，開發(fā)者通過接口調(diào)用可控制整個數(shù)據(jù)中心的資源池。華為基于OpenStack架構(gòu)研發(fā)的云計算產(chǎn)品FusionSphere OpenStack[7]（以下簡稱為FSO），是商用加固型的OpenStack，現(xiàn)多應(yīng)用于大型企業(yè)的數(shù)據(jù)中心，提供IaaS云服務(wù)。FSO Java SDK基于開源庫OpenStack4j實現(xiàn)，用于配置和控制OpenStack的基礎(chǔ)服務(wù)，且前者也協(xié)配有按組件劃分的接口，允許使用者進行二次開發(fā)。RedHat OpenStack Platform[8]同樣是一個能夠滿足在生產(chǎn)級環(huán)境下客戶和業(yè)務(wù)需求的OpenStack云計算產(chǎn)品，因其結(jié)合紅帽Linux系統(tǒng)構(gòu)建的IaaS私有云而具有高穩(wěn)定性和可擴展性等特點，同時整體依托的底層Linux還可為云主機的操作系統(tǒng)額外增添一種選擇。除上述列舉的產(chǎn)品外，國內(nèi)外還有諸多企業(yè)，如EasyStack、Lenovo、Intel、IBM等，也已轉(zhuǎn)入基于OpenStack開源項目設(shè)計部署云計算的解決方案研發(fā)中。本文將采用2種接口調(diào)用方式適配OpenStack型云平臺，分別為OpenStack4j封裝的OpenStack WEB API和OpenStack原生的RESTful API。

VMware開源的 VI （版本4后更名為vSphere） Java API 是一組旨在用于簡化VI SDK Web服務(wù)接口的Java類庫，現(xiàn)已呈現(xiàn)出性能卓越、響應(yīng)速度快、可讀性強等特點，是一套簡潔、穩(wěn)定、且包括有與VMware vSphere通信功能的實用工具。開發(fā)者調(diào)取其定義良好的管理對象模型，充分采用面向?qū)ο缶幊?，便能通過該API連接至vCenter Server ，從而配置新的虛擬機并管理其生命周期。目前，開源的VI Java已停止更新，近期出現(xiàn)的VI JavaNG6.5是VI Java的商業(yè)版，在設(shè)計上配備了高性能的流引擎，無需生成DOM對象，節(jié)省了內(nèi)存的消耗。本文選用VMware開源的VI Java API，VI JavaNG實則沿用了開源的VI Java API，兩者具有一致的API，只不過VI JavaNG加設(shè)了更多的功能和支持選項。

Apache CloudStack API 采用RESTful風格，以HTTP的GET、POST方法提交所有請求，采用apiKey和私人簽名登錄驗證的執(zhí)行方式。API請求主要由以下部分組成：CloudStack管理服務(wù)器的URL、處理傳入請求的API Servlet路徑、執(zhí)行的服務(wù)命令字符串、簽名。其中，服務(wù)命令字符串包括命令、命令所需的參數(shù)、標識用戶賬戶的唯一API密鑰。每條HTTP請求都需要使用HMAC SHA-1散列函數(shù)對用戶密鑰進行計算，生成的字符串用作簽名，以便CloudStack對調(diào)用者展開身份認證和授權(quán)。CloudStack默認API的調(diào)用響應(yīng)格式為XML，但也可外延為本項目使用的JSON響應(yīng)格式，僅需要在服務(wù)命令字符串中添加“&response;=json”字樣即可。

以CloudStack云計算平臺為例，圖4選取了常用功能，列出模塊與子模塊的統(tǒng)一接口方案。

3.3通用適配器基本設(shè)計理念和處理流程

本文對適配器模式的傳統(tǒng)模型加以改造，選用該模式分類下的對象適配器模式，補充創(chuàng)建型模式中的工廠方法和單例模式，創(chuàng)新性地將三者結(jié)合使用[9]。模型改造后重新定義的角色說明具體可見表1。

想要達到3.2節(jié)提出的4種Adaptee與原本不兼容的Target能夠在同一項目中的配合協(xié)作，就需要進行接口轉(zhuǎn)換，對3種既有云計算平臺的開放接口逐一引入進一步的封裝，隔離既有云計算平臺和云管理平臺，改造后的新接口解耦了客戶應(yīng)用程序?qū)扔邢到y(tǒng)的依賴。適配器模式在未對現(xiàn)有類和接口啟動改造的前提下，從外部增加新對象（即Adapter適配器類）完成從舊接口到新接口的轉(zhuǎn)換處理。調(diào)用各既有系統(tǒng)的既有類型，依照客戶程序的要求實現(xiàn)新接口。適配器層接收云平臺接口的參數(shù)輸入信息，輸出云平臺接口響應(yīng)信息，并將輸入輸出封裝成JavaBean。應(yīng)用層通過HTTP協(xié)議或直接調(diào)用socket接口建立連接，且通過適配器層可切換任意云平臺接口，適配器支持可擴展性，可添加不同云平臺不同版本接口。

適配器項目的終態(tài)將被導(dǎo)出為JAR文件，供客戶程序?qū)胧褂?。圖5展示了通用適配器統(tǒng)一接口的UML類圖，直觀地反映出新老接口的描述。適配器統(tǒng)一接口工作流程分述如下：

（1）客戶端程序執(zhí)行setRequestParam（Request request）方法配置出帶有資源池管理軟件類型、實際虛擬機操作等參數(shù)項的request。

（2）getAdapter（）方法發(fā)送請求，調(diào)用適配器jar包中的統(tǒng)一外部接口創(chuàng)建相應(yīng)的適配器（例如OpenStackAdapter等）。

（3）適配器調(diào)用具體實現(xiàn)，在內(nèi)部創(chuàng)建適配器執(zhí)行對象Adaptee（例如OpenStackAdaptee等），獲取適配者單例。

（4）適配者根據(jù)傳入request的信息類型，構(gòu)造相應(yīng)云計算平臺所規(guī)定的API請求URL，API請求參數(shù)包括主機地址、用戶名、密碼、租戶名等（CloudStack需生成簽名），并對參數(shù)及URL進行序列化。

（5）執(zhí)行check（Request request）方法檢測服務(wù)器連接成功與否。

（6）執(zhí)行execute（Request request）方法，實現(xiàn)獲取tokens、查詢云主機列表、虛擬機生命周期操作、掛載或卸載磁盤、創(chuàng)建或注銷鏡像等功能的API命令。

（7）適配器將返回的JSON格式的響應(yīng)信息封裝成Response響應(yīng)類，發(fā)送至客戶端的調(diào)用處，客戶端接收Response，并將結(jié)果顯示于CMP的圖形化界面上。

本文針對不同類型的API采取不同的封裝方式，如原生封裝（不改變底層云平臺API提供的任何接口）、數(shù)據(jù)轉(zhuǎn)換（采用FastJson進行轉(zhuǎn)換）、注解方式（通過注解方式對Request請求和Response結(jié)果加以賦值）。其中，RESTful HTTP風格的API中，核心關(guān)鍵性的抽象概念在于通過唯一標識遠程訪問資源，使用GET、PUT、POST等方法發(fā)出請求并獲取響應(yīng)。因此適配器項目對大量請求和響應(yīng)進行了封裝，首先實現(xiàn)了2個用于封裝基本參數(shù)的基類Request和Response，兩者的類圖詳見圖6，其余所有組件分類下的API接口均繼承自上述2個基類。

Request基類使用云平臺類型、主機名稱、API密鑰、租戶名稱等信息通過身份認證后連接至服務(wù)器，自定義1個Command Annotation，并帶有3個成員變量：name（請求名稱）、description（請求描述）、responseObject（返回值類型，默認值為Response.class）。Request類中g(shù)etRequestMethod（）方法通過反射獲取類中所有匹配的注解，強制轉(zhuǎn)化為Command類型，并調(diào)用name方法返回請求名稱；同理，getResponseTag（）方法調(diào)用responseObject方法來運行饋送返回值類型。Response基類包含調(diào)用方法是否成功、異常錯誤、返回狀態(tài)、異常信息頭、響應(yīng)體內(nèi)容等成員變量。

通用適配器中的請求和響應(yīng)類均繼承自以上2個基類，擴展了請求響應(yīng)類型以及封裝的參數(shù)。請求響應(yīng)類的一級分類為云平臺類型，二級分類是API組件類型，三級分類則細化到某一操作。以CloudStack云平臺中虛擬機API模塊為例，研究得到3級分類下涉及功能的請求/響應(yīng)類，重點表述可參見表2。

利用以上請求/響應(yīng)類，加上特定的請求參數(shù)，測試類或客戶程序即可統(tǒng)一化、模板化地調(diào)用各類云平臺的具體操作，輕松完成異構(gòu)私有云管平臺池化資源的集中協(xié)調(diào)和管理。4結(jié)束語

建立異構(gòu)私有云管平臺通用適配器的目的和意義在于，能夠有效地整合并調(diào)度不同云計算平臺下的虛擬化資源，基于適配器而開發(fā)的CMP系統(tǒng)可對基礎(chǔ)設(shè)施資源實現(xiàn)集中式、可視化的管理，簡化了企業(yè)規(guī)模不斷擴大的數(shù)據(jù)中心的云計算資源管理復(fù)雜度，提高了資源利用和復(fù)用率；宏觀且實時掌控所有資源池中存量資源的使用情況，及時合理地調(diào)度資源，降低IT預(yù)算，節(jié)約運營成本，減少運維人員數(shù)量，提高IT運維的管理效率。

參考文獻

[1] 計世資訊. 2016-2017年中國私有云市場現(xiàn)狀與發(fā)展趨勢研究報告[EB/OL].[2017-10]. http：//www.ccwresearch.com.cn/report_detail.htm？id=458774.

[2] 陸平，趙培，左奇. OpenStack系統(tǒng)架構(gòu)設(shè)計實戰(zhàn)[M]. 北京：機械工業(yè)出版社， 2016.

[3]OpenStack. OpenStack Docs： Pike[EB/OL]. [2018-04-23]. https：//docs.openstack.org/releasenotes/openstack-manuals/pike.html.

[4] 王春海. 深入學習VMware vSphere 6[M].北京：人民郵電出版社， 2016.

[5]VMware R&D.; VMware vSphere Java API[EB/OL].[2017-06-01]. http：//vijava.sourceforge.net/testimonial.php.

[6] 劉振宇， 蔡立志， 陳文捷. CloudStack技術(shù)指南[M]. 哈爾濱：哈爾濱工程大學出版社， 2015.

[7] 華為技術(shù)有限公司. FusionSphere OpenStack[EB/OL].[2017-05-30]. http：//developer.huawei.com/ict/cn/site-cloud/products/fusionSphere-openstack.

[8] RedHat. RedHat OpenStack Platform[EB/OL]. [2017-05-31]https：//www.redhat.com/zh/technologies/linux-platforms/openstack-platform.

[9] 王翔， 孫遜. 模式—工程化實現(xiàn)及擴展（設(shè)計模式Java版）[M]. 北京：電子工業(yè)出版社， 2012.（上接第25頁）

[7] ABDELAZIZ A Y， FATHY A. A novel approach based on crow search algorithm for optimal selection of conductor size in radial distribution networks[J]. Engineering Science and Technology， 2017， 20（2）： 391-402.

[8] YANG Xinshe. Cuckoo search and firefly algorithm： Overview and analysis[M]. Cham：Springer International Publishing， 2014.

[9] RAY T， LIEW K M. Society and civilization： An optimization algorithm based on the simulation of social behavior[J]. IEEE Transactions Evolutionary Computations， 2003，7（4）：386-396.

[10]LIU Hui， CAI Zixing， WANG Yong. Hybridizing particle swarm optimization with differential evolution for constrained numerical and engineering optimization[J]. Applied Soft Computing， 2010，10（2）：629-640.

[11]ZHANG Min， LUO Wenjian， WANG Xufa. Differential evolution with dynamic stochastic selection for constrained optimization[J]. Information Sciences， 2008，178：3043-3074.

[12]SADOLLAH A， BAHREININEJAD A， ESKANDAR H， et al. Mine blast algorithm： A new population based algorithm for solving constrained engineering optimization problems[J]. Applied Soft Computing， 2013，13（5）：2592-2612.

[13]COELLO C A C. Use of a self-adaptive penalty approach for engineering optimization problems[J]. Computers in Industry， 2000，41（2）：113-127.

[14]COELHO L D S. Gaussian quantum-behaved particle swarm optimization approaches for constrained engineering design problems[J]. Expert Systems with Applications， 2010，37（2）：1676-1683.

[15]HUANG Fuzhuo， WANG Ling， HE Qie. An effective co-evolutionary differential evolution for constrained optimization[J]. Applied Mathematics Computation， 2007，186（1）：340-356.

[16]YANG Xinshe.Bat algorithm： Literature review and applications[J]. International Journal of Bio-Inspired Computation， 2013， 5（3）： 141-149.

[17]BAYKASOGLU A. Design optimization with chaos embedded great deluge algorithm[J]. Applied Soft Computing， 2012，12（3）： 1055-1067.