基于虛擬化技術的信關站基帶資源池設計與實現(xiàn)

王力權(quán)，翟 華，張志麗，王艷君，解立坤

(1.中國電子科技集團公司第五十四研究所，河北 石家莊 050081；2.北京跟蹤與通信技術研究所,北京 100094)

0 引言

衛(wèi)星移動通信，相對于地面移動通信系統(tǒng)，具有覆蓋范圍廣、通信費用與距離無關以及不受地理條件限制等優(yōu)點，能夠?qū)崿F(xiàn)對海洋、山區(qū)和高原等地區(qū)近乎無縫的覆蓋[1-3]，不僅能夠傳輸電話、電報，而且能夠傳輸高質(zhì)量的電視以及高速數(shù)據(jù)等。衛(wèi)星信關站是連接衛(wèi)星網(wǎng)絡和地面網(wǎng)絡的樞紐，從網(wǎng)絡互通角度，其包含基帶處理單元和交換互聯(lián)單元,主要完成傳輸算法、協(xié)議轉(zhuǎn)換、網(wǎng)絡交換及互聯(lián)互通等功能[4]?；鶐幚韱卧切抨P站中重要組成部分，實現(xiàn)信號的發(fā)送接收、編解碼和協(xié)議處理等功能。

隨著用戶數(shù)量和應用數(shù)據(jù)規(guī)模等需求增長，衛(wèi)星移動通信網(wǎng)絡需要存在多種體制和規(guī)模，不同制式的網(wǎng)絡相互重疊覆蓋，這就導致衛(wèi)星通信網(wǎng)絡整體需要維持的基帶資源總量和能耗巨大[5]。由于業(yè)務流量在地域上分布不均勻，導致了基礎設施在數(shù)量或者時間上的冗余，造成信關站處理資源的閑置和浪費，增大運營和維護成本?；鶐зY源池的建立，可將信關站基帶處理中對實時性要求不高的部分，如分幀復接、MAC處理、RLC處理及PDCP處理等部署在通用服務器上，構(gòu)建統(tǒng)一的資源池，進行聯(lián)合協(xié)作分配和資源管理；同時也實現(xiàn)了軟硬件解耦，提高了不同制式信關站的兼容性和可擴展性[6-7]。虛擬化技術是一種使基帶處理單元能夠靈活低成本支持多?；蚨嘀剖降募夹g，基帶處理單元占用的硬件資源通過虛擬化技術在物理資源池中進行高效的調(diào)度分配，對基帶處理單元軟件本身屏蔽其底層硬件資源的管理細節(jié)[8]。云計算是一種通過網(wǎng)絡對共享資源池(如網(wǎng)絡、服務器、存儲)提供便捷、按需訪問的計算模型，可實現(xiàn)與資源提供者快速交互，并通過較小工作量實現(xiàn)資源的快速釋放和提供[9]。

本文通過虛擬化技術，將信關站基帶處理單元虛擬化，進行資源整合，構(gòu)建資源池?；谠朴嬎闫脚_，實現(xiàn)對虛擬基帶資源池的管控，支持根據(jù)硬件負載情況的動態(tài)遷移功能。

1 虛擬基帶資源池構(gòu)建

基于內(nèi)核的虛擬機(Kernel-based Virtual Machine,KVM)是一款Linux的開源虛擬化軟件。在KVM中，虛擬機被視為常規(guī)的Linux進程，由標準Linux調(diào)度程序進行調(diào)度，虛擬機的每個虛擬CPU(vCPU)被視為一個常規(guī)的Linux進程。本質(zhì)上，KVM是管理虛擬硬件設備的驅(qū)動，該驅(qū)動作為管理接口，負責虛擬處理器的創(chuàng)建、虛擬內(nèi)存的分配、寄存器的讀寫以及虛擬處理器的運行[10-11]。

基于KVM的虛擬化技術的信關站總體架構(gòu)如圖1所示。部分基帶處理以及協(xié)議與交換處理可通過KVM在基于X86架構(gòu)的通用服務器集群上創(chuàng)建虛擬機，屏蔽物理設備的差異性，從而構(gòu)建虛擬基帶資源池。這不僅提高了物理設備資源的使用效率，還降低了衛(wèi)星移動通信系統(tǒng)中信關站的能源開銷，減少其建設費用和運營費用。

圖1 虛擬化信關站總體架構(gòu)Fig.1 Virtual gateway architecture

本文介紹基于KVM技術的信關站虛擬化平臺架構(gòu)和部署方式，并構(gòu)建了測試平臺，通過對虛擬化平臺的負載性能測試和動態(tài)遷移性能測試驗證了該虛擬化平臺的資源和運行管控能力。

2 虛擬管控平臺架構(gòu)設計

2.1 虛擬管控平臺總架構(gòu)

圖2為信關站基帶處理單元虛擬管控平臺的架構(gòu)圖，圖中管控平臺是在基帶處理通用服務器集群上構(gòu)建虛擬層，并通過動態(tài)遷移實現(xiàn)資源管控。虛擬層上可運行多個虛擬機，一個虛擬機可處理一個BBU單元，也可處理L2/L3單元，虛擬機按照不同的粒度進行功能劃分，有利于提高基帶處理資源的利用率，從而提升虛擬化信關站的總體效能。

圖2 信關站虛擬化架構(gòu)圖 Fig.2 Virtualization architecture diagram of gateway station

本文設計的虛擬化基帶資源池通過OpenStack構(gòu)建虛擬資源管控平臺。OpenStack采用分布式架構(gòu)，是一個開源的，旨在實現(xiàn)開放簡單、具有大規(guī)?？蓴U展性及豐富特征集的云計算平臺[12-13]，虛擬管控平臺按照功能的不同分為多個模塊項目，可以根據(jù)實際需求進行項目組合，不同項目功能劃分明確且耦合性低，OpenStack包含以下基本組件：

計算服務(Nova)在OpenStack中負責向用戶按需提供不同規(guī)格的虛擬機。Nova的核心功能是將大量部署了KVM的物理服務器統(tǒng)一納入管理，組成一個具有完整資源視圖的邏輯資源池。在此基礎上，Nova通過接收不同用戶發(fā)起的請求，對資源池中的資源進行生命周期管理操作。

鏡像服務(Glance)負責對系統(tǒng)中提供的各類鏡像的元數(shù)據(jù)進行管理，并提供鏡像的創(chuàng)建、刪除、查詢、上傳及下載等能力。

身份認證服務(Keystone)負責對用戶進行身份認證，并向被認定為合法的用戶發(fā)放令牌。用戶持Keystone發(fā)放的令牌訪問 OpenStack的其他項目，以使用其提供的服務。

網(wǎng)絡管理(Neutron)為用戶提供不同層次的多種網(wǎng)絡服務功能，包括L2組網(wǎng)、L3組網(wǎng)、內(nèi)網(wǎng)DHCP管理、Internet浮動IP管理、內(nèi)外網(wǎng)防火墻、負載均衡及VPN等。

用戶界面(Horizon)提供基于Web自助服務入口連接底層的云計算服務，管理員可以管理云端服務當前的部署與狀態(tài)[14-15]。

2.2 虛擬管控平臺部署

合理的部署架構(gòu)是基帶虛擬資源池穩(wěn)定高效的基礎，針對信關站基帶處理單元多服務器環(huán)境，本文采用多節(jié)點的OpenStack部署架構(gòu)。虛擬管控平臺包含一個控制節(jié)點和兩個計算節(jié)點共3臺服務器。通過控制節(jié)點的Web界面對虛擬基帶資源池進行管控。OpenStack的安裝部署流程如圖3所示。步驟1為基本準備階段，需要網(wǎng)絡時間協(xié)議、數(shù)據(jù)庫等配置，以保證后續(xù)的服務模塊正常運作。步驟2～5分別為添加身份認證、鏡像服務，計算服務和用戶界面，計算節(jié)點只需安裝計算服務和網(wǎng)絡服務的部分模塊[16]。

圖3 OpenStack部署流程 Fig.3 Deployment process of OpenStack

2.3 動態(tài)遷移方案

信關站虛擬資源池目的在于資源池內(nèi)的資源共享，能夠進行靈活調(diào)度，為此需要研究虛擬管控平臺中的動態(tài)遷移方案。動態(tài)遷移是為了確保正常運行通過將虛擬機從一個物理機移動到另一個物理機時不會對虛擬機用戶造成太大的影響[17]，即保證資源靈活調(diào)度過程中，信關站服務的用戶能夠保持接續(xù)。本文將動態(tài)遷移所需要的源平臺和目的平臺的共用磁盤文件放置在一個共享存儲節(jié)點(控制節(jié)點)，實現(xiàn)數(shù)據(jù)的集中訪問，減少調(diào)用過程中頻繁傳輸對遷移性能造成的影響。本平臺采用基于的客戶端/服務器架構(gòu)的NFS(Network File System)網(wǎng)絡文件系統(tǒng)，支持通過網(wǎng)絡實現(xiàn)跨物理機分享文件。動態(tài)遷移的實現(xiàn)主要涉及OpenStack的計算服務Nova。在遷移之前需要做好如下配置：① 指定vncserver_listen=0.0.0.0,以保證動態(tài)遷移正常工作；② 節(jié)點之間能夠互相執(zhí)行名稱解析；③ 確保Nova和libvirt用戶的UID和GID在各個節(jié)點之間相同；④ 確保可以免密碼通過SSH實現(xiàn)節(jié)點的互通[18]。

3 虛擬化平臺及管控平臺動態(tài)遷移性能測試

3.1 虛擬化平臺的負載性能測試

本節(jié)構(gòu)建了信關站虛擬化基帶資源池的測試環(huán)境，組建了虛擬化管控平臺，分別測試同時運行1臺、2臺和4臺虛擬機時，平臺處理器、內(nèi)存和磁盤I/O的性能。虛擬化平臺的配置如下：

① 控制節(jié)點：處理器為Intel Core i5-6500，內(nèi)存12 G，雙網(wǎng)卡，ubuntu16.04操作系統(tǒng)；

② 計算節(jié)點：處理器為Intel Core i7-4770，內(nèi)存8 G，雙網(wǎng)卡，ubuntu16.04操作系統(tǒng)；

③ 虛擬客戶機：vCPU均為1核，內(nèi)存均為1 G，磁盤大小均為20 G，操作系統(tǒng)均為Ubuntu14.04。

本次測試將選取如下性能指標做分析：

① 處理器性能損耗：其中real time表示編譯從開始到結(jié)束的總時間，包括期間其他進程所占用的時間和進程被阻塞的時間；user time表示被測試程序在用戶模式下所占用的CPU時間，即進程執(zhí)行的真正CPU時間；sys time表示進程在內(nèi)核調(diào)用中所占用的CPU時間。

② 內(nèi)存性能：內(nèi)存的通信帶寬表示內(nèi)存的讀取速度，訪問操作時延表示存儲數(shù)據(jù)的訪問完成時產(chǎn)生的延遲，帶寬值越大、延遲越低、內(nèi)存性能就越好。

③ 磁盤IOPS和負載性能：IOPS指每秒的輸入輸出量或讀寫次數(shù)，是衡量磁盤性能的主要指標之一；負載性能是指在某項服務運行時，系統(tǒng)資源的使用情況，能反映出虛擬化平臺在運行測試過程中不同負載情況下的承受能力。

3.1.1 處理器性能損耗測試

虛擬化平臺中分別同時運行1臺、2臺、4臺虛擬客戶機，每個客戶機同時運行內(nèi)核編譯使CPU處于密集狀態(tài)，觀測虛擬化平臺中內(nèi)存的使用率由36.9%增長到76.6%，CPU的使用率由1.8%增加到24.7%，客戶機的編譯時間也逐漸增加。表1為虛擬化平臺同時運行4臺客戶機編譯所需時間。

表1 負載4臺虛擬機的內(nèi)核編譯時間Tab.1 Kernel compilation time for 4 virtual machines

由于不同負載下每臺客戶機的編譯所需時間相近，選取VM1的數(shù)據(jù)進行對比分析，如圖4所示。每臺虛擬機均處于CPU密集狀態(tài)，隨著負載數(shù)量增加，客戶機編譯內(nèi)核的時間有所增加。對于虛擬機，同時運行4臺虛擬機比運行1臺虛擬機時處理器的性能有所下降，對于虛擬化平臺，負載能力和內(nèi)存及CPU利用率有所提高。

圖4 不同負載下的VM1編譯時間Fig.4 VM1 compile time under different loads

3.1.2 內(nèi)存性能測試

選取內(nèi)存測試工具LMbench，基于不同負載情況的虛擬化平臺做測試，統(tǒng)計本地通信帶寬、內(nèi)存隨機訪問操作時延的數(shù)據(jù)。測試過程中，CPU空閑率從平臺負載最小時的約81.6%到平臺負載最大時的37.2%，有較大差距，說明在進行測試的過程中，負載的增加對平臺的處理器性能產(chǎn)生較大影響。針對不同的負載平臺，對本地通信帶寬和操作時延兩項數(shù)據(jù)進行分析，測試結(jié)果如圖5和圖6所示。

圖5 不同負載下的本地通信帶寬Fig.5 Local communication bandwidth under different loads

圖6 不同負載下的內(nèi)存隨機訪問操作時延Fig.6 Memory random access operation delay under different loads

以VM1為例，隨著負載的增加，本地通信帶寬呈現(xiàn)下降的趨勢，而操作時延呈上升趨勢。在高負載平臺下，多個虛擬機同時進行頁面的數(shù)據(jù)更新，相比于低負載平臺情況產(chǎn)生了更多開銷，出現(xiàn)較大時延，平臺性能也會下降。

3.1.3 磁盤IO負載性能測試

在不同負載情況的虛擬化平臺中，分別以大小為4 kbit,8 kbit,16 kbit,100 kbit,1 Mbit的數(shù)據(jù)塊進行讀寫操作，并對IOPS和CPU空閑率這兩項的數(shù)據(jù)做統(tǒng)計。由于不同負載下的每臺客戶機的IOPS相近，故對于VM1基于不同負載環(huán)境下的IOPS值進行統(tǒng)計，如圖7所示。

圖7 不同負載下磁盤性能指標Fig.7 Disk performance index under different loads

隨著虛擬化平臺中負載的增加，CPU空閑率逐漸降低，說明當負載越高，虛擬化平臺的處理器能力越處于高負荷狀態(tài)。在相同負載情況下，單次I/O塊文件越大，存儲每秒主機訪問次數(shù)就越少，IOPS越小；當負載增加時，出現(xiàn)不同虛擬機同時訪問磁盤I/O的情況，從而導致通信阻塞，每個虛擬機的存儲主機訪問次數(shù)降低，IOPS值有不同程度的減小。說明虛擬化平臺中，磁盤性能在一定程度上影響了數(shù)據(jù)讀寫。

3.2 動態(tài)遷移性能測試

本文選取OpenStack作為虛擬基帶資源池的管控平臺，基于NFS共享存儲的動態(tài)遷移，分別針對不同配置的客戶機進行動態(tài)遷移，分析該管控平臺中動態(tài)遷移性能。為減少誤差，如表2所示虛擬機的配置，分別選取內(nèi)存1 024 Mbit，2 048 Mbit及磁盤容量10 Gbit和20 Gbit的4種類型虛擬機作為測試樣本，操作系統(tǒng)均為Centos7。針對虛擬機空閑狀態(tài)和有負載(CPU使用率95%，內(nèi)存使用率75%)的情況下，動態(tài)遷移性能測試。表3和表4是不同情況下的虛擬機動態(tài)遷移過程中對遷移總時間、宕機時間和傳輸數(shù)據(jù)量的統(tǒng)計。

表2 虛擬機配置Tab.2 Configuration of virtual machine

表3 空閑態(tài)下的動態(tài)遷移數(shù)據(jù)統(tǒng)計Tab.3 Statistics of dynamic migration data in idle state

表4 負載情況下的動態(tài)遷移數(shù)據(jù)統(tǒng)計Tab.4 Statistics of dynamic migration data under load

由圖8和圖9可知，虛擬機的內(nèi)存大小和磁盤容量對遷移總時間和傳輸數(shù)據(jù)量均有一定的影響，而對于宕機時間影響不大。有負載的情況會導致相同配置的虛擬機在總遷移時間、宕機時間和傳輸數(shù)據(jù)量上存在較大差異。

圖8 動態(tài)遷移總時間和傳輸數(shù)據(jù)量Fig.8 Total time of dynamic migration and the amount of data transferred

圖9 動態(tài)遷移宕機時間和傳輸數(shù)據(jù)量Fig.9 Dynamic migration downtime and the amount of data transferred

4 結(jié)束語

基于KVM虛擬化技術，對信關站基帶處理單元虛擬化進而構(gòu)建虛擬基帶資源池，可屏蔽物理設備之間的差異性，提高物理設備的使用效率。本文針對虛擬基帶資源池的管控，提出基于OpenStack云計算平臺的管控架構(gòu)設計，可為信關站基帶處理單元的實時管理和動態(tài)調(diào)度提供平臺支撐。通過對虛擬平臺性能測試和管控平臺中動態(tài)遷移測試，驗證了該方案具有一定的有效性與穩(wěn)定性，從而可以有效降低設備的能耗和成本費用，增強對基帶處理單元資源的靈活管控，本文的工作可為我國衛(wèi)星移動通信系統(tǒng)信關站的建設提供技術和方案上的支持。