一種OpenStack的業(yè)務保障設計

陳墾

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

關鍵詞：OpenStack;云計算;HA

中圖分類號：TP39? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?文獻標識碼：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

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

圖1? ?虛擬IP的使用

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

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

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

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

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

Filter的過濾條件有許多，可以是可用域，內存，CPU，磁盤，image等等。當經過這些條件篩選后的節(jié)點就會進入weight的過程，即根據一定的評分標準進行優(yōu)先級的排序。比如默認為根據計算節(jié)點空閑的內存量計算權重值，空閑越多的節(jié)點權重越高，優(yōu)先級越高，會優(yōu)先承載實例，如圖2所示。

圖2? ?初始調度過程

1.2? ?OpenStack的HA

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

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

1. 系統(tǒng)停機

2. 數據丟失

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

圖3? ?實例的HA

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

OpenStack目前滿足其自身基礎結構服務的高可用性要求，這意味著接近百分百的正常運行時間對于OpenStack基礎架構本身來說是可行的[12]。但是，OpenStack不能保證單個客戶實例的可用性接近百分百。

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

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

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

2? ?應用DRS

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

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

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

2.1? ?OpenStack對接VMware的方案

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

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

VMware提供了一種用于OpenStack的計算驅動，名為VMware Nova vCenter Driver，其與OpenStack的交互如圖4所示。

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

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

VMware節(jié)點的配置和vCenter的安裝過程較為繁瑣且并非本文所關心的要點，因此本文不再詳細贅述。在成功配置好VMware節(jié)點并安裝好vCenter后，需要在OpenStack的控制節(jié)點上修改Nova服務的配置文件，即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é)點的IP，datestore的用戶名和密碼，集群的名稱等信息，這些信息都是在vCenter的安裝時指定的。

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

2.2? ?DRS功能的應用驗證

為了驗證對接后的DRS功能，在OpenStack平臺上建立好所需的資源，比如網絡，租戶，集群，硬盤等等。

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

圖5? ?云主機列表

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

圖6? ?DRS配置

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

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

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

圖7? ?虛擬機運行狀況

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

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

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

圖8? ?虛擬機遷移后運行情況

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

4? ?結? 論

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

參考文獻

[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，FANELLI M，FOSCHINI 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服務[J]. 計算機與網絡，2018（3）：60—63.

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

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