面向網(wǎng)絡(luò)性能優(yōu)化的虛擬計算資源調(diào)度機制研究

王煜煒，劉敏，房秉毅，秦晨翀，閆小龍

（1. 中國科學(xué)院計算技術(shù)研究所，北京 100190；2. 中國科學(xué)院大學(xué)，北京 100049；3. 中國聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司，北京 100032）

面向網(wǎng)絡(luò)性能優(yōu)化的虛擬計算資源調(diào)度機制研究

王煜煒1,2，劉敏1，房秉毅3，秦晨翀1,2，閆小龍1,2

（1. 中國科學(xué)院計算技術(shù)研究所，北京 100190；2. 中國科學(xué)院大學(xué)，北京 100049；3. 中國聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司，北京 100032）

針對基于Xen的vCPU調(diào)度機制對虛擬機網(wǎng)絡(luò)性能的影響進(jìn)行了深入研究和分析。提出一種高效、準(zhǔn)確、輕量級的網(wǎng)絡(luò)排隊敏感類型虛擬機（NSVM）識別方法，可根據(jù)當(dāng)前虛擬機I/O傳輸特征將容易受到影響的虛擬機進(jìn)行準(zhǔn)確識別和區(qū)分。進(jìn)而設(shè)計一種新型虛擬計算資源調(diào)度和分配機制 Diff-Scheduler，將不同類型虛擬機的vCPU實施分池隔離調(diào)度，同時提高NSVM類型虛擬機vCPU的調(diào)度頻率。原型系統(tǒng)實驗結(jié)果表明，相比Xen默認(rèn)的調(diào)度機制，Diff-Scheduler能夠大幅提高虛擬機網(wǎng)絡(luò)性能，同時保證計算資源分配的公平性。

云計算；虛擬化；vCPU調(diào)度；網(wǎng)絡(luò)排隊敏感型；虛擬計算資源分配

1 引言

當(dāng)前，云計算作為新興的計算服務(wù)方式得到了產(chǎn)業(yè)界、學(xué)術(shù)界的廣泛關(guān)注。亞馬遜[1]、谷歌[2]、微軟[3]以及國內(nèi)的阿里巴巴[4]、中國聯(lián)通[5]、中國移動[6]、中國電信[7]等企業(yè)和電信運營商均建立了自己的公有云和私有云平臺，從而可以為用戶提供高效、安全、靈活的計算服務(wù)。隨著以大數(shù)據(jù)為代表的分布式計算框架日益普及，大量執(zhí)行復(fù)雜且網(wǎng)絡(luò)吞吐量密集任務(wù)的應(yīng)用已經(jīng)移植到云平臺。

虛擬化作為云計算的重要核心技術(shù)使多個用戶可以高效、隔離地使用物理機資源。通常情況下，云計算服務(wù)提供商會將資源按照用戶需求以虛擬機（VM,virtual machine）的形式租用給用戶。不同用戶的虛擬機以資源共享的方式占用同一物理服務(wù)器的CPU、內(nèi)存、外設(shè)存儲以及網(wǎng)絡(luò)等資源。云計算服務(wù)商主要依托虛擬化監(jiān)管軟件Hypervisor實現(xiàn)對各個虛擬機的資源管理。典型的Hypervisor包括 Xen、KVM、Hyper-V、ESX-i等，其中，Xen作為主流的開源虛擬化平臺，已被國內(nèi)外眾多云計算服務(wù)提供商廣泛采用[8]。

然而，越來越多的研究表明[9～12]，虛擬化技術(shù)的引入給虛擬機網(wǎng)絡(luò)性能帶來了較大的負(fù)面影響。多個虛擬機共享物理服務(wù)器硬件資源，使采用虛擬化技術(shù)創(chuàng)建的虛擬機并不能完全提供等同于傳統(tǒng)物理機的特性。一方面，對于經(jīng)常執(zhí)行大量網(wǎng)絡(luò)應(yīng)用密集型通信任務(wù)的VM而言，執(zhí)行通信任務(wù)需要和執(zhí)行計算密集型任務(wù)的VM競爭計算資源；另一方面，虛擬化平臺提供的虛擬計算資源（vCPU,virtual CPU）調(diào)度機制未能充分考慮2種任務(wù)之間的競爭給網(wǎng)絡(luò)性能帶來的干擾，進(jìn)而造成虛擬機網(wǎng)絡(luò)性能受到顯著影響，具體表現(xiàn)在網(wǎng)絡(luò)吞吐量降低、延遲增大等。當(dāng)物理主機承載的計算負(fù)載較高時，此類影響尤為強烈。

本文針對基于Xen的vCPU調(diào)度機制對虛擬機網(wǎng)絡(luò)性能的影響進(jìn)行了深入研究，通過實驗驗證可知，vCPU調(diào)度機制帶來的虛擬機I/O共享環(huán)阻塞是造成其網(wǎng)絡(luò)性能下降的重要原因。為了保障網(wǎng)絡(luò)性能，需要解決以下幾個問題：1)明確vCPU調(diào)度機制干擾hypervisor的I/O通信系統(tǒng)的主要方式和影響要素；2)如何從所有虛擬機中選擇出對此類干擾敏感且受影響嚴(yán)重的虛擬機類型，進(jìn)而進(jìn)行區(qū)分式的調(diào)度處理；3)如何在不違背云計算資源公平共享原則的基礎(chǔ)上對計算資源進(jìn)行重新合理調(diào)配，從而有效減少網(wǎng)絡(luò)性能受到的影響[12]。

克服上述3個問題存在較大的技術(shù)挑戰(zhàn)。vCPU調(diào)度對網(wǎng)絡(luò)性能干擾的根本原因在于虛擬資源共享服務(wù)模式本身。因此，在現(xiàn)有基于Xen的虛擬化平臺中，設(shè)計實現(xiàn)既能保證計算資源分配公平同時又能為執(zhí)行網(wǎng)絡(luò)密集型任務(wù)的虛擬機提供區(qū)分式的調(diào)度策略面臨很大的挑戰(zhàn)。

本文圍繞面向網(wǎng)絡(luò)性能優(yōu)化的虛擬資源調(diào)度機制展開研究，基于上述核心問題及挑戰(zhàn)提出了有針對性的解決方案，主要創(chuàng)新貢獻(xiàn)如下。

1)通過實驗驗證對 vCPU機制影響虛擬機網(wǎng)絡(luò)傳輸過程進(jìn)行了詳細(xì)分析，進(jìn)一步明確I/O共享環(huán)中的請求項隊列長度變化是表征數(shù)據(jù)傳輸阻塞程度的重要指標(biāo)。

2)基于虛擬機接收和發(fā)送數(shù)據(jù)方向上I/O共享環(huán)溢出、過載及停滯特征，提出一種高效、輕量級的虛擬機類型識別方法，把虛擬機識別為網(wǎng)絡(luò)排隊敏感型虛擬機（NSVM,network queuing sensitive virtual machine）和非網(wǎng)絡(luò)排隊敏感型虛擬機（NNVM,non-network queuing sensitive virtual machine）2種類型。前者較后者更容易受到vCPU調(diào)度機制引起的資源競爭的影響。

3)提出了一種面向網(wǎng)絡(luò)性能優(yōu)化的新型虛擬計算資源分配及調(diào)度機制Diff-Scheduler，該機制優(yōu)化并改進(jìn)了Xen原有的vCPU調(diào)度機制，將NSVM與NNVM類型虛擬機的vCPU分池隔離與區(qū)分調(diào)度。

4)基于Xen 4.4研發(fā)了原型系統(tǒng)并進(jìn)行性能對比實驗。實驗結(jié)果表明，相關(guān)機制能夠大幅提高虛擬機網(wǎng)絡(luò)性能，并保證計算資源分配的公平性。

2 相關(guān)工作

諸多相關(guān)研究[11～18]表明，虛擬機網(wǎng)絡(luò)性能的下降與所屬虛擬化平臺提供的vCPU調(diào)度機制有關(guān)。文獻(xiàn)[11]針對虛擬化技術(shù)對Amazon EC2虛擬機網(wǎng)絡(luò)性能的影響進(jìn)行了研究，并對延遲、吞吐量及分組丟失率指標(biāo)進(jìn)行了測量。文中指出在數(shù)據(jù)中心網(wǎng)絡(luò)處于非擁塞的情況下，虛擬化技術(shù)的引入會導(dǎo)致網(wǎng)絡(luò)吞吐量及傳輸延遲等指標(biāo)顯著下降。但文中并沒有給出影響虛擬機網(wǎng)絡(luò)性能的具體原因。Shea等研究者在文獻(xiàn)[12]中指出，虛擬機同時執(zhí)行通信和計算任務(wù)的“雙重身份”是導(dǎo)致虛擬機網(wǎng)絡(luò)性能下降的根本原因。Xen中的 vCPU調(diào)度機制影響了虛擬機內(nèi)部 CPU對網(wǎng)絡(luò)相關(guān)任務(wù)的處理，進(jìn)而導(dǎo)致了虛擬機網(wǎng)絡(luò)性能下降。文中通過改變vCPU調(diào)度周期來緩解網(wǎng)絡(luò)性能影響，并通過簡單的 CPU隔離機制驗證其有效性。Gamage[13]和Kangarlou[14]針對 TCP應(yīng)用的發(fā)送過程和接收過程，在特權(quán)域Domain 0增加代理處理模塊，由其代替VM對相關(guān)TCP連接和數(shù)據(jù)分組傳輸進(jìn)行處理，從而保證發(fā)送/接收窗口大小，提高 TCP應(yīng)用的吞吐量。上述做法在提高TCP傳輸性能的同時給Domain 0域帶來較大的處理和存儲負(fù)擔(dān)，且針對其他類型數(shù)據(jù)分組，如UDP則無法進(jìn)行加速處理。Xu[15]提出將VM分為LSVM和NLSVM區(qū)分對待，并將LSVM的調(diào)度時間進(jìn)一步劃分成若干小的時間片，從而提高了LSVM的調(diào)度頻率，保障了LSVM的網(wǎng)絡(luò)性能。但是，文中并未明確如何具體識別 LSVM 和NLSVM，在VM較多的物理CPU共享隊列，LSVM仍需要等待較長時間才能贏得CPU時間片。Xu[16～18]提出以用戶為中心的VM傳輸延遲優(yōu)化方案，文中針對VM和VM之間的傳輸延遲進(jìn)行測量和分析，并給出了一種輕量級的測量VM受到競爭干擾的方法，用戶可以直接對所租用的各個VM當(dāng)前網(wǎng)絡(luò)性能進(jìn)行評估，并且按照評估結(jié)果將應(yīng)用任務(wù)進(jìn)行分配。該方法一定程度上避免了虛擬化技術(shù)對VM網(wǎng)絡(luò)延遲性能的影響，但以用戶為中心的方案并未從根本上解決上述性能下降問題，若不同的用戶同時采用上述策略，則會造成VM網(wǎng)絡(luò)性能的迅速下降。

上述方案從不同角度提出了改善虛擬機網(wǎng)絡(luò)性能的方法，但是尚未有方案能夠完整解決引言中提到的3個主要問題，并提出針對性的高效處理策略。

3 vCPU調(diào)度對I/O通信影響分析

本文從分析 vCPU調(diào)度機制對 Xen中虛擬機I/O通信機制的影響入手，基于I/O傳輸特征對VM類型進(jìn)行合理、準(zhǔn)確識別，提出一種面向網(wǎng)絡(luò)性能優(yōu)化的虛擬計算資源分配及調(diào)度機制Diff-Scheduler，可大幅度提升虛擬機的網(wǎng)絡(luò)性能。

3.1 基于Xen的vCPU調(diào)度機制

vCPU是由Hypervisor分配給VM的虛擬CPU，是虛擬化系統(tǒng)對其物理 CPU資源的抽象。系統(tǒng)運行過程中，VM分得的vCPU將在各個物理CPU核上形成等待調(diào)度的 vCPU隊列。vCPU調(diào)度是指Hypervisor挑選vCPU并分配其一段時間物理CPU使用權(quán)限的過程。合理的vCPU調(diào)度機制是VM高效執(zhí)行任務(wù)的關(guān)鍵。目前，Xen的穩(wěn)定版本默認(rèn)采用Credit Scheduler調(diào)度機制[19]，調(diào)度器依據(jù)Weight值為每個虛擬機分配其 Credit，同時為每個物理CPU維護(hù)一個vCPU隊列。當(dāng)vCPU沒有被調(diào)度時，就處于非活躍狀態(tài)。直至其下一次被調(diào)度時，才能重新處于活躍狀態(tài)。對于頻繁執(zhí)行網(wǎng)絡(luò)通信任務(wù)的VM而言，如果其vCPU長時間處于非活躍狀態(tài)，將會大大影響其網(wǎng)絡(luò)通信性能，下面將結(jié)合Xen的I/O通信機制進(jìn)行詳細(xì)分析。

3.2 基于I/O共享環(huán)的網(wǎng)絡(luò)數(shù)據(jù)傳輸

在Xen中，VM的網(wǎng)絡(luò)通信通過位于其內(nèi)部的前端設(shè)備和位于特權(quán)域Domain 0內(nèi)部的后端設(shè)備交互實現(xiàn)，如圖1所示，設(shè)備驅(qū)動采用前后端分離模型，分為前端驅(qū)動與后端驅(qū)動2部分。前端驅(qū)動位于VM域，后端驅(qū)動位于特權(quán)域Domain 0。前后端驅(qū)動通過 Xen提供的共享內(nèi)存機制進(jìn)行通信。VM發(fā)送和接收數(shù)據(jù)過程均對應(yīng)一個大小固定的共享I/O環(huán)型存儲隊列，用于存放數(shù)據(jù)分組收發(fā)過程的控制信息。其內(nèi)部存放著 2類數(shù)據(jù)結(jié)構(gòu)：請求（request）項與響應(yīng)（response）項。請求項與響應(yīng)項分別存入共享 I/O環(huán)并形成請求隊列與響應(yīng)隊列，且響應(yīng)隊列隊尾總是緊跟于請求隊列隊首之后。對應(yīng)發(fā)送和接收過程，相關(guān)的控制項包括“發(fā)送請求”（sending request）、“發(fā)送響應(yīng)”（sending response）、“接收請求”（receiving request）、“接收響應(yīng)”（receiving response）4種類型。

圖1 基于Xen的虛擬網(wǎng)絡(luò)I/O通信架構(gòu)

數(shù)據(jù)分組的收發(fā)與生產(chǎn)者和消費者之間傳遞商品的過程類似，以VM接收數(shù)據(jù)分組為例，首先，位于Domain 0的后端驅(qū)動從接收I/O環(huán)中取出“接收請求”，并將該數(shù)據(jù)分組存入共享內(nèi)存緩沖區(qū)域；同時，依據(jù)存有該數(shù)據(jù)分組的共享內(nèi)存頁 ID及數(shù)據(jù)偏移量等信息生成“接收響應(yīng)”，并將其放入接收I/O環(huán)指定位置；然后，通過事件通道通知前端驅(qū)動，前端驅(qū)動將“接收響應(yīng)”從I/O環(huán)中取出，并將從共享內(nèi)存緩沖區(qū)中接收到的數(shù)據(jù)分組交給虛擬機操作系統(tǒng)協(xié)議棧繼續(xù)處理。發(fā)送過程和上述接收過程類似。

3.3 vCPU調(diào)度對數(shù)據(jù)傳輸影響分析

上文中提到，VM的網(wǎng)絡(luò)性能受vCPU調(diào)度機制的影響。本文通過研究發(fā)現(xiàn)，共享 I/O環(huán)中請求項隊列長度是表征虛擬機當(dāng)前網(wǎng)絡(luò)傳輸擁塞狀況的重要因素。在數(shù)據(jù)傳輸過程中，共享 I/O環(huán)中請求項隊列長度會隨vCPU隊列等待延遲發(fā)生相應(yīng)變化，進(jìn)而影響虛擬機的網(wǎng)絡(luò)性能，這是影響虛擬機網(wǎng)絡(luò)性能的重要原因。下面通過具體實驗分別對vCPU不需排隊以及vCPU平均等待隊列長度為1的2種場景下VM吞吐量與請求項隊列長度變化關(guān)系進(jìn)行驗證分析。其中，vCPU不需排隊是指在宿主機計算資源充足，vCPU無需排隊等待可直接獲取CPU時間片的情況，簡稱Queue-0場景；vCPU平均隊列長度為 1指的是vCPU平均需要等待 1個調(diào)度周期（Xen默認(rèn)為30 ms）才能獲取 CPU時間片的情況，簡稱Queue-1場景。

為獲取相關(guān)信息，本文對Xen虛擬網(wǎng)絡(luò)設(shè)備后端驅(qū)動進(jìn)行修改，在用戶空間獲取 I/O共享環(huán)中的請求項隊列長度值。該值是個不大于256的非負(fù)數(shù)。當(dāng)共享 I/O環(huán)“溢出”時，測得的請求隊列長度已不能準(zhǔn)確代表其真實長度，本文將其校準(zhǔn)為最大值 256。這里的溢出并不是真正意義上的內(nèi)存堆棧溢出，而是對應(yīng)請求項、響應(yīng)項隊列長度加上本次待放入的請求項數(shù)量后大于等于最大值256的情況。此時表明I/O共享環(huán)發(fā)生了比較嚴(yán)重的擁塞，實際情況并不會出現(xiàn)真正的堆棧溢出，Xen系統(tǒng)設(shè)計了自適應(yīng)調(diào)節(jié)機制，采取相關(guān)退避或等待策略。

實驗環(huán)境如下：網(wǎng)絡(luò)拓?fù)洵h(huán)境由2臺服務(wù)器及連接它們之間的路由設(shè)備組成，如圖2所示。其中宿主機服務(wù)器S上部署Xen 4.4系統(tǒng)及本文所提的相關(guān)vCPU優(yōu)化調(diào)度功能模塊；另一臺服務(wù)器T作為測試對端，每臺服務(wù)器均配有8核物理 CPU、32 GB內(nèi)存和 2塊千兆局域網(wǎng)網(wǎng)卡。Domain 0特權(quán)域和測試用虛擬機內(nèi)運行的操作系統(tǒng)均為 Ubuntu14.04，內(nèi)核版本分別為 Linux 3.13.11和Linux 3.13.0。

圖2 實驗網(wǎng)絡(luò)拓?fù)洵h(huán)境

在宿主機服務(wù)器S上，除Domain 0之外共建立6個虛擬機，分別命名為VM1～VM6。虛擬機之間通過虛擬交換設(shè)備相連，進(jìn)而通過千兆高速局域網(wǎng)與測試對端服務(wù)器 T連接。各 VM 內(nèi)分別安裝Iperf[20]與 Sysbench[21]工具，用來生成 TCP、UDP等業(yè)務(wù)流和計算負(fù)載。同時可用 Iperf對吞吐量、分組丟失率和流量進(jìn)行監(jiān)測分析。

具體測試參數(shù)如下：Domain 0預(yù)分配了2個物理CPU與10 GB內(nèi)存空間。VM1～VM6各自被預(yù)分配2 GB內(nèi)存；實驗中采樣周期Tm為10 ms，識別周期Ts為100 ms。

實驗中默認(rèn)將2個CPU預(yù)分配給Domain 0域。Queue-0場景下 VM1～VM6分別被預(yù)分配 1個vCPU；Queue-1場景下，VM1～VM6分別被預(yù)分配2個vCPU，因此，平均等待隊列長度為1。本文在VM1上用Iperf工具生成TCP和UDP業(yè)務(wù)流，同時在VM1～VM6上用Sysbench工具生成100%計算負(fù)載；然后，通過實驗觀察發(fā)送和接收方向上I/O請求項隊列長度與TCP、UDP業(yè)務(wù)流吞吐量變化關(guān)系及對應(yīng)I/O共享環(huán)溢出情況。實驗結(jié)果如圖3～圖8所示。

圖3 TCP吞吐量與請求項隊列長度變化關(guān)系（接收方向）

數(shù)據(jù)分組接收方向上，圖 3和圖 4分別對應(yīng)Queue-0與Queue-1這2種場景下，虛擬機TCP、UDP業(yè)務(wù)流吞吐量與 VM 請求項隊列長度的變化關(guān)系。從圖3(a)中可以看出，在Queue-0場景下，TCP業(yè)務(wù)吞吐量穩(wěn)定在190 Mbit/s。請求項隊列平均長度在35～55范圍內(nèi)小幅度平穩(wěn)變化；相應(yīng)地，如圖3(b)所示，在 Queue-1場景下，TCP業(yè)務(wù)平均吞吐量降幅達(dá)70.8%，達(dá)到55.5 Mbit/s，且波動變化劇烈。請求隊列項平均長度約為 150，其值同樣呈現(xiàn)大幅振蕩情況。

圖4分別對應(yīng)Queue-0和Queue-1這2種場景下，UDP業(yè)務(wù)流吞吐量和請求項隊列平均長度之間的對應(yīng)變化關(guān)系。2種場景下，吞吐量的變化趨勢與TCP類似，對應(yīng)Queue-0場景為194 Mbit/s，對應(yīng)Queue-1場景為68 Mbit/s；然而，請求項隊列平均長度分別為48和29，呈現(xiàn)出和TCP不同的情況，這是因為在Queue-1場景下發(fā)生了更多的I/O共享環(huán)擁塞，部分請求項累計在I/O環(huán)中等待處理。

圖4 UDP吞吐量與請求項隊列長度變化關(guān)系（接收方向）

圖5分別對應(yīng)數(shù)據(jù)分組接收方向上，TCP和UDP業(yè)務(wù)對應(yīng)Queue-0和Queue-1這2種場景下I/O環(huán)的溢出情況（1表示溢出，0表示不溢出），從圖5可看出，Queue-1場景下I/O環(huán)產(chǎn)生了多次溢出情況，且對于 UDP而言，其產(chǎn)生溢出的頻率高于TCP業(yè)務(wù)，幾乎接近于100%。

通過對上述實驗結(jié)果分析可知，在數(shù)據(jù)分組接收方向上，VM請求項不能得到及時處理，因而長期維持在一定數(shù)量規(guī)模，其值在消耗殆盡與突然大量補充 2種狀態(tài)之間頻繁交替切換，進(jìn)而造成了VM網(wǎng)絡(luò)性能的下降。

圖5 I/O共享環(huán)溢出情況（接收方向）

數(shù)據(jù)分組發(fā)送方向上，圖 6和圖 7分別對應(yīng)Queue-0與Queue-1這2種場景下，虛擬機TCP、UDP業(yè)務(wù)流吞吐量與請求項隊列長度的關(guān)系。從圖6(a)可以看出，在Queue-0場景下，TCP業(yè)務(wù)流吞吐量穩(wěn)定在190 Mbit/s左右，且對應(yīng)請求項隊列長度平均值穩(wěn)定在5左右，這說明由于該場景下VM的計算資源較為充足，發(fā)送請求項能得到及時處理；對應(yīng)Queue-1場景，如圖6(b)所示，請求項隊列長度間斷重復(fù)出現(xiàn)長度為0的情況，統(tǒng)計不為0情況的次數(shù)為20，其不為0的有效平均長度為50.7。同時，TCP平均吞吐量為87.6 Mbit/s，降幅達(dá)53.9%。

圖7分別對應(yīng)Queue-0和Queue-1這2種場景下，UDP業(yè)務(wù)吞吐量和請求項隊列平均長度之間對應(yīng)變化關(guān)系。類似于TCP情況，從圖7(a)中可看出，在Queue-0場景下，UDP業(yè)務(wù)流吞吐量穩(wěn)定在194 Mbit/s左右，且對應(yīng)請求項隊列長度平均值同樣穩(wěn)定在5左右；相應(yīng)地，Queue-1場景的情況如圖7(b)所示，請求項隊列長度間斷重復(fù)出現(xiàn)長度為0情況，統(tǒng)計不為0情況的次數(shù)為18，其不為0的有效平均長度為53.7。同時，對應(yīng)UDP吞吐量為77.6 Mbit/s，降幅達(dá)60%。

圖6 TCP吞吐量與請求項隊列長度變化關(guān)系（發(fā)送方向）

圖8分別對應(yīng)發(fā)送方向上，TCP和UDP業(yè)務(wù)在Queue-0和Queue-1這2種場景下I/O環(huán)溢出情況（1表示溢出，0表示不溢出），從圖8可以看出，在發(fā)送方向上，由于VM受到vCPU排隊影響無法及時處理發(fā)送數(shù)據(jù)分組的請求，因此，基本上不會造成I/O共享環(huán)的溢出情況。

通過對上述實驗結(jié)果分析可知，在數(shù)據(jù)分組發(fā)送方向上，VM前端驅(qū)動發(fā)送數(shù)據(jù)分組的任務(wù)受到vCPU排隊影響而發(fā)生間斷性阻塞，造成無法及時處理相關(guān)發(fā)送數(shù)據(jù)分組的請求，因而請求隊列項出現(xiàn)了間斷性重復(fù)為0的情況，因此，造成了網(wǎng)絡(luò)性能的下降。

圖7 UDP吞吐量與請求項隊列長度變化關(guān)系（發(fā)送方向）

綜合上述接收和發(fā)送方向的分析可知，Xen默認(rèn)的vCPU調(diào)度機制產(chǎn)生的排隊等待導(dǎo)致了vCPU交替處于活躍與非活躍狀態(tài)，從而對虛擬網(wǎng)絡(luò)設(shè)備前后端驅(qū)動之間的數(shù)據(jù)交互過程產(chǎn)生干擾。該干擾使虛擬機無法及時從Domain 0接收數(shù)據(jù)和發(fā)送數(shù)據(jù)。通過多次實驗可以定量分析出網(wǎng)絡(luò)性能受限和VM請求項隊列長度變化之間的關(guān)系，進(jìn)而提出VM類型識別方法。

4 基于I/O傳輸特征的VM類型識別

4.1 VM類型及通信狀態(tài)定義

根據(jù)虛擬機的I/O傳輸特征，本文將VM分為2種類型：NSVM和NNVM。其中，NSVM指的是執(zhí)行網(wǎng)絡(luò)通信任務(wù)密集且網(wǎng)絡(luò)性能容易受到 vCPU調(diào)度排隊影響的虛擬機，此類虛擬機大多承載了較密集的通信任務(wù)；而 NNVM 主要承載的是計算密集型任務(wù)，且受到vCPU排隊調(diào)度的影響較輕。為了更好地識別虛擬機類型，定義如下通信狀態(tài)。

圖8 I/O共享環(huán)溢出情況（發(fā)送方向）

1)溢出狀態(tài)（overflow state）：VM當(dāng)前I/O環(huán)請求項、響應(yīng)項隊列長度加上本次待放入的請求項數(shù)量后大于等于最大值 QLmax，且頻率非常頻繁，QLmax值為256。

2)過載狀態(tài)（overload state）：VM當(dāng)前I/O環(huán)未處于溢出狀態(tài)，但是經(jīng)常大于一定閾值QLth，且頻率非常頻繁。其中，QLth為I/O請求項隊列長度過載閾值，本文默認(rèn)為150，可根據(jù)實際情況調(diào)整。

3)正常狀態(tài)（normal state）：VM的I/O請求項隊列長度介于0和QLth之間，通信未受到明顯影響。

4)停滯狀態(tài)（stagnate state）：VM的I/O請求項隊列長度在測量周期內(nèi)交替頻繁重復(fù)出現(xiàn)零和非零值情況，多數(shù)對應(yīng)VM發(fā)送數(shù)據(jù)的場景。

4.2 VM類型識別

VM類型識別通過監(jiān)測VM的I/O請求隊列項長度變化和統(tǒng)計分析VM的通信狀態(tài)來完成，假設(shè)當(dāng)前物理宿主機S中存在N個VM，用Vi(i=1,2,…,N)表示。其中，NSVM類型的VM個數(shù)記作Nns；NNVM類型的VM個數(shù)記作Nnn。M表示S上物理CPU核總數(shù)（不包括預(yù)分配給Domain 0的CPU數(shù)量）。初始狀態(tài)下，每個Vi預(yù)分配的vCPU數(shù)量為ui，且隨機、平均地在不同物理 CPU上排隊等待調(diào)度。根據(jù) Xen默認(rèn)的計算資源分配原則，VM 占用 CPU資源的分配比例權(quán)重Wi計算如下

令Ci表示每個VM初始化分得物理CPU數(shù)量，即每個VM理論上可平均占用的CPU數(shù)量，則有

令采樣周期為Tm，識別周期為Ts，則在一個識別周期內(nèi)采樣次數(shù)Ns計算如下

4.2.1 數(shù)據(jù)分組接收方向識別

在數(shù)據(jù)分組接收方向，Domain 0接收從網(wǎng)卡發(fā)送的數(shù)據(jù)并通過I/O機制轉(zhuǎn)發(fā)給VM，若VM由于vCPU調(diào)度排隊而導(dǎo)致不能及時接收數(shù)據(jù)分組，會使其持續(xù)處于溢出和過載狀態(tài)。本文定義為第j次采樣時 VM 請求項隊列長度，為響應(yīng)項隊列長度，為待放入請求項個數(shù)；和分別表征采樣周期內(nèi)VM是否處于溢出和過載狀態(tài)，則有

4.2.2 數(shù)據(jù)分組發(fā)送方向識別

在數(shù)據(jù)分組發(fā)送方向，VM通過Domain 0發(fā)送數(shù)據(jù)分組，若VM由于vCPU調(diào)度排隊而導(dǎo)致不能及時發(fā)送數(shù)據(jù)，會使 VM 頻繁處于通信停滯狀態(tài)。定義為發(fā)送方向上第j次采樣時請求項隊列長度，表征采樣周期內(nèi)請求隊列項長度是否為0，ne為識別周期內(nèi)隊列長度不為零的次數(shù)，當(dāng)監(jiān)測到隊列長度不為零時，ne自動累加。為I/O請求項隊列平均長度，為發(fā)送方向I/O請求停滯頻率，即

4.2.3 接收和發(fā)送方向聯(lián)合識別

由于 VM 在執(zhí)行通信過程中數(shù)據(jù)分組的收發(fā)是同時進(jìn)行的，因此，只要接收和發(fā)送的某一個方向判定為NSVM型，即可以判定該VM為NSVM型，反之為NNVM型。完成識別后，2種類型的VM分別記入集合Vns和Vnn，整體識別流程如圖9所示。

5 Diff-Scheduler機制

基于VM類型識別結(jié)果，本節(jié)提出一種面向網(wǎng)絡(luò)性能優(yōu)化的新型虛擬計算資源分配及調(diào)度機制Diff-Scheduler，該機制基于2種類型VM的資源需求，將物理計算資源進(jìn)行重新分配，進(jìn)一步提高NSVM的默認(rèn)調(diào)度頻率，最終提升其網(wǎng)絡(luò)性能，同時保證了計算資源分配的公平性。

圖9 VM類型聯(lián)合識別流程

5.1 VM計算資源使用情況分析

利用Xen提供的接口實時測量各個VM實際所占用的 CPU負(fù)載，通常以 VM 所占單個物理CPU的倍數(shù)來表示，記作 Li，i為 VM 編號（i=1,…,N）。每個VM分別比較Li和Ci的大小關(guān)系，判斷當(dāng)前計算資源是否滿足其需求。當(dāng)Li≤Ci時，說明該VM沒有消耗完分配給它的CPU計算資源，處于“計算資源非饑餓”狀態(tài)；反之，若Li＞Ci時，則說明當(dāng)前時刻該VM處于“計算資源饑餓”狀態(tài)。

經(jīng)過上述分析，可將對應(yīng)NSVM類型的VM分為2種子類型，即NSVM中的“計算資源饑餓”子型NSVM_h和“計算資源非饑餓”子型NSVM_nh，其個數(shù)分別為 Nnsh和 Nnsnh；相應(yīng)地，NNVM 類型的VM也可進(jìn)一步劃分為2種子類型，即NNVM中的“計算資源饑餓”子型NNVM_h和NNVM_nh“計算資源非饑餓”子型NNVM_nh，其個數(shù)分別為Nnnh和Nnnnh，顯然有

5.2 CPU資源計算與重新分配

本節(jié)分別計算“計算資源非饑餓”型與“計算資源饑餓”2種類型VM所需的CPU資源數(shù)量。首先，利用第5.1節(jié)中的統(tǒng)計分析結(jié)果來計算“計算資源非饑餓”狀態(tài)VM所占的CPU數(shù)量Cnh以及NSVM_nh子型和NNVM_nh子型分別所占的CPU數(shù)量Cnsnh和Cnnnh

其中，Lk為每個NSVM_nh型VM對應(yīng)占用的實際物理CPU數(shù)量，Lr為每個NNVM_nh型VM對應(yīng)占用的實際物理CPU數(shù)量。則余下物理CPU數(shù)量即為“計算資源饑餓”型VM應(yīng)分得的CPU數(shù)量Ch

其中，Nh=Nnsh+Nnnh為當(dāng)前統(tǒng)計周期內(nèi)所有“計算資源饑餓”型VM數(shù)量。最后計算出NSVM_h和NSVM_nh型VM應(yīng)分得的物理CPU數(shù)量Nnsh和Nnnh

5.3 計算資源分池優(yōu)化調(diào)度

利用Xen提供的工具接口，將物理宿主機服務(wù)器上的所有CPU資源劃分為2個分池，分別對應(yīng)NSVM資源分池和NNVM資源分池。初始狀態(tài)下，NSVM資源分池中的物理CPU數(shù)置為零，全部CPU資源默認(rèn)在NNVM資源池中。

利用第5.2中的計算結(jié)果，向NSVM資源分池中分配Cns個物理CPU，并將NSVM對應(yīng)的vCPU分配到該資源分池進(jìn)行調(diào)度，其中，為所有NSVM需要的CPU值，并向下取整。同時，向NNVM分池中分配Cnn個物理CPU，將NNVM對應(yīng)的 vCPU分配到該池進(jìn)行調(diào)度，其中為所有NNVM需要的CPU值，并向下取整。計算資源分池調(diào)度示例如圖10所示。

NSVM資源分池和 NNVM資源分池中的調(diào)度算法仍然采用Xen默認(rèn)的Credit Scheduler，但2個分池的CPU時間片調(diào)度周期（slice time）需要進(jìn)行重新設(shè)定。其中，NSVM資源分池調(diào)整為5 ms（本文默認(rèn)調(diào)整值），NNVM 資源分池仍然保持默認(rèn)值30 ms。實際情況下，NSVM資源分池的 CPU時間片調(diào)度周期可以根據(jù)用戶應(yīng)用的密集程度動態(tài)調(diào)整。

需要補充說明的是，由于實際情況下計算出來的Cns和Cnn很可能不是整數(shù)，其小數(shù)部分之和約為1。為了有效利用資源，本文采用隨機概率的方式進(jìn)行余下1個CPU的分配。

1)假設(shè)Cns取整之前的小數(shù)部分為δ（保留一位小數(shù)），Cnn取整之前的小數(shù)部分為η，分別計算此時屬于Cns和Cnn的余數(shù)分配百分比λns和即

2)設(shè)定一個隨機數(shù)程序，其中，隨機數(shù)數(shù)目為10δ+10η，每次進(jìn)行一次隨機數(shù)的生成，以概率λns將余下的1個物理CPU分配給NSVM資源分池，以概率λnn將余下的 1個物理 CPU分配給 NNVM資源分池。

6 原型系統(tǒng)設(shè)計

Xen的I/O通信系統(tǒng)由位于Domain 0域的后端驅(qū)動、位于VM側(cè)的前端驅(qū)動以及共享內(nèi)存機制共同協(xié)作完成。為了更好地實現(xiàn)VM類型識別和區(qū)分式的分池調(diào)度策略，本文在原有Xen平臺的基礎(chǔ)上擴展實現(xiàn)了部分功能模塊，設(shè)計實現(xiàn)了基于I/O傳輸特征感知的虛擬計算資源分配與優(yōu)化調(diào)度原型系統(tǒng)，架構(gòu)如圖 11所示。為了不影響原有功能的運行，系統(tǒng)設(shè)計遵循如下原則：1)除信息監(jiān)測模塊以外，所有模塊均部署和工作于Domain 0特權(quán)域，各個虛擬機系統(tǒng)不需要做任何改變，增加了系統(tǒng)的可移植性和部署的靈活性；2)各個子模塊功能均為輕量級，信息統(tǒng)計分析及策略生成操作由Python語言編寫，運行成本開銷較小，不會給Domain 0域增加額外大的負(fù)擔(dān)。

6.1 I/O隊列信息監(jiān)測模塊

圖10 計算資源分池調(diào)度示例

該模塊工作于Xen內(nèi)核空間中，通過模塊插入和退出的方式可進(jìn)行靈活部署，可以周期性地實時監(jiān)測后端驅(qū)動的 I/O傳輸隊列信息和虛擬機當(dāng)前CPU負(fù)載情況，包括請求項隊列長度、響應(yīng)項隊列長度及實際占用物理CPU數(shù)量等。信息統(tǒng)計默認(rèn)周期為10毫秒/次。獲取信息有2個途徑：一是通過 I/O傳輸共享數(shù)據(jù)內(nèi)存緩存區(qū)提供的接口，獲取 Xen的前后端分離驅(qū)動的 netback和netfront之間共享環(huán)形緩沖區(qū)存放的信息；二是通過Xen中Libxenstat庫提供的接口來獲取每個虛擬機當(dāng)前的CPU使用信息，隨后將信息傳遞給信息統(tǒng)計分析模塊。

圖11 原型系統(tǒng)架構(gòu)設(shè)計

6.2 信息統(tǒng)計分析模塊

接收來自I/O隊列信息監(jiān)測模塊中的信息，分別提取每個虛擬機對應(yīng)的發(fā)送、接收I/O共享環(huán)中的各類隊列長度等參數(shù)信息，并做線性平滑處理，將處理結(jié)果發(fā)送至策略生成模塊。

6.3 策略生成模塊

根據(jù)信息統(tǒng)計分析模塊傳遞的處理結(jié)果，進(jìn)行虛擬機類型識別操作。本文所提的相關(guān)VM類型識別和計算資源分配核心策略部署于該模塊中。主要過程是將當(dāng)前虛擬機分為NSVM型和NNVM型，同時分別計算2種類型的VM應(yīng)分配的CPU數(shù)量，將上述內(nèi)容匯總為 CPU分池調(diào)度策略，并將策略信息傳遞給調(diào)度執(zhí)行模塊。

6.4 調(diào)度執(zhí)行模塊

基于 Xen提供的 XL管理接口，周期性執(zhí)行CPU分池比例的調(diào)整和調(diào)度頻率調(diào)整。

7 實驗與結(jié)果分析

為了驗證本文所提面向網(wǎng)絡(luò)性能優(yōu)化的虛擬計算資源分配及調(diào)度機制的準(zhǔn)確性和有效性，本文與Xen默認(rèn)的Credit Scheduler調(diào)度機制進(jìn)行了性能對比實驗，比較VM網(wǎng)絡(luò)業(yè)務(wù)吞吐量、延遲變化情況，此外還包括應(yīng)用Diff-Scheduler機制對CPU資源分配公平性影響的驗證。

7.1 實驗環(huán)境

實驗環(huán)境采用與3.3節(jié)相同的拓?fù)渑c配置，所不同的是本文利用Linux限流工具添加30ms延遲以及160 Mbit/s的最大網(wǎng)絡(luò)吞吐量限制，用以模擬真實的小規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境。

虛擬機類型識別參數(shù)設(shè)置如下：接收方向上，I/O環(huán)請求隊列溢出頻率閾值δth設(shè)定為0.2，I/O環(huán)請求隊列項長度過載閾值為150，過載頻率判別閾值為 0.6；發(fā)送方向上，I/O環(huán)請求隊列長度閾值為45，停滯頻率判別閾值γth為0.5。

7.2 結(jié)果分析

為了更好地驗證本文機制的有效性，實驗在下列2種場景下對TCP、UDP吞吐量、平均延遲以及CPU資源公平性等性能指標(biāo)進(jìn)行比較。

1)vCPU平均隊列長度為1的場景，即 Queue-1場景（參考第 3.3節(jié)），此時為每個 VM 預(yù)分配 2個vCPU。

2)vCPU平均隊列長度為2的場景，簡稱Queue-2場景，此時為每個VM預(yù)分配3個vCPU。

7.2.1 TCP吞吐量

如圖12所示，在Queue-1場景下，使用Xen默認(rèn)的vCPU調(diào)度機制Credit Scheduler時，TCP業(yè)務(wù)流平均吞吐量僅為 54 Mbit/s。當(dāng)采用Diff-Scheduler機制后，TCP業(yè)務(wù)流平均吞吐量達(dá)到了96 Mbit/s，提升約77.8%；在Queue-2場景下，采用Credit Scheduler機制，TCP吞吐量持續(xù)降低，僅為37 Mbit/s，因為vCPU排隊的時延增加，更多的虛擬機參與 CPU資源競爭，使性能受到的影響加大。采用Diff-Scheduler后，吞吐量達(dá)到74 Mbit/s，性能提升100%。

7.2.2 UDP吞吐量

如圖 13所示，在 Queue-1場景下，分別采用Credit Scheduler和Diff-Scheduler后，UDP平均吞吐量分別為66 Mbit/s和118 Mbit/s，提升將近78.8%；相應(yīng)地，在Queue-2場景下，UDP吞吐量分別為45 Mbit/s和95 Mbit/s，提升111.1%。相比TCP，Diff-Scheduler對UDP業(yè)務(wù)網(wǎng)絡(luò)性能提升更明顯。

7.2.3 平均延遲

圖12 TCP吞吐量變化情況對比

圖13 UDP吞吐量變化情況對比

本文利用ICMP RTT來測量待測VM和測試對端T之間的平均延遲。利用PING工具產(chǎn)生ICMP請求及響應(yīng)，發(fā)送速率為10次/秒，載荷為100 byte。圖14分別對應(yīng) Queue-1和Queue-2這2種場景下的平均延遲概率累計分布函數(shù)圖（CDF圖）。在Queue-1場景下，相比Credit Scheduler，本文所提Diff-Scheduler機制將平均延遲從71 ms減少至32 ms，下降近55%；在Queue-2場景下，平均延遲由96 ms減少至37 ms，下降近61%；上述結(jié)果表明，應(yīng)用本文所提機制能夠有效、持續(xù)地降低網(wǎng)絡(luò)平均延遲。

7.2.4 計算資源分配公平性

通過原型系統(tǒng)實驗已驗證 Diff-Scheduler機制能夠有效提升虛擬機的網(wǎng)絡(luò)性能，本節(jié)驗證該機制計算資源分配的公平性。眾所周知，Credit Scheduler機制進(jìn)行計算資源分配具有良好的公平性。因此，本文以Credit Scheduler機制作為基準(zhǔn)標(biāo)準(zhǔn)，利用2種機制下，NSVM和NNVM這2種類型虛擬機所分得的CPU數(shù)量比值來評價公平性。

令CNS和CNN作為 Credit Scheduler機制下，NSVM和NNVM這2種類型虛擬機所分得的CPU數(shù)量；Cns和Cnn作為Diff-Scheduler機制下，NSVM和NNVM這2種類型虛擬機所分得的CPU數(shù)量，和FRnn分別為對應(yīng)2種類型虛擬機的資源公平性比率

圖14 網(wǎng)絡(luò)平均延遲變化情況對比

圖15 計算資源分配公平性驗證結(jié)果

式(21)中的比率值越接近1，表明Diff-Scheduler具有更準(zhǔn)確的資源分配公平性。實驗結(jié)果如圖 15所示，在Queue-1場景下，對應(yīng)TCP和UDP業(yè)務(wù)，NSVM類型的計算資源公平性比率分別為1.023和1.034；相應(yīng)地，在Queue-2場景下，對應(yīng)TCP和UDP業(yè)務(wù)流，NSVM類型的計算資源公平性比率分別為1.015和1.008。對NNVM類型而言，其計算資源公平性比率在2種情況下同樣非常接近于1。說明Diff-Scheduler機制充分保證了CPU資源分配的公平性。此外，相比NSVM類型，NNVM類型的公平性比率值略低于 1，這是因為計算資源重新分配與分池調(diào)度時，分配剩余CPU時產(chǎn)生了細(xì)微的隨機誤差，也是本文所提機制在提升網(wǎng)絡(luò)性能與資源分配之間的細(xì)微權(quán)衡。在實際系統(tǒng)運行中，這種細(xì)微權(quán)衡將不會對計算和網(wǎng)絡(luò)通信任務(wù)帶來影響。

8 結(jié)束語

云計算為用戶提供了一種基于互聯(lián)網(wǎng)的新型計算模式。作為搭建云計算平臺的基礎(chǔ)，虛擬化技術(shù)通過將計算機的各種實體資源抽象以便實現(xiàn)資源共享。然而，上述計算資源共享的方式也給虛擬機網(wǎng)絡(luò)性能帶來了較大的負(fù)面影響。本文以主流開源虛擬化技術(shù) Xen為研究對象，針對其默認(rèn)的vCPU調(diào)度策略造成虛擬機網(wǎng)絡(luò)性能下降的問題進(jìn)行深入研究。提出了一種新型的面向網(wǎng)絡(luò)性能優(yōu)化的計算資源分配及調(diào)度機制。通過實驗表明，該機制可有效提高虛擬機網(wǎng)絡(luò)的吞吐量，顯著降低延遲，同時保證計算資源分配的公平性。

未來的研究工作將基于大規(guī)模數(shù)據(jù)中心內(nèi)部資源池環(huán)境進(jìn)行。包括：1)數(shù)據(jù)中心內(nèi)部多服務(wù)器之間的VM資源調(diào)度，可根據(jù)當(dāng)前VM的CPU負(fù)載競爭情況與通信情況將計算資源進(jìn)行重新調(diào)配，將通信流量集中的 NSVM 型虛擬機遷移至低負(fù)載宿主機服務(wù)器；2)基于應(yīng)用類型的優(yōu)化調(diào)度方式，數(shù)據(jù)中心內(nèi)部有大量不同類型的任務(wù)，下一步工作可根據(jù)不同類型任務(wù)的 QoS要求進(jìn)行有針對性的資源調(diào)度和隔離，為用戶提供高效的區(qū)分式服務(wù)。

[1]Amazon elastic compute cloud[EB/OL]. http://aws.amazon.com/ec2/.

[2]Google cloud platform[EB/OL]. http://cloud.google.com.

[3]Microsoft server and cloud platform[EB/OL]. http://www.microsoft.com/servercloud/.

[4]Aliyun.com[EB/OL]. http://appcloud.aliyun.com.

[5]Wo cloud[EB/OL]. http://www.wocloud.cn.

[6]Ecloud[EB/OL]. http://ecloud.10086.cn/.

[7]E Cloud[EB/OL]. http://www.ctyun.cn/.

[8]The XEN project[EB/OL]. http://www.xenproject.org/.

[9]OSTERMANN S,IOSUP A,YIGITBASI N,et al. A performance analysis of EC2 cloud computing services for scientific computing[C]//International Conference on Cloud Computing. c2010:115-131.

[10]WHITEAKER J,SCHNEIDER F,TEIXEIRA R. Explaining packet delays under virtualization[J].ACM Sigcomm Computer Communication Review,2011,41(1):38-44.

[11]WANG G,NG T. The impact of virtualization on network performance of amazon EC2 data center[C]//The 29th IEEE International Conference on Computer Communications. c2010:1-9.

[12]SHEA R,WANG F,WANG H,et al. A deep investigation into network performance in virtual machine based cloud environments[C]//The 33th IEEE International Conference on Computer Communications.c2014: 1285-1293.

[13]GAMAGE S,KANGARLOU A,KOMPELLA R R,et al. Opportunistic flooding to improve TCP transmit performance in virtualized clouds[C]//The 2nd ACM Symposium on Cloud Computing. c2011: 24.

[14]KANGARLOU A,GAMAGE S,KOMPELLA R R,et al. vSnoop:improving TCP throughput in virtualized environments via acknowledgement offload[C]//The 2010 ACM/IEEE International Conference for High Performance Computing,Networking,Storage and Analysis.c2010: 1-11.

[15]XU C,GAMAGE S,RAO P N,et al. vSlicer: latency-aware virtual machine scheduling via differentiated-frequency CPU slicing[C]// The 21st International Symposium on High-Performance Parallel and Distributed Computing. c2012: 3-14.

[16]XU Y,MUSGRAVE Z,NOBLE B,et al. Bobtail: avoiding long tails in the cloud[C]//The USENIX Conference on Network Systems Design and Implementation. c2013: 329-341.

[17]XU Y. Characterizing and mitigating virtual machine interference in public clouds[D]. Michigan: University of Michigan,2014.

[18]XU Y,BAILEY M,NOBLE B,et al. Small is better: avoiding latency traps in virtualized data centers[C]//The 4th Annual Symposium on Cloud Computing. c2013.

[19]Credit2 scheduler[EB/OL]. http://wiki.xen.org/wiki/Credit2_Scheduler_Development#Status.

[20]Iperf[EB/OL]. http://iperf.sourceforge.net/.

[21]Sysbench[EB/OL]. http://sysbench.sourceforge.net/.

Study on virtual computing resource scheduling for network performance optimization

WANG Yu-wei1,2,LIU Min1,FANG Bing-yi3,QIN Chen-chong1,2,YAN Xiao-long1,2

(1. Institute of Computing Technology,Chinese Academy of Sciences,Beijing 100190,China;2. University of Chinese Academy of Sciences,Beijing 100049,China; 3. China Unicom,Beijing 100032,China)

A deep insight into the relationship between vCPU scheduling and I/O transmit in Xen was provided. Then an effective and lightweight recognition method,through which could identify the so-called NSVM (network queuing sensitive virtual machine)that was more vulnerable to the congestion in I/O transmit was put forward. Furthermore,a novel mechanism for resource assignment and scheduling called Diff-Scheduler was proposed. It could schedule the vCPU of the NSVM more frequently than other VM in different pools independently. Evaluations based on a prototype of Xen platform featured Diff-Scheduler show that the proposed mechanism significantly improves the network performance of VM. Specifically,comparing with the default mechanism of Xen,Diff-Scheduler proposed jointly enhances throughput,latency remarkably and ensures the fairness of resource allocation at the same time.

cloud computing,virtualization,vCPU scheduling,network queuing sensitive,virtual computing resource assignment

The National Natural Science Foundation of China (No.61132001,No.61120106008,No.61472402,No.61472404,No.61272474,No.61202410)

TP302

A

2016-01-25；

2016-06-23

國家自然科學(xué)重點基金資助項目（No.61132001,No.61120106008,No.61472402,No.61472404,No.61272474,No.61202410）

10.11959/j.issn.1000-436x.2016161

王煜煒（1980-），男，河北唐山人，中國科學(xué)院博士生、助理研究員，主要研究方向為未來網(wǎng)絡(luò)、虛擬化技術(shù)和云計算。

劉敏（1976-），女，河南鄭州人，博士，中國科學(xué)院研究員、博士生導(dǎo)師，主要研究方向為移動管理、網(wǎng)絡(luò)測量和移動計算。

房秉毅（1980-），男，山東泰安人，博士，中國聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司高級工程師，主要研究方向為下一代網(wǎng)絡(luò)、移動核心網(wǎng)和云計算。

秦晨翀（1991-），男，山西臨汾人，中國科學(xué)院碩士生，主要研究方向為虛擬化技術(shù)、下一代網(wǎng)絡(luò)、移動計算。

閆小龍（1990-），男，安徽阜陽人，中國科學(xué)院碩士生，主要研究方向為虛擬化技術(shù)、下一代網(wǎng)絡(luò)、移動計算。