面向網絡性能優化的虛擬計算資源調度機制研究

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

（1. 中國科學院計算技術研究所，北京 100190；2. 中國科學院大學，北京 100049；3. 中國聯合網絡通信集團有限公司，北京 100032）

面向網絡性能優化的虛擬計算資源調度機制研究

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

（1. 中國科學院計算技術研究所，北京 100190；2. 中國科學院大學，北京 100049；3. 中國聯合網絡通信集團有限公司，北京 100032）

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

云計算；虛擬化；vCPU調度；網絡排隊敏感型；虛擬計算資源分配

1 引言

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

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

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

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

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

本文圍繞面向網絡性能優化的虛擬資源調度機制展開研究，基于上述核心問題及挑戰提出了有針對性的解決方案，主要創新貢獻如下。

1)通過實驗驗證對 vCPU機制影響虛擬機網絡傳輸過程進行了詳細分析，進一步明確I/O共享環中的請求項隊列長度變化是表征數據傳輸阻塞程度的重要指標。

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

3)提出了一種面向網絡性能優化的新型虛擬計算資源分配及調度機制Diff-Scheduler，該機制優化并改進了Xen原有的vCPU調度機制，將NSVM與NNVM類型虛擬機的vCPU分池隔離與區分調度。

4)基于Xen 4.4研發了原型系統并進行性能對比實驗。實驗結果表明，相關機制能夠大幅提高虛擬機網絡性能，并保證計算資源分配的公平性。

2 相關工作

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

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

3 vCPU調度對I/O通信影響分析

本文從分析 vCPU調度機制對 Xen中虛擬機I/O通信機制的影響入手，基于I/O傳輸特征對VM類型進行合理、準確識別，提出一種面向網絡性能優化的虛擬計算資源分配及調度機制Diff-Scheduler，可大幅度提升虛擬機的網絡性能。

3.1 基于Xen的vCPU調度機制

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

3.2 基于I/O共享環的網絡數據傳輸

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

圖1 基于Xen的虛擬網絡I/O通信架構

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

3.3 vCPU調度對數據傳輸影響分析

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

為獲取相關信息，本文對Xen虛擬網絡設備后端驅動進行修改，在用戶空間獲取 I/O共享環中的請求項隊列長度值。該值是個不大于256的非負數。當共享 I/O環“溢出”時，測得的請求隊列長度已不能準確代表其真實長度，本文將其校準為最大值 256。這里的溢出并不是真正意義上的內存堆棧溢出，而是對應請求項、響應項隊列長度加上本次待放入的請求項數量后大于等于最大值256的情況。此時表明I/O共享環發生了比較嚴重的擁塞，實際情況并不會出現真正的堆棧溢出，Xen系統設計了自適應調節機制，采取相關退避或等待策略。

實驗環境如下：網絡拓撲環境由2臺服務器及連接它們之間的路由設備組成，如圖2所示。其中宿主機服務器S上部署Xen 4.4系統及本文所提的相關vCPU優化調度功能模塊；另一臺服務器T作為測試對端，每臺服務器均配有8核物理 CPU、32 GB內存和 2塊千兆局域網網卡。Domain 0特權域和測試用虛擬機內運行的操作系統均為 Ubuntu14.04，內核版本分別為 Linux 3.13.11和Linux 3.13.0。

圖2 實驗網絡拓撲環境

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

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

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

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

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

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

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

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

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

圖5 I/O共享環溢出情況（接收方向）

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

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

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

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

通過對上述實驗結果分析可知，在數據分組發送方向上，VM前端驅動發送數據分組的任務受到vCPU排隊影響而發生間斷性阻塞，造成無法及時處理相關發送數據分組的請求，因而請求隊列項出現了間斷性重復為0的情況，因此，造成了網絡性能的下降。

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

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

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

4.1 VM類型及通信狀態定義

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

圖8 I/O共享環溢出情況（發送方向）

1)溢出狀態（overflow state）：VM當前I/O環請求項、響應項隊列長度加上本次待放入的請求項數量后大于等于最大值 QLmax，且頻率非常頻繁，QLmax值為256。

2)過載狀態（overload state）：VM當前I/O環未處于溢出狀態，但是經常大于一定閾值QLth，且頻率非常頻繁。其中，QLth為I/O請求項隊列長度過載閾值，本文默認為150，可根據實際情況調整。

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

4)停滯狀態（stagnate state）：VM的I/O請求項隊列長度在測量周期內交替頻繁重復出現零和非零值情況，多數對應VM發送數據的場景。

4.2 VM類型識別

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

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

令采樣周期為Tm，識別周期為Ts，則在一個識別周期內采樣次數Ns計算如下

4.2.1 數據分組接收方向識別

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

4.2.2 數據分組發送方向識別

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

4.2.3 接收和發送方向聯合識別

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

5 Diff-Scheduler機制

基于VM類型識別結果，本節提出一種面向網絡性能優化的新型虛擬計算資源分配及調度機制Diff-Scheduler，該機制基于2種類型VM的資源需求，將物理計算資源進行重新分配，進一步提高NSVM的默認調度頻率，最終提升其網絡性能，同時保證了計算資源分配的公平性。

圖9 VM類型聯合識別流程

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

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

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

5.2 CPU資源計算與重新分配

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

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

其中，Nh=Nnsh+Nnnh為當前統計周期內所有“計算資源饑餓”型VM數量。最后計算出NSVM_h和NSVM_nh型VM應分得的物理CPU數量Nnsh和Nnnh

5.3 計算資源分池優化調度

利用Xen提供的工具接口，將物理宿主機服務器上的所有CPU資源劃分為2個分池，分別對應NSVM資源分池和NNVM資源分池。初始狀態下，NSVM資源分池中的物理CPU數置為零，全部CPU資源默認在NNVM資源池中。

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

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

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

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

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

6 原型系統設計

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

6.1 I/O隊列信息監測模塊

圖10 計算資源分池調度示例

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

圖11 原型系統架構設計

6.2 信息統計分析模塊

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

6.3 策略生成模塊

根據信息統計分析模塊傳遞的處理結果，進行虛擬機類型識別操作。本文所提的相關VM類型識別和計算資源分配核心策略部署于該模塊中。主要過程是將當前虛擬機分為NSVM型和NNVM型，同時分別計算2種類型的VM應分配的CPU數量，將上述內容匯總為 CPU分池調度策略，并將策略信息傳遞給調度執行模塊。

6.4 調度執行模塊

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

7 實驗與結果分析

為了驗證本文所提面向網絡性能優化的虛擬計算資源分配及調度機制的準確性和有效性，本文與Xen默認的Credit Scheduler調度機制進行了性能對比實驗，比較VM網絡業務吞吐量、延遲變化情況，此外還包括應用Diff-Scheduler機制對CPU資源分配公平性影響的驗證。

7.1 實驗環境

實驗環境采用與3.3節相同的拓撲與配置，所不同的是本文利用Linux限流工具添加30ms延遲以及160 Mbit/s的最大網絡吞吐量限制，用以模擬真實的小規模數據中心網絡環境。

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

7.2 結果分析

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

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

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

7.2.1 TCP吞吐量

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

7.2.2 UDP吞吐量

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

7.2.3 平均延遲

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

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

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

7.2.4 計算資源分配公平性

通過原型系統實驗已驗證 Diff-Scheduler機制能夠有效提升虛擬機的網絡性能，本節驗證該機制計算資源分配的公平性。眾所周知，Credit Scheduler機制進行計算資源分配具有良好的公平性。因此，本文以Credit Scheduler機制作為基準標準，利用2種機制下，NSVM和NNVM這2種類型虛擬機所分得的CPU數量比值來評價公平性。

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

圖14 網絡平均延遲變化情況對比

圖15 計算資源分配公平性驗證結果

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

8 結束語

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

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

[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

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

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

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

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

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

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

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