吳東起　吳國蘭

摘要：云計算技術的發(fā)展飛快：VMware 2011年9月發(fā)布vSphere 5.0、歷經5.1、5.5、6.0、2016年11月推出vSphere 6.5，對于一款商業(yè)平臺軟件來說，算得上發(fā)展迅猛。OpenStack 2010年開始正式發(fā)布，每半年推出一個新版本，目前已是第15個版本-Ocata（2017年2月推出）；新版本相對于上一個版本完善了原有的功能，也擴展了很多新的功能。這兩款云平臺軟件在IaaS方面的表現(xiàn)各有千秋，該文以這兩個平臺下的VM批量部署的例子進行比較，進而分析、總結了OpenStack和VM-ware vSphere在資源調度上的異同、優(yōu)劣。

關鍵詞：云計算；虛擬機；虛擬機調度；資源分配；VMware vSphere；OpenStack

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2017）22-0028-04

1說明

1）本文中的斜體字表示該部分內容是變量，在具體操作中會有變化。

2）本文中的OpenStack指的是OpenStack 0cata版本，VM-ware vSphere指的是VMware vSphere 6.5。

3）本文中涉及兩種虛擬化平臺，各自有術語體系，有時難免混亂，為避免誤解，做以下說明：

VMware vSphere中的虛擬機（Virtual Machine）概念為大多數(shù)人所接受，但在OpenStack中又有兩種叫法：在dashboard（控制面板）中叫做instance（實例），在openstack命令行中則用server（可理解為“云服務器”淶表示，我用VM作為它們的統(tǒng)稱。

4）筆者是在基本相同的硬件環(huán)境下將VMware vSphere與OpenStack下部署多臺虛擬機的情況進行測試比較的，具體為：主機都是兩臺DELL PowerEdge R920服務器、同一個網(wǎng)絡環(huán)境、本地存儲；VMware vSphere的vCenter Server安裝在兩臺主機的其中之一上，OpenStack將其中一臺主機作為單一控制節(jié)點同時也是計算節(jié)點。

2VMware vSphere下虛擬機（Virtual Machine）的部署

筆者在VMware vSphere下完成虛擬機部署的系統(tǒng)架構如“圖1 VMware vSphere群集架構圖”所示：

為了實現(xiàn)我們的虛擬機部署方案，在物理機上安裝ESXi6.5后，依次做了以下工作：

1）在主機esxi-hostl上新建虛擬機，安裝操作系統(tǒng)Win-dows Server 2012（10.1.28.38），在系統(tǒng)上安裝配置Windows域，安裝SQL Server 2012，安裝配置vCenter Server 6.5，在vCenterServer上建立數(shù)據(jù)中心并添加兩臺主機-esxi-hostl、esxi-host2

2）創(chuàng)建主機群集MyCluster，包括主機esxi-hostl、esxi-host2，并啟用DRS。

3）創(chuàng)建vSphere分布式交換機（vSphere Distributed Switch）

4）創(chuàng)建虛擬機模板CIRROS-TEMPLATE

5）新建一臺Windows Server虛擬機，并在其上安裝Power-CLI6.5.1（接下來的腳本將在這臺虛擬機上運行）為了與后述的OpenStack環(huán)境下的VM部署相對比，我在VMware vSphere環(huán)境下沒有使用vSphere web client圖形界面創(chuàng)建虛擬機（vSphereweb client圖形界面也不支持批量部署虛擬機），而是使用Pow-erCLI腳本來創(chuàng)建。

下面是PowerCLI批量部署虛擬機的腳本代碼，該腳本完成的主要操作是：

以administrator身份連接vCenter Server（10.1.28.38），獲取創(chuàng)建虛擬機的模板（CIRROS-TEMPLATEJ，獲取群集（MyClus-ter），設置虛擬機名稱前綴（vmname-），使用循環(huán)語句foreach在群集上建立15臺虛擬機，建立虛擬機DRS組（vmGrp），建立主機DRS組（vmHostGrp），創(chuàng)建虛擬機一主機DRS規(guī)則（MyRule），即虛擬機“vmname-1”，“vmname-2”，“vmname-3”必須運行在主機“esxi-hostl”之上，虛擬機“vmname-4”，“vmname-5”，……，“vm-name-15”則由DRS群集自動調度。

該腳本的具體內容如下：

3OpenStack下實例（Instance）的部署

筆者在OpenStack下完成實例部署的系統(tǒng)架構如“圖2節(jié)點服務視圖”所示：

兩臺主機的名稱分別是Umaster50（是控制節(jié)點，同時也是計算節(jié)點）、Ucomputer51（計算節(jié)點），都是先最小化安裝操作系統(tǒng)ubuntu 16.04，然后安裝配置如“圖2節(jié)點服務視圖”所示的服務，具體過程不是本文重點，在此略過。

正式部署實例前，先要為OpenStack用戶建立環(huán)境，即將用戶名、密碼、項目名稱、域名稱、認證URL等信息導出到對應的系統(tǒng)環(huán)境變量中，為操作方便起見，我們一般用一個腳本來實現(xiàn)，比如下面的n14_openrc文件：

有了上面的客戶端腳本，如果想以域default，項目n14和用戶n14-1的身份運行openstack客戶端，只需要以如下格式加載

$.n14_openrc

同樣，OpenStack管理員（admin）用戶也可以使用類似的腳本建立工作環(huán)境，文中用admin_openrc表示該腳本名稱，其具體內容在此略過，可參照n14_openrc。endprint

在創(chuàng)建實例（instance）/云服務器（sgiver）之前，一般情況下要確定的幾個要素是：實例類型（flavor）、鏡像（image）、網(wǎng)絡（net-work）、安全組（security-group）、密鑰對（key-pair）、實例名稱。

實例類型定義了實例對CPU、內存、磁盤的需求；鏡像定義了實例的源（類似于VMware vSphere里的模板，包含了實例的操作系統(tǒng)和其他的軟件）；網(wǎng)絡定義了實例所在的網(wǎng)絡；安全組用來控制進出實例的流量（相當于實例外部一道防火墻）、密鑰對定義了公鑰和私鑰用以登錄實例。

以下命令可以登錄到任一節(jié)點上運行，也可以把它們保存在shell腳本中，具體功能依次是OpenStack管理員用戶建立實例類型（名字為m1.nano）、鏡像（名字為cirros）、外部網(wǎng)絡（名字為providerl；OpenStack普通用戶n14-1建立自定義網(wǎng)絡（名字為seffl4，網(wǎng)絡id為ed8be57e-9695-411e-822d-030909b03feJ）、路由器（名字為routerl4）、安全組（名字為default）、密鑰對（名字為mykey），服務器組的（名稱為grp-1）：

下面一組命令先建立具有互斥策略的服務器組，然后新建13個實例，并應用該服務器組策略一將這些實例盡可能分散在不同的主機上f如果有13臺以上的主機可用，將在優(yōu)先級較高的13臺主機上分別建立13個實例，但在我們的實驗環(huán)境下只有兩臺主機，這一部署策略的特點沒有充分體現(xiàn)出來），接著獲取第一個實例的信息，最后建立的兩個實例cosvm-1、cosvm-2與第一個實例civm-1在同一主機上（假設d821cd84-6f03-4afa-98b8-cf077fde0487就是civm-1的UUID）。

上述操作在OpenStack的horizon圖形界面下也可以非常方便地完成。

4VMWARE VSPHERE、oPENSTACK在資源調度上的比較

對任何一種提供IaaS服務的云平臺來說，資源無非是CPU、內存、電源、存儲器和網(wǎng)絡資源。經過在VMware vSphere、OpenStack下部署虛擬機/實例的體會，筆者認為二者在資源調度上有以下區(qū)別：

1）從資源調度的工作方式上來說，VMware vSphere對資源分配的主要機制是通過對資源的份額、預留和限制的配置來實現(xiàn)的，在啟用DRS（vSphere Distributed Resource Scheduler-分布式資源調度）群集、數(shù)據(jù)存儲DRS群集、OVS…的情況下，可以在群集層次上調度資源。

OpenStack中對實例的管理是通過核心組件nova來實現(xiàn)的。nova的架構比較復雜，包含很多組件，其中nova-scheduler實現(xiàn)實例資源調度服務，也就是負責決定在哪個計算節(jié)點上運行新建實例，以及如何分配資源。新建實例的調度過程分為兩步：

（1）通過過濾器（filter）選擇滿足條件的主機一計算節(jié)點（運行nova-compute的節(jié)點）

（2）通過權重計算（weighting）選擇在最優(yōu)（權重值最大）的主機上創(chuàng)建實例（Instance），即過濾器過濾出可用的主機列表后，調度器會對每個可用主機進行加權計算，算出各主機的權重，再根據(jù)權重選中優(yōu)先級最高（權重最大）的主機為實例分配資源。加權的計算方法就普通的加權算法，假設加權指標為w1、w2等，那么公式就是：

權重=w1加權系數(shù)。w1基準值+w2加權系數(shù)*w2基準值+…

w1、w2這些指標由配置文件nova.conf中的選項fil-ter_scheduler.weight_classes設置，其默認值是nova.scheduler.weights.all_weighers，即默認表示采用以下加權指標來計算權重：

RAMWeigher（可用內存）、DiskWeigher（磁盤空閑空間）、MetricsWeigherf根據(jù)metrics_weight_setting設置的公式計算權重）、IoOpsWeigher（主機IO負載）、PCIWeigher（PCI設備數(shù)量）、ServerGroupSoftAffinityWeigherf運行的屬于同一個服務器組的實例數(shù)，正值）、ServerGroupSoftAntiAffinityWeigher（運行的屬于同一個服務器組的實例數(shù)，負值）。

2）從資源調度的指標上來說，VMware vSphere對CPU、內存以及存儲IO配置份額、預留和限制，具體點說就是可以基于份額分配占資源提供方的總的百分比，或者分配所保證的最少資源預留量，或者設置資源使用的上限。VMware vSphere要實現(xiàn)自動化的資源調度需定義DRS群集，即當需要在DRS群集上新建虛擬機的時候，系統(tǒng)會根據(jù)設置采用兩種不同的處理方式：

（1）自動選擇合適的主機、存儲運行虛擬機。

（2）顯示虛擬機運行位置、存儲位置的建議，用戶可以選擇接受或覆蓋。

在DRS群集上可以使用關聯(lián)性規(guī)則，控制群集內主機上的虛擬機的放置位置?？梢詣?chuàng)建兩種類型的規(guī)則：

（1）用于指定虛擬機組和主機組之間的關聯(lián)性或反關聯(lián)性。關聯(lián)性規(guī)則規(guī)定，所選虛擬機DRS組的成員可以或必須在特定的主機DRS組成員上運行。反關聯(lián)性規(guī)則規(guī)定，所選虛擬機DRS組的成員不能在特定的主機DRS組成員上運行。

（2）用于指定各個虛擬機之間的關聯(lián)性或反關聯(lián)性。指定關聯(lián)性的規(guī)則會使DRS嘗試將指定的虛擬機一起保留在同一臺主機上。根據(jù)反關聯(lián)性規(guī)則，DRS嘗試將指定的虛擬機分開，例如，當一臺主機出現(xiàn)問題時，將不會同時丟失兩臺虛擬機。

OpenStack默認在所有可用主機上調度實例，對資源調度的指標粒度要比VMware vSphere的更精細，而且可以更方便地自定義過濾指標，由于可用于過濾的具體指標很多（參見Open-Stack官方手冊），并且用戶還可以自定義過濾指標，故此不可能一一說明，下面我們列舉nova默認調度器Filterscheduler的主要過濾指標：endprint

RetryFilter：重試過濾器，可以過濾掉在以前的調度中不成功的主機。

AvailabilityZoneFiher：為提高容災性和提供隔離服務，可以將主機劃分到不同的區(qū)域（Zone）中，在創(chuàng)建實例的時候可以指定實例創(chuàng)建在哪個可用區(qū)域中。

RamFiher：內存過濾器，將不能滿足flavor（實例類型）內存需求的主機過濾掉。

DiskFiher，：磁盤過濾器，將不能滿足flavor（實例類型）磁盤需求的主機過濾掉。

ComputeFilter：計算過濾器（保證只有nova-compute服務正常工作的主機—計算節(jié)點才能夠被nova-scheduler調度）

ComputeCapabilitiesFilter，：主機（計算節(jié)點）特性過濾器，如主機架構等。

ImagePropertiesFilter，：鏡像屬性過濾器，依據(jù)鏡像屬性進行過濾，如：架構（architecture）、虛擬機監(jiān)視器類型（hypervisortype）等。

Hosts Aggregates（主機聚合）：主機聚合過濾器，根據(jù)主機聚合的CPU內核數(shù)、內存空間、磁盤空間、實例數(shù)、IO負載等指標對主機聚合進行過濾。

IoOpsFiher：并發(fā)IO操作過濾器，可以過濾掉并發(fā)IO操作超過max_io_ops_per_host的值的主機。

SameHostFiher、DifferentHostFiher：將新建實例調度到與其它實例相同或不同的主機上。

SimpleCIDRAffinityFilter：主機IP過濾器，可將實例調度到指定IP地址段的主機上。

ServerGroupAffinityFiher、ServerGroupAntiAffinityFiher：服務器組調度器，可以調度同一服務器組的實例位于相同主機上，或位于不同的主機上。

OpenStack不僅可以依據(jù)計算資源、存儲資源、網(wǎng)絡資源屬性對主機進行過濾，還可以依據(jù)單元（cell）屬性對主機進行過濾。

3）從高可用（HA）的角度，尤其是VM的高可用來看，VM-ware vSphere明顯走在前面一通過DRS群集實現(xiàn)兩個級別的高可用：vSphere HA能讓故障虛擬機快速恢復、vSphere Fault Tol-eranee能保證虛擬機的持續(xù)可用。此外DRS群集的DPM（vSphere Distributed Power Management）功能可以根據(jù)群集資源利用率來打開和關閉主機電源，從而減少總體功耗。簡單說，就是當DMP檢測到群集中有足夠多的空閑資源的時候，會關閉一臺或多臺主機以減少能耗；反之，當檢測到空閑資源較少的時候，會打開處于待機狀態(tài)的主機，并使用VModon將虛擬機遷移到這些主機上。而OpenStack實例的高可用還沒有統(tǒng)一的解決方案，相關工作組正在進行這方面的工作，還處于初級階段。

4）從用戶的角度來看，OpenStack的控制節(jié)點管理所有資源，用戶在使用資源的時候只需要向控制節(jié)點提出請求，具體的資源分配對用戶來說是透明的；VMware vSphere的vCenterServer雖說管理所有資源，但作用更像是一個統(tǒng)一的頂層接口，用戶在使用資源的時候要指明計算資源、存儲資源的名稱、位置等信息。

5）從批量部署的角度來說，OpenStack無論是在dashboard的horizon界面中還是命令行下，都可以輕松進行批量部署；VMware vSphere下的Web Chent每次只能創(chuàng)建一個虛擬機，如果要批量部署，就要通過稍顯麻煩的腳本來實現(xiàn)。

6）從創(chuàng)建VM的效率上來說，同等條件下，OpenStack創(chuàng)建實例的效率要比VMware vSphere創(chuàng)建虛擬機的效率高出許多，可以說不可同日而語。

7）從資源調度的自主性來說，OpenStack作為開源軟件，可以自定義資源調度方案、可以選擇使用其它調度器分配資源，而VMware vSphere當然不會允許用戶做這些自定義設置。

5結論

經過對上述兩種平臺的學習，以及本人在實際工作中使用這兩種平臺的體驗，我認為在資源調度方面VMware vSphere仍然是傳統(tǒng)虛擬化思維方式，而OpenStaek則是開放融合的云計算思維方式，從前文的對比中看出，除了在VM的高可用性方面OpenStaek稍遜一籌外，資源調度的其它方面OpenStack均表現(xiàn)出色。當然VMware vSphere在文檔質量、易用性、某些性能的穩(wěn)定性方面目前還是要強于OpenStaek。

使用VMware vSphere和OpenStack兩款產品的對比，感覺就像是網(wǎng)絡環(huán)境下使用Windows服務器和Linux服務器的對比：一商業(yè)、一開源；一易上手、一難入門；一自成體系、一組件成堆由用戶組裝；一成熟但前景不明、一青澀但潛力無限；一風光不再、一擁者日眾……。

對IT工程人員來說，0penStaek相對于VMware vSphere的優(yōu)勢不僅體現(xiàn)在資源調度上，盡管部署一個OpenStack私有云環(huán)境要耗費的精力遠多于VMware vSphere，但從系統(tǒng)運行效率、運維的性價比上來說，開始階段的付出絕對是值得的。就像當年我們掌握了Linux服務器，就覺得不用考慮購買Win-dows服務器一樣。endprint