陳墾

摘? ?要：基于OpenStack云計(jì)算管理平臺(tái)的原生資源管理技術(shù)，通過對(duì)接兼容Vmware云計(jì)算管理平臺(tái)，來實(shí)現(xiàn)一種更為合理高效的業(yè)務(wù)保障技術(shù)。通過配置高可用HA來保障物理機(jī)、邏輯節(jié)點(diǎn)、裸機(jī)和虛擬機(jī)的業(yè)務(wù)可用性。通過可用域設(shè)置DRS來保障虛擬機(jī)的業(yè)務(wù)連續(xù)性。

關(guān)鍵詞：OpenStack;云計(jì)算;HA

中圖分類號(hào)：TP39? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?文獻(xiàn)標(biāo)識(shí)碼：A

A Business Support Design for OpenStack

CHEN Ken？覮

（Wuhan Research Institute of Posts and Telecommunications，Wuhan，Hubei 430079，China）

Abstract：This article achieve a more reasonable and efficient business support technology through docking compatible VMware Cloud management platform based on OpenStack Cloud computing management platform of native resource management technology. Securing the business availability of physical machines，logical nodes，bare metal，and virtual machines by configuring high-availability HA，and securing the business continuity of virtual machines by setting up DRS with available domains.

Key words：OpenStack;Cloud computing;HA

云計(jì)算以其高效迅捷的部署和靈活的資源管理得到了眾多支持，并且成為一種成熟的商業(yè)模式。云計(jì)算通過提供基礎(chǔ)設(shè)施或者平臺(tái)，來為用戶實(shí)現(xiàn)快速部署和應(yīng)用，并以租賃的方式盈利[1]。在如今龐大的網(wǎng)絡(luò)體系中，云計(jì)算的出現(xiàn)提高了資源的利用率，使得上層用戶能夠?qū)Ｗ⒂陂_發(fā)，而不受底層影響。可以說，云計(jì)算的發(fā)展是網(wǎng)絡(luò)發(fā)展的必然，也是未來最受關(guān)注的領(lǐng)域之一[2-3]。作為提供服務(wù)的云計(jì)算廠商來說，提供一種穩(wěn)定的計(jì)算與存儲(chǔ)業(yè)務(wù)才能夠獲得用戶的青睞。使用KVM虛擬化技術(shù)的OpenStack云計(jì)算管理平臺(tái)受其社區(qū)開源性的制約，并沒有采用Vmware、EC2、Xen等商用虛擬化技術(shù)的方案，而是自己開發(fā)了一套技術(shù)集。由于OpenStack是協(xié)同開發(fā)的產(chǎn)物，早期的版本并不重視業(yè)務(wù)穩(wěn)定性與可靠性管理，而是以有效性為主要目的[4]。隨著OpenStack版本的不斷迭代以及使用率上升，各種原生方案與第三方方案開始部署于各個(gè)OpenStack云計(jì)算商的產(chǎn)品中，其中比較流行的方案有兩種，一種是Load Balancer + Keepalive保證HA（High Availability）[5];還有一種是Load Balancer + Keepalive + Pacemaker + Corosync 配置 HA，它們都可以某種程度上保證OpenStack的業(yè)務(wù)可靠性[6]。然而以上方案存在一定的缺陷，Load Balancer雖然可以讓系統(tǒng)達(dá)到網(wǎng)絡(luò)訪問的負(fù)載均衡，但卻沒辦法解決內(nèi)存、CPU等資源的負(fù)載不均衡問題[7];Keepalive實(shí)際上是通過配置一個(gè)虛擬IP地址來隱藏實(shí)際節(jié)點(diǎn)IP，而虛擬IP作為一個(gè)分發(fā)訪問任務(wù)的中間站，將訪問均衡分配到不同的實(shí)際節(jié)點(diǎn)上，如圖1所示，同樣沒法直接均衡內(nèi)存與CPU的負(fù)載。本文基于OpenStack原生技術(shù)，結(jié)合VMware的技術(shù)，通過對(duì)接OpenStack與VMware平臺(tái)，從而調(diào)用DRS（Distributed Resource Scheduler）技術(shù)設(shè)計(jì)一種對(duì)OpenStack平臺(tái)下管理的實(shí)例進(jìn)行動(dòng)態(tài)資源調(diào)度的方案，先于負(fù)載超過閾值前均衡內(nèi)存與CPU，保障業(yè)務(wù)穩(wěn)定性[8]。

圖1? ?虛擬IP的使用

1? ?OpenStack原生業(yè)務(wù)保障

1.1? ?OpenStack靜態(tài)資源調(diào)度

業(yè)務(wù)保障基于OpenStack的資源調(diào)度，資源調(diào)度分為靜態(tài)調(diào)度與動(dòng)態(tài)調(diào)度，其中靜態(tài)調(diào)度是最為基本，也是實(shí)現(xiàn)正常功能所需的技術(shù)。靜態(tài)調(diào)度也可稱之為初始調(diào)度，它是實(shí)現(xiàn)實(shí)例（虛擬機(jī)）所進(jìn)行的最開始的步驟。OpenStack的虛擬機(jī)調(diào)度策略主要是由FilterScheduler和ChanceScheduler實(shí)現(xiàn)的，其中FilterScheduler作為默認(rèn)的調(diào)度引擎實(shí)現(xiàn)了基于主機(jī)過濾（filtering）和權(quán)值計(jì)算（weighing）的調(diào)度算法，而ChanceScheduler則是基于隨機(jī)算法來選擇可用主機(jī)的簡(jiǎn)單調(diào)度引擎[9]。在設(shè)計(jì)上，OpenStack基于filter和weighter支持第三方擴(kuò)展，因此用戶可以通過自定義filter和weighter，或者使用json資源選擇表達(dá)式來影響虛擬機(jī)的調(diào)度策略從而滿足不同的業(yè)務(wù)需求。

所謂filter，是在選取資源（主要是計(jì)算資源）時(shí)，設(shè)立一系列規(guī)則和門檻，從而使得OpenStack在創(chuàng)建實(shí)例時(shí)能夠盡量平衡，不會(huì)產(chǎn)生一臺(tái)機(jī)器超負(fù)荷運(yùn)轉(zhuǎn)而其他機(jī)器空閑的情況[10]。理想的情況下，所有的機(jī)器能均分所有負(fù)載，比如要運(yùn)行5個(gè)實(shí)例，那么就會(huì)依次運(yùn)行于5個(gè)計(jì)算節(jié)點(diǎn)上（如果計(jì)算節(jié)點(diǎn)數(shù)量大于或等于5）;如果要運(yùn)行3個(gè)計(jì)算節(jié)點(diǎn)，那么就有兩個(gè)節(jié)點(diǎn)運(yùn)行兩個(gè)實(shí)例，一個(gè)節(jié)點(diǎn)運(yùn)行一個(gè)實(shí)例，從而實(shí)現(xiàn)盡可能的平衡。

以上是一種理想的情況，實(shí)際情況是創(chuàng)建的實(shí)例有著不同的資源需求（比如所需內(nèi)存和CPU不同）。這就使得分配實(shí)例的時(shí)候不能單純的看數(shù)量，而應(yīng)當(dāng)考慮到資源，也就是從數(shù)量的平衡轉(zhuǎn)移到資源的平衡。假設(shè)所有計(jì)算節(jié)點(diǎn)的能力基本一致，實(shí)際情況可能會(huì)存在不同的實(shí)體機(jī)混用，這也造成了計(jì)算節(jié)點(diǎn)的性能不一致。同時(shí)，有些計(jì)算節(jié)點(diǎn)也運(yùn)行著其他服務(wù)，對(duì)內(nèi)存和CPU資源的過度占用可能會(huì)影響其他服務(wù)。因此，針對(duì)不同的實(shí)體機(jī)，可能會(huì)配置不同的規(guī)則，比如可以配置某個(gè)節(jié)點(diǎn)最多承載5個(gè)實(shí)例，或者配置其最多負(fù)載50%的內(nèi)存或CPU，以此來人為留出余裕。

Filter的過濾條件有許多，可以是可用域，內(nèi)存，CPU，磁盤，image等等。當(dāng)經(jīng)過這些條件篩選后的節(jié)點(diǎn)就會(huì)進(jìn)入weight的過程，即根據(jù)一定的評(píng)分標(biāo)準(zhǔn)進(jìn)行優(yōu)先級(jí)的排序。比如默認(rèn)為根據(jù)計(jì)算節(jié)點(diǎn)空閑的內(nèi)存量計(jì)算權(quán)重值，空閑越多的節(jié)點(diǎn)權(quán)重越高，優(yōu)先級(jí)越高，會(huì)優(yōu)先承載實(shí)例，如圖2所示。

圖2? ?初始調(diào)度過程

1.2? ?OpenStack的HA

實(shí)例創(chuàng)建之時(shí)OpenStack會(huì)進(jìn)行靜態(tài)的資源調(diào)配，這意味著分配好的資源在實(shí)例創(chuàng)建之后就不會(huì)進(jìn)行變化，但是實(shí)際應(yīng)用中這樣是存在風(fēng)險(xiǎn)的。某個(gè)計(jì)算節(jié)點(diǎn)可能會(huì)無法正常工作，比如網(wǎng)線斷開，電源斷開，或者是某人不小心重啟了網(wǎng)絡(luò)服務(wù)，以及其他種種導(dǎo)致不能正常承載實(shí)例的錯(cuò)誤。這樣的錯(cuò)誤一旦發(fā)生而實(shí)例無法繼續(xù)維持，可能會(huì)造成業(yè)務(wù)的中斷，也會(huì)成為云計(jì)算最大的風(fēng)險(xiǎn)。于是一種用于應(yīng)急災(zāi)備的方案被用于OpenStack——高可用HA。

高可用HA系統(tǒng)力求最大限度地減少以下問題：

1. 系統(tǒng)停機(jī)

2. 數(shù)據(jù)丟失

大多數(shù)高可用性系統(tǒng)僅在發(fā)生故障時(shí)才能保證防止系統(tǒng)停機(jī)和數(shù)據(jù)丟失。但是，它們也可以防止級(jí)聯(lián)故障，在這種情況下，一次故障的發(fā)生就會(huì)惡化為一系列相應(yīng)的故障。許多服務(wù)提供商保證服務(wù)級(jí)別協(xié)議 （SLA），包括計(jì)算服務(wù)的正常運(yùn)行時(shí)間百分比，該協(xié)議是根據(jù)可用時(shí)間和系統(tǒng)停機(jī)時(shí)間 （不包括計(jì)劃停機(jī)時(shí)間） 計(jì)算的[11]。

圖3? ?實(shí)例的HA

如圖3所示，OVM1和OVM2是兩個(gè)實(shí)例，通過Virtual IP可以依次訪問它們。當(dāng)它們都運(yùn)行了keepalive時(shí)，即使所在的Cluster發(fā)生了宕機(jī)，也可以安全轉(zhuǎn)移至其它可用的Cluster。

OpenStack目前滿足其自身基礎(chǔ)結(jié)構(gòu)服務(wù)的高可用性要求，這意味著接近百分百的正常運(yùn)行時(shí)間對(duì)于OpenStack基礎(chǔ)架構(gòu)本身來說是可行的[12]。但是，OpenStack不能保證單個(gè)客戶實(shí)例的可用性接近百分百。

集群最小數(shù)量被定義為一半以上的節(jié)點(diǎn)數(shù)量，高可用性環(huán)境中的每個(gè)集群都應(yīng)該有奇數(shù)的節(jié)點(diǎn)。如果多個(gè)節(jié)點(diǎn)失敗，使集群數(shù)量大小低于最小數(shù)量，則集群本身將故障。

例如，在七節(jié)點(diǎn)集群中，最小數(shù)量應(yīng)設(shè)置為 floor（7/2） + 1 = 4。如果最小數(shù)量是四個(gè)節(jié)點(diǎn)，而四個(gè)節(jié)點(diǎn)同時(shí)故障，則集群本身將故障;如果不超過三個(gè)節(jié)點(diǎn)故障，則集群繼續(xù)正常工作。如果拆分為三個(gè)節(jié)點(diǎn)和四個(gè)節(jié)點(diǎn)的分區(qū)，則四個(gè)節(jié)點(diǎn)的最小數(shù)量將繼續(xù)決定分區(qū)工作狀態(tài)。

當(dāng)四個(gè)節(jié)點(diǎn)同時(shí)故障時(shí)，集群也將繼續(xù)工作。但是，如果拆分為三個(gè)節(jié)點(diǎn)和四個(gè)節(jié)點(diǎn)的分區(qū)，三個(gè)節(jié)點(diǎn)的最小數(shù)量將使雙方都試圖隔離其他資源和主機(jī)資源。如果不啟用Fence，它將直接運(yùn)行每個(gè)資源的兩個(gè)副本。

2? ?應(yīng)用DRS

VMware的分布式資源調(diào)度（Distributed Resource Scheduler，DRS）可以持續(xù)不斷地監(jiān)控資源池的利用率，并能夠根據(jù)商業(yè)需要在虛擬機(jī)中智能地分配合適的資源。通過這樣的動(dòng)態(tài)分配和平衡計(jì)算資源，IT架構(gòu)和商業(yè)目標(biāo)就可以達(dá)成同步。VMware DRS能夠整合服務(wù)器，降低IT成本，增強(qiáng)靈活性;通過災(zāi)難修復(fù)，減少停機(jī)時(shí)間，保持業(yè)務(wù)的持續(xù)性和穩(wěn)定性;減少需要運(yùn)行服務(wù)器的數(shù)量以及動(dòng)態(tài)地切斷當(dāng)前未需使用的服務(wù)器的電源，提高了能源的利用率。

DRS與HA原本是VMware的技術(shù)，隨著VMware進(jìn)入OpenStack社區(qū)并提供支持后，兩者之間的融合逐漸加深。在新的OpenStack版本中，對(duì)接VMware虛擬機(jī)以及相應(yīng)的HA與DRS技術(shù)已經(jīng)可以實(shí)現(xiàn)。

DRS可以在平臺(tái)平穩(wěn)運(yùn)行時(shí)根據(jù)配置，協(xié)調(diào)各個(gè)節(jié)點(diǎn)之間的負(fù)載，實(shí)現(xiàn)一定范圍的負(fù)載均衡。舉個(gè)例子，當(dāng)設(shè)置策略為CPU使用率平衡某個(gè)節(jié)點(diǎn)的CPU使用率，一旦超過了閾值，就會(huì)觸發(fā)DRS功能，節(jié)點(diǎn)上就進(jìn)行相應(yīng)操作來使得CPU降低到某一水平（通常是執(zhí)行遷移實(shí)例來釋放CPU資源），同樣的，也可以設(shè)置內(nèi)存模式來達(dá)到控制內(nèi)存使用率。

2.1? ?OpenStack對(duì)接VMware的方案

在OpenStack的新版本中，社區(qū)在Nova中提供了兩種連接VMware的Driver，分別是ESXDriver和VCDriver。前者由于丟失了一些VMware的集群特性諸如HA和DRS，已經(jīng)逐漸被拋棄，因此本文選擇后者作為接口驅(qū)動(dòng)。

由于需要納管VMware虛擬機(jī)，而OpenStack原生的KVM與VMware是不同的虛擬化方式，因此我們需要使用一個(gè)獨(dú)占的物理節(jié)點(diǎn)來配置VMware。并且由于VCDriver的局限性，我們還需要在VMware的節(jié)點(diǎn)上安裝vCenter。

VMware提供了一種用于OpenStack的計(jì)算驅(qū)動(dòng)，名為VMware Nova vCenter Driver，其與OpenStack的交互如圖4所示。

實(shí)際上OpenStack只是起到一個(gè)控制的作用，由控制節(jié)點(diǎn)下發(fā)指令，最終還是靠vCenter來完成ESXi主機(jī)的控制。上文提到的VMware vCenter Driver會(huì)讓Nova-Scheduler將ESXi主機(jī)看作OpenStack中一個(gè)普通的計(jì)算節(jié)點(diǎn)進(jìn)行管理，這樣在OpenStack看來，納管的VMware主機(jī)就不具有太多的特殊性，只要通過驅(qū)動(dòng)進(jìn)行中間代理就能夠下發(fā)指令。

圖4? ?Nova vCenter Driver與OpenStack的交互

VMware節(jié)點(diǎn)的配置和vCenter的安裝過程較為繁瑣且并非本文所關(guān)心的要點(diǎn)，因此本文不再詳細(xì)贅述。在成功配置好VMware節(jié)點(diǎn)并安裝好vCenter后，需要在OpenStack的控制節(jié)點(diǎn)上修改Nova服務(wù)的配置文件，即nova.conf文件，具體配置如下：

[DEFAULT]

compute_driver=vmwareapi.VMwareVCDriver

[vmware]

host_ip=

host_username=

host_password=

cluster_name=

datastore_regex=

wsdl_location=https：///sdk/vimService.wsdl? ? ? ? ? ? ? insecure=True

以上配置指定了VMware節(jié)點(diǎn)的IP，datestore的用戶名和密碼，集群的名稱等信息，這些信息都是在vCenter的安裝時(shí)指定的。

完成以上配置后，便可以在vCenter與OpenStack的Dashboard中看見新建的虛擬機(jī)，并且可以使用VMware的DRS特性。

2.2? ?DRS功能的應(yīng)用驗(yàn)證

為了驗(yàn)證對(duì)接后的DRS功能，在OpenStack平臺(tái)上建立好所需的資源，比如網(wǎng)絡(luò)，租戶，集群，硬盤等等。

如圖5所示，在UI界面上可以看見已經(jīng)建立了一些云主機(jī)，也就是實(shí)例，首先要確保這些云主機(jī)都在同一個(gè)節(jié)點(diǎn)上，并且該節(jié)點(diǎn)所在可用域有至少3個(gè)節(jié)點(diǎn)。

圖5? ?云主機(jī)列表

DRS進(jìn)程雖然在所有計(jì)算節(jié)點(diǎn)上都有安裝，但是只會(huì)在同一個(gè)可用域中的一個(gè)節(jié)點(diǎn)上運(yùn)行一個(gè)DRS進(jìn)程，也就是說，只有一個(gè)節(jié)點(diǎn)的DRS進(jìn)程是處于active狀態(tài)。但是所有的節(jié)點(diǎn)都需要配置統(tǒng)一的文件，以設(shè)定DRS服務(wù)的開啟與否，運(yùn)行的模式，閾值，輪詢周期等等參數(shù)。下面進(jìn)行DRS配置文件的設(shè)置，如圖6所示。

圖6? ?DRS配置

其中enable_global_mode = True表示全局模式，意味著無需對(duì)可用域進(jìn)行其他配置;rs_rule = cpu_percent表示CPU使用率模式;rs_threshold = 50表示閾值為50，即CPU使用率到達(dá)50%以上時(shí)會(huì)觸發(fā)DRS功能;rs_name = CPU utilization4為該DRS策略的名稱，方便區(qū)分;rs_enable = True表示DRS功能開啟，相當(dāng)于總開關(guān);rs_stabilization = 3 表示每3次輪詢時(shí)間執(zhí)行一次DRS。

要驗(yàn)證DRS功能，需要?jiǎng)?chuàng)造條件來觸發(fā)節(jié)點(diǎn)達(dá)到DRS閾值，一個(gè)方法就是使用人為加壓來讓計(jì)算節(jié)點(diǎn)達(dá)到閾值。通過編寫一個(gè)腳本，可以令計(jì)算節(jié)點(diǎn)不停的執(zhí)行某個(gè)命令，從而消耗大量CPU資源。在compute-0節(jié)點(diǎn)上運(yùn)行CPU加壓腳本后，使用TOP命令查看節(jié)點(diǎn)CPU資源使用情況。

設(shè)定CPU超過閾值并且穩(wěn)定10分鐘后執(zhí)行DRS，在等待10分鐘后，可以觀察到虛擬機(jī)開始執(zhí)行遷移，此時(shí)在控制節(jié)點(diǎn)上查看compute-0節(jié)點(diǎn)的虛擬機(jī)，如圖7所示。

圖7? ?虛擬機(jī)運(yùn)行狀況

在上圖可以看到，第三行的實(shí)例，狀態(tài)顯示migrating，也就是遷移，說明DRS功能觸發(fā)實(shí)例執(zhí)行遷移。

之前設(shè)定DRS執(zhí)行遷移周期為三個(gè)輪詢時(shí)間，一個(gè)輪詢時(shí)間為20秒，也就是大約一分鐘遷移一臺(tái)，直至CPU使用率降至閾值以下，實(shí)際上，在加壓腳本的影響下，哪怕沒有實(shí)例存在，CPU使用率也無法降低至50%以下，所以實(shí)例只會(huì)一直遷移，直至所有實(shí)例全部遷出，或者可用域內(nèi)其他節(jié)點(diǎn)無法承載。

30分鐘后，再次查看compute-0上的實(shí)例，如圖8所示。

圖8? ?虛擬機(jī)遷移后運(yùn)行情況

從上圖可以看出，對(duì)比執(zhí)行DRS之前，其上的實(shí)例已經(jīng)遷走許多，所有實(shí)例都可正常運(yùn)行。

4? ?結(jié)? 論

基于OpenStack原生功能的基礎(chǔ)上，通過對(duì)接VMware vSphere平臺(tái)，從而實(shí)現(xiàn)了HA與DRS的高級(jí)功能，設(shè)計(jì)了一種保障OpenStack云計(jì)算平臺(tái)業(yè)務(wù)的方案。本設(shè)計(jì)在保留OpenStack原有結(jié)構(gòu)的同時(shí)，引入了VMware的管理方式，使得該云計(jì)算管理平臺(tái)有著更好的兼容性，通過使用VMware成熟的設(shè)計(jì)，加強(qiáng)了OpenStack云計(jì)算管理平臺(tái)的穩(wěn)定性。該方案既可發(fā)揮災(zāi)備的作用，也可實(shí)現(xiàn)預(yù)防的功能，通過手工配置的方式可以讓用戶更加靈活的調(diào)整方案，具有廣泛的應(yīng)用場(chǎng)景。

參考文獻(xiàn)

[1]? ? NANDA S，CHIUEH T. A survey on virtualization technologies[R]. Technical Report，TR-179，New York：Stony Brook University，2005：1—42.

[2]? ? LI Y，LI W，JIANG C. A survey of virtual machine system：current technology and future trends[C]// International Symposium on Electronic Commerce & Security. IEEE Computer Society，2010：332—336.

[3]? ? ROSENBLUM M，GARFINKEL T. Virtual machine monitors：current technology and future trends[J]. Computer，2005，38（5）：39—47.

[4]? ? JACKSON K. OpenStack cloud computing cookbook[M]. Birmingham：Packt Publishing Limited，2012：151—154.

[5]? ? CORRADI A，F(xiàn)ANELLI M，F(xiàn)OSCHINI L. VM consolidation：a real case based on OpenStack cloud[J]. Future Generation Computer Systems，2014，32（1）：118—127.

[6]? ? VYAS U. HA in OpenStack[M]// Applied OpenStack Design Patterns. Apress，2016.

[7]? ? DU Q，QIU J，YIN K，et al. High availability verification framework for OpenStack based on fault injection[C]// International Conference on Reliability，Maintainability and Safety. IEEE，2017：1—7.

[8]? ? SAHASRABUDHE S S，SONAWANI S S. Comparing openstack and VMware[C]// International Conference on Advances in Electronics，Computers and Communications. IEEE，2015：1—4.

[9]? ? SHANMUGANATHAN G，GULATI A，VARMAN P. Defragmenting the cloud using demand-based resource allocation[J]. Acm Sigmetrics Performance Evaluation Review，2013，41（1）：67—80.

[10]? 毛軍禮. OpenStack之Nova服務(wù)[J]. 計(jì)算機(jī)與網(wǎng)絡(luò)，2018（3）：60—63.

[11]? 王侃，劉釗遠(yuǎn). 基于OpenStack云平臺(tái)的彈性資源配置系統(tǒng)[J]. 數(shù)碼世界，2018（3）：199—200.

[12]? 閆映東，文成玉. 中小企業(yè)OpenStack云平臺(tái)高可用技術(shù)研究與實(shí)現(xiàn)[J]. 無線互聯(lián)科技，2018（5）：131—132.