一種基于Xen的云基礎設施管理平臺構建方法

宋 勇，蔡志平

(1.湖南民族職業學院，湖南岳陽 414000；2.國防科技大學計算機學院，湖南長沙 410073)

1 研究背景

伴隨著以智能化制造為主要特征的工業4.0時代來臨，歷經近十年高速發展的云計算技術正在全球范圍內掀起大數據應用的浪潮[1]。作為云計算的技術基石，虛擬化技術不斷豐富著云計算的內涵，并衍生出多樣化的架構和理念。由于云計算本質上是一種基于基礎設施共享的租賃服務，用戶通過按需付費的形式，獲取高效的云計算服務，因此，基礎設施即服務(IAAS)被業界公認為最具發展前景的云計算服務[2]。

OpenStack是一款應用廣泛的IAAS開源管理工具[3]，其核心代碼由NASA和Rackspace共同捐獻，支持市面主流虛擬機平臺的管理，如VMWare、Xen、KVM等。距2010年7月OpenStack發布第一個版本Austin到今天，已經有6年多的時間，伴隨它蓬勃發展的同時，也暴露了諸多亟待解決的問題，例如：OpenStack尚缺少完善的多租戶理念，權限和角色模型還不成熟,缺少可信驗證等安全業務功能等。

針對上述存在的問題，本文從軟件架構的角度對OpenStack內部組件特性和管理平臺實現進行了分析與探索，利用XenServer提供的大規模、成熟的API免費接口搭建多“租戶”的、可審計、安全可信的虛擬化云計算平臺，并在此虛擬化環境中通過部署多節點的OpenStack服務器來構建IAAS管理平臺，并以IOZONE進行了云服務實際性能的測試。本文的研究工作可為虛擬化環境下IAAS平臺的構建和研究提供有益借鑒。

2 基于Xen的云計算平臺構建

2.1 XenServer的API

當前，虛擬化平臺產品的競爭主要集中在VMWare、Windows Server Hyper-V和Citrix XenServer之間[4]。其中，XenServer的免費版本對開發者提供了免費的API接口，開發者可以通過調用API開放接口來實現云計算中資源動態調整、彈性計算、高可用、應用的快速部署等高級功能[5]。

2.2 XenServer CPU池的異構管理

在實際的配置過程中，由于Resource Pool的配置通常存在不同的時序，服務器主機之間的CPU易形成異構關系[6]，需要對各主機的CPU進行異構管理，其基本配置過程如下：①確認主機的CPU類型，并通過xe host-cpu-info命令獲取各主機的CPU Feature值；②將上一步驟中獲取的CPU Feature 值逐一進行AND運算操作，獲取下一運算環節中所需的Common Mask值；③逐一對所有的XenServer Host使用命令xe host-set-cpu-features features=*(*是Common Mask值)設置好CPU Feature的Common Mask值，重啟主機后生效；④最后將已經修改好CPU Feature的XenServer Host加入到同一個Pool池中。

當XenServer Host退出Resource Pool后，許可服務器的注冊信息會隨著本地存儲格式化而被清空，因此，異構管理需要重新注冊上述信息。

2.3 平臺安全性設計

為了確保云平臺的可信性，需對開源XenSever進行可信化設計，其中一個主要的手段便是引入虛擬機監視器機制，將其內核精簡為可信域，作為云平臺運行的安全支撐基礎。在此基礎上，再定義一個用于系統可信服務管理的安全域，為高可信級別的用戶、服務和應用提供運行規則，同時創建多個計算節點虛擬機實例域，為普通用戶、服務和應用提供運行規則。對于上述域，制定如下運行規則：(i)安全域與可信域之間僅支持單向通信，即只允許可信域讀取安全域寫到計算節點虛擬機實例中某個固定區域的數據，反之則不行；(ii)計算節點虛擬機實例域中，應用程序通過標準的系統調用接口請求系統的內核服務，并通過可信域中的虛擬化引擎訪問系統資源。可信服務運行規則的流程如圖1所示。

圖1 平臺可信性運行規則流程圖

圖1中，應用程序通過定制的API接口請求計算節點虛擬機實例域中系統的內核服務，經過驗證后，系統內核發現是可信服務的系統調用，便按照運行規則(ii)將該請求轉發給可信域；可信域按照運行規則(i)將該定制的請求單向發給系統安全域的定制安全內核，經過驗證后，定制安全內核通知可信服務，并存儲在計算節點虛擬機實例域中指定位置，等待計算節點虛擬機實例域中的應用程序讀取。

為了證明上述設計的安全性，需要從兩方面的威脅來評估：一方面源自系統安全域的攻擊；另一方面源自計算節點虛擬機實例域的攻擊。在證明前首先進行下述定義：

sys表示系統，vss表示安全域，vcs表示計算節點虛擬機實例域，vsm表示虛擬機監視器，P(T)代表程序T可能造成破壞的概率。

本系統被攻破的概率是源自系統安全域攻擊與計算節點虛擬機實例域攻擊所造成的破壞概率之和，記為：

P(T)=P(Tvss)+P(Tvcs).

(1)

其中，P(Tvss)是源自安全域攻擊可能造成破壞的概率，可以表示為：

(2)

其中，Pott(t1)指包含其它威脅的代碼可能破壞的概率。

在(1)式中，P(Tvcs)是指源自計算節點虛擬機實例域攻擊可能造成破壞的概率，可以表示為：

(3)

傳統的虛擬機系統，被破壞的概率P′(T)主要由包含威脅的代碼Tm與包含BUG的代碼Ts所造成破壞的概率構成，可以表示為：

(4)

由于虛擬機監視器的源代碼數量遠遠小于傳統虛擬機系統的源代碼數量，因此下述公式成立。

(5)

由(5)式可以得出，本平臺的系統安全性優于傳統的虛擬機平臺。

3 OpenStack多節點部署

OpenStack主要部署形式可以劃分為控制型和計算型兩種類型，控制型節點運行nova-network組件，計算型節點運行nova-compute組件[7]。典型的OpenStack分布式多節點部署方式如圖2所示。

圖2 多節點IAAS平臺拓撲圖

圖2中控制節點運行了包括nova-api、nova-network、keystone、nova-scheduler等多個組件，用于管理計算型節點。計算型節點與hypervisor交互，負責管理虛擬機實例的狀態及其他用戶元數據和參數。圖2中還包括GlanceISO鏡像庫和數據庫(MySQL)節點。本文采用OpenStack官網推薦的All-in-ONE配置模式，進行多節點的部署。該模式將所有組件都配置運行在一臺物理機上，通過FlatDHCP方式動態分配各虛擬機實例的IP地址，如圖3所示。

在實際的配置過程中，通常將內部的組件運行在不同的虛擬機實例中，如圖4所示。圖中domain0是物理機安裝XenServer后自動產生的高權限虛擬機，可直接同虛擬化層的hypervisor交互。通過Xencenter客戶端可以在XenServer上管理虛擬機實例，但是對物理機高權限的配置則需要使用xe命令行工具。由于僅需要一臺物理機，因此只用一塊物理網卡eth0即可，eth0用于外部通信。

圖4 基于XenServer的All-in-ONE多節點配置模式

在XenServer上部署OpenStack之前，需要創建一個VLAN網絡，專門用于類似圖2中各虛擬機實例的交互，為避免混淆，需要區分此處提到的虛擬機是指計算節點生成的虛擬機，而在All-in-ONE配置模式中，是指XenServer上虛擬機中的虛擬機，后者僅出現在開發、測試、調試的場景中，在真實的生產環境下是不會出現的。

安裝配置好nova-controller-node，控制節點會啟動nova-api、nova-network、nova-scheduler、glance-api、glance-registry等服務，其中nova相關服務會注冊到數據庫的service表中。nova客戶端用戶通過命令行“nova-manage service list”可查看當前nova服務的狀態。類似地，安裝配置好nova-compute-node，計算節點會啟動nova-compute服務，同時根據配置文件中的nova-url通知nova-controller-node，并注冊到數據庫的compute_nodes表中。所有部署成功之后，可以通過命令行或Harizon操作OpenStack云平臺，其基本的操作流程描述如下：①創建租戶和租戶內的用戶，并賦予管理員admin權限；②用戶上傳虛擬機鏡像image；③啟動image創建虛擬機實例；④向虛擬機實例注入元數據。

4 性能測試

測試采用的工具軟件是IOZONE3.0。測試分兩個階段進行，每個階段各針對一種典型的云計算應用場景進行性能測試。

4.1 容錯性能測試

圖5 測試拓撲圖

用于測試的環境包括1個標準機柜，裝配有4臺機架式服務器，其中2臺是OpenStack管理服務器，3臺是存儲服務器，采用N+1冗余方式進行數據保護。用作計算服務節點的塔式服務器有6臺，各服務器的操作系統均為Red Hat Enterprise Linux5(64bits)，另外，用戶可以根據需要增設認證服務器。OpenStack管理服務器組成1個Pool，以Pool連接到存儲節點的1個卷中。WS-C2960S交換機用于OpenStack和XenServer的通信，同時也是管理存儲的網絡設備，以便OpenStack能夠控制XenServer工作。測試虛擬機實例由OpenStack創建，用戶設定虛擬機模板，然后分別在scheduler、networking、spawning和active階段，nova控制模塊完成尋找計算節點、分配固定IP、啟動虛擬機、注入用戶元數據等動作，在active狀態下，代表虛擬機成功創建并啟動。測試環境的拓撲結構如圖5所示。

給上述設備加電，待系統自檢和初始化完成后，存儲節點設備掛載妥當，輸出標準的NFS服務。此時隨機關閉云平臺中任一臺存儲節點電源，驗證系統的數據是否完整，文件系統是否能夠正常訪問。參與測試的每個節點有一個靜態IP，每個靜態IP會對應若干FlatDHCP IP，這些FlatDHCP IP用于客戶端的IP地址分配，當某個節點的電源被關閉后，FlatDHCP IP會自動捆綁到其他節點，NFS服務并沒有中斷，當前業務仍然保持連接，無需重新連接。為確保平臺的容錯能力，實驗中需要調整計算節點的數量，來對比IOZONE聚合帶寬的波動，相關的測試參數如下：IOZONE-Recb rec.xls-t 3-r 16K-s 8G-i 0-+m./nodelist.natp-C。

隨機關閉節點電源后，測試結果顯示，IOZON測試時指定的臨時文件呈現持續增大趨勢，該節點上的FlatDHCP IP隨機轉移，重新將掉電節點加電后，IOZONE的操作沒有受到任何影響，數據完整，文件系統可以正常訪問，并且FlatDHCP IP通過平衡后又轉移回當前節點。測試完成后獲得的IOZONE聚合帶寬數據如表1所示。

表1 IOZONE聚合帶寬數據

從表1可以看出，不同計算節點帶來的影響是IOZONE的聚合帶寬受到影響，這是由于容錯操作的后臺恢復工作需要占用較多的CPU資源而導致的。需要指出的是，此處數據容錯測試性是針對節點的，而不是磁盤級別，即在N+1的容錯模式下，一個存儲節點中只要有1塊硬盤沒有出現問題，即使其它N塊硬盤出現了問題，也可以保證數據不丟失。這表明基于Xen的OpenStack多節點部署IAAS云平臺具有非常健壯的容錯性，可以為應用層提供良好的數據容錯服務。

4.2 讀寫性能測試

讀寫性能測試采用隨機基準測試模式，基準測試參數包括讀寫兩類，用于測試的數據塊包括0.5KB、4KB、16KB和32KB四個類型，初始并發數為500線程，測試頻率為每基準測試1分鐘。由于服務器cache的影響，如果測試文件太小，測試的結果將會極為優異。因此，為了規避測試數據的奇異值，獲得接近真實應用場景的測試數據，測試時需要創建大于swap規模的分區并掛載，并關閉cache，同時在壓力測試工具Tsung逐步加大存儲節點壓力的情況下，使用IOZONE按照以下兩種測試順序獲取基準文件讀寫參數：①順序存儲、100%讀；②50%順序、50%隨機存儲、50%讀、50%寫。兩輪測試結果如表2和表3所示。

表2 順序存儲和100%讀的測試參數

表3 50%順序、50%隨機存儲和50%讀、50%寫的測試參數

以上兩種順序的測試結果表明，節點越多在帶寬利用率、平均I/O響應時間和IOPS指標上的提升越明顯。另外，相對于較小的數據塊，數據塊越大，IOPS指標提升越明顯，最大增幅超過300%。但是與NFS存儲提供的帶寬相比較，帶寬利用率仍然較低，潛在提升空間較大，建議在預算充裕的前提下，適當增加分布式節點的數量，充分利用存儲帶寬，為云平臺的應用層提供更好的基礎設施支撐。

圖6 IOPS測試結果

接下來在所有主機上創建50個左右的虛擬機實例，留一臺掛載在存儲不同卷中的虛擬機實例暫時閑置，其余使用dd命令進行高強度的寫操作：

#dd if=/dev/zero of=/tmp/file.imgbs=1M count=99999999

然后用webbench增加測試壓力，用高并發流量訪問空閑虛擬機的某個大于swap的大文件，測試結果如圖6所示。

從圖6可以看出，在壓力流量較小的情況下，存儲的I/O性能達到了一個比較好的峰值，在增加的流量達到總吞吐量80%的時候，即341.2MB/s時，IOPS平均值為6000，未出現明顯衰減，處在一個相對穩定的狀態，IOPS的性能測試達到了預期目標。

5 結語

未來最有發展前景的云計算服務模式是基礎設施即服務(IAAS)[8]。簡單、冗余、可擴展的架構設計保證了OpenStack用于IAAS基礎管理服務的優越性。本文在研究了OpenStack及其基礎云平臺XenServer的特征和相關開源技術的基礎上，針對基于Xen技術的OpenStack IAAS平臺進行了基礎云平臺構建實現、CPU池異構管理、可信安全服務設計以及多節點部署等研究工作。文件基準讀寫性能的測試數據顯示，在繼承了開源Xen和OpenStack優勢的同時，本文研究構建的IAAS平臺能夠有效提高云平臺的安全性，并且具有良好的容錯能力和穩定的并發讀寫能力。在云計算蓬勃開展的形勢下，隨著Xen開源社區和OpenStack的不斷完善，基于Xen技術的OpenStack云基礎設施管理平臺將得到更廣泛的應用。