虛擬機和容器超融合試驗研究

吳金壇 陳路路 李智鑫

1(中國銀聯電子支付研究院 上海 201203)

2(復旦大學計算機科學技術學院 上海 200433)

0 引 言

當前，云計算已是金融機構運用金融科技打造現代化運營的基礎，越來越多的金融機構將實施云計算解決方案作為科技戰略創新的第一步，建立金融數字生態，金融行業已經形成了“上云刻不容緩”的共識，不僅是大金融機構，越來越多的中小金融機構對上云的需求也變得更加迫切[1]。隨著金融機構面向互聯網業務的迅速發展，數據中心云平臺規模及資源需求不斷提升，云計算平臺上的資源能否高效調度已上升為關鍵技術問題，解決好云資源高效調度問題，也就解決了企業的云資源快速供給問題。

虛擬化資源是云平臺的主要資源服務模式，因此虛擬化技術是云平臺的核心關鍵支撐技術。虛擬化技術將整個數據中心的計算資源統一抽象出來，形成可以按一定粒度分配的計算資源池。通過虛擬化技術的應用，數據中心可以具備更高的應用密度，從而在等量資源情況下能夠為更多的用戶提供服務。

1 背景介紹

1.1 虛擬化技術介紹

虛擬機和容器是當前主流的虛擬化技術[2]。虛擬機(Virtual Machine，VM)指通過軟件模擬的、具有完整硬件系統功能的、運行在一個完全隔離環境中的完整計算機系統。虛擬機技術最早由IBM于二十世紀六七十年代提出，其中虛擬機監視器(Virtual Machine Monitor，VMM)是虛擬機技術的核心，它是一層位于操作系統和計算機硬件之間的代碼，用來將硬件平臺分割成多個虛擬機。VMM運行在特權模式，主要作用是隔離并且管理上層運行的多個虛擬機，仲裁它們對底層硬件的訪問，并為每個客戶操作系統虛擬一套獨立于實際硬件的虛擬硬件環境(包括處理器、內存、I/O設備)。容器技術則是一種沙盒技術，可以將應用運行在其中，與外界隔離，這個沙盒可以被方便地“轉移”。本質上，容器就是一種特殊的進程。通過在創建容器進程的時候，指定了這個進程所需要啟用的一組命名空間(Namespace)參數，進而讓該容器進程只能看到當前Namespace所限定的資源、文件、設備、狀態或配置。

經過多年發展和優勝劣汰，目前主流的虛擬機技術是KVM硬件虛擬化技術，主流的容器技術是docker容器，其架構分別如圖1和圖2所示。虛擬機虛擬化包括硬件虛擬化技術和指令集虛擬化技術，此處以硬件虛擬化技術為例說明。

圖1 虛擬機虛擬化架構圖

圖2 容器虛擬化架構圖

在圖1所示的虛擬機虛擬化架構圖下，每個虛擬機在Hypervisor的管理下擁有自己獨立的客戶操作系統，互不干擾，在每個客戶操作系統之上可以運行獨立軟件和應用。而容器則在Docker引擎的控制下，直接運行在宿主機的操作系統之上，多個Docker可以共享主機操作系統。相比之下，虛擬機架構安全，隔離性強；容器則輕便，開銷小，易于快速部署。

1.2 虛擬機和容器應用場景

虛擬機管理程序直接與宿主機硬件對接，虛擬機的操作系統和應用程序構成了一個單獨的環境，與物理機能力相同，同時應用從物理機遷移到虛擬機的過程簡單，安全性有保障。虛擬機高度發展，技術成熟，因此企業普遍把虛擬機方案作為其核心業務的首選方案。

但是隨著技術的演變，容器方案也取得了一席之地。隨著微服務架構發展，軟件應用解耦為小功能，而容器能夠將軟件分離開來，使得應用程序更快地進行創建，更易于維護。在私有云數據中心中，借助私有云的安全內控機制，在不用多考慮安全隔離的場景下，容器可以更好地服務于密集打包部署應用。同時，容器僅對應用實例進行隔離，資源開銷更低，大規模部署下更能節省計算資源成本[3]。

基于虛擬機和容器的技術各有優勢[4-5]，可以預見，虛擬機與容器未來在云數據中心環境內必然是共同存在的，如何實現虛擬機與容器的共融部署是當前云平臺建設的關鍵研究方向，分析虛擬機與容器如何融合部署和實現高效調度正是本文要解決的問題。

2 當前融合方案

當前的數據中心所采取的虛擬機和容器技術融合方案可以分為兩大類，第一類是容器運行于虛擬機之上，第二類是將容器和虛擬機分別運行在不同物理服務器上。

2.1 虛擬機中運行容器

容器運行于虛擬機方案的基本架構如圖3所示。

圖3 虛擬機中運行容器架構圖

在此架構下，虛擬機監視器(Hypervisor)運行于物理服務器之上，物理服務器資源被分配給多臺虛擬機，在虛擬機之上運行Docker容器引擎，實現一臺虛擬機上運行一個或多個容器，由虛擬機為容器提供資源。國內企業如云南云電同方科技提出的虛擬機和容器融合的混合架構[6]，國家電網公司信通部設計的與服務器相適應的容器虛擬化框架[7]，國外企業如Google和Amazon等主流服務提供商的云計算虛擬融合系統，均采取該類方案[8]。

2.2 虛擬機和容器邏輯并存

第二種方案是將虛擬機和容器在物理資源層面分開，前端提供統一資源請求接口，根據資源請求對任務進行分發至不同的物理服務器，基本架構如圖4所示。

圖4 虛擬機和容器邏輯共存架構圖

這種架構下，前端用戶可以在統一資源申請界面上申請虛擬機資源或容器資源，而后臺會將請求分發給對應的服務器來處理請求。如中國銀聯公司采用獨立的物理資源池部署，虛擬機專用部分物理資源，容器專用另外的物理資源，相互獨立，虛擬機由OpenStack[9]管理，容器由Kubernetes[10]管理，兩個開源工具均直接部署在物理機之上。

2.3 當前融合方案優缺點分析

第一種融合方案在虛擬機中運行容器利用了兩者技術的優勢，容器中的應用既實現了輕量化，又能有良好的隔離性，但效率受到很大影響：(1) 需要創建虛擬機，在創建虛擬機時要預估虛擬機容量；(2) 容器刪除時，釋放的資源被虛擬機保留著，不能回收利用；(3) 開發人員還需要對容器運行的虛擬機環境進行管理。

第二種融合方式僅是在邏輯層面的融合，是一種“邏輯共存，物理隔離”的融合方案，對用戶而言雖然可以享受到虛擬機和容器的服務，但在物理層面，虛擬機和容器并沒有融合，存在以下問題：(1) 調度不夠靈活，虛擬機和容器智能調度僅能在各自指定的服務器上運行；(2) 未能實現虛擬機和容器資源的相互彈性使用，虛擬機或容器各自的資源的總量是由各自分配給的服務器量所決定的；(3) 資源利用率低，分配給虛擬機和容器的服務器都要超過業務需求，以防止突發大量訪問。

總體而言，這兩種方案雖然有各自的優點，但對資源的利用率都不夠高。

3 虛擬化超融合技術方案

3.1 設計思路與架構

1) 虛擬化超融合方案設計思路。針對上述方案一中容器部署在虛擬機上所造成的性能損耗問題和方案二中虛擬機和容器物理隔離導致數據中心內出現資源墻的問題，探索出一種新的虛擬機與容器融合的方案，其主要設計思路如下。

(1) 虛擬機與容器可共存于同一物理節點，且容器直接運行于物理機之上，虛擬機與容器共享物理機資源，減少性能損耗。

(2) 實現底層資源池統一管理，由云計算的IaaS層對虛擬機與容器資源進行統一分配，實現異構資源的聯合調度，打破數據中心資源墻。

(3) 實現容器編排，在云計算的PaaS層對容器進行統一編排管理，從而充分發揮容器的優勢。

2) 虛擬化超融合架構。云計算從服務層次上可以劃分為三層，分別為IaaS層(基礎設施服務)、PaaS層(平臺服務)和SaaS層(軟件服務)，本方案架構涉及前兩個層面，分別是Iaas層的資源統一管理調度和Paas層的容器編排。

(1) IaaS層：資源統一管理調度。IaaS層的融合架構如圖5所示。云資源管理平臺構建一個統一的物理資源池，對計算、網絡、存儲等資源進行統一納管。虛擬機和容器分別由各自的管理組件創建，所有資源請求全部由資源調度協調器進行審核，并篩選出滿足要求的物理機節點進行分配。鏡像由云資源管理平臺統一提供。虛擬機和容器生命周期結束后，由云資源管理平臺把資源釋放回資源池。

圖5 統一資源調度圖

(2) PaaS層：容器編排。構建PaaS層的融合架構如圖6所示。容器編排有多種方案[11]，IaaS層完成了對虛擬機和容器的生命周期管理，PaaS層則進一步融合實現對容器的編排能力。通過副本管理、標簽管理、接口管理等服務組件，將分布在不同物理節點、松散結合的容器進行邏輯化的組織，形成相關功能集群，以實現負載均衡、擴容縮容、灰度升級及故障冗余等能力，集群容器編排的相關算法也是值得探究的方向[12]。

圖6 容器編排架構圖

3.2 虛擬化超融合解決方案

基于上述方案架構，采用開源技術框架進行了實現。IaaS層采用OpenStack為底層資源管理工具，PaaS層采用Kubernetes為容器編排工具，整體技術框架如圖7所示。

圖7 整體技術框架示意圖

在實現過程中，單純采用開源的原生方案無法滿足一些核心功能點，主要問題如下：(1) OpenStack中的Zun組件雖然可以創建容器，但是在資源管理上，原生OpenStack并沒有實現虛擬機與容器資源信息的互通共享，從而出現虛擬機與容器之間的資源競爭問題，因此必須在IaaS做到虛擬機與容器資源的統一協調分配。(2) 本文方案采用OpenStack的Zun來創建容器，而上層又需要Kubernetes對容器進行編排，因此必須對兩個平臺的相關組件進行對接。另外，Zun與Kubernetes在對容器操作的時候，各自采用了不同的管理模型，因此對接過程中還需要對兩種不同的管理模型進行轉化。(3) OpenStack和Kubernetes的網絡方案不同，融合后需要新的網絡通信方案。

針對上述問題，分別提出了相應的解決方案，并進行了架構原型系統的實現，描述如下：

1) 虛擬機和容器共存的資源統一管理。在實現容器與虛擬機融合資源管理方面，原型系統基于OpenStack Placement項目進行了聯合調度的數據接口定制，并重新編寫了Zun和Nova服務模塊的實時調度策略，支持在融合視圖下的計算資源統一管理，如圖8所示。

圖8 OpenStack中Placement調度過程

相比原生Placement，本系統在實現過程中進行了如下能力增強[13]：(1) 打破原生Placement對虛擬機和容器資源分別單獨管理的結構，重構了虛擬機與容器資源信息共享的管理機制，在資源管理與調度層面為超融合打下基礎；(2) 為方便管理，將虛擬機與容器的底層數據模型進行統一化處理，并基于此對數據管理、業務邏輯等相關代碼進行重新編寫；(3) 在虛擬機與容器的調度策略中加入NUMA機制，實現了對底層硬件資源的精細化管理。

2) 虛擬機和容器共存的容器編排。一些方案已實現虛擬機和容器的編排調度[14-15]，在容器管理的設計上，在IaaS層通過OpenStack的Zun組件來創建容器，在PaaS層則通過Kubernetes對容器進行編排。但Zun管理容器的模型是Container，而Kubernetes編排容器的模型是Pod。由于IaaS層與PaaS層容器管理模型不同，兩層無法直接對接。

本方案通過開發中間組件Virtual Kubelet(VK)，來實現兩種不同管理模型的轉換。VK組件作為Kubernetes與OpenStack信息交互的橋梁，首先要對Kubernetes的Master節點對容器的操作請求進行監聽，然后在內部將請求信息中的POD數據模型轉換為OpenStack可識別的Contaner數據模型，進而將請求下發至OpenStack平臺。同樣在OpenStack操作完畢后返回信息的時候，VK組件還要進行一次反向轉換。同時為方便管理部署，本方案將VK注冊集成至Kubernetes平臺中。整體架構圖如圖9所示。

圖9 OpenStack與Kubernetes融合設計架構圖

3) 虛擬機和容器共存的網絡模型解決方案。在網絡融合對接上，本方案基于OpenStack已有的網絡組件——Kuryr，與Kubernetes網絡進行適配對接，定制化開發Kuryr-Kubernetes組件。該組件南向可調用Neutron接口，為上層提供實際的網絡資源，實現底層網絡功能，北向則實現了Kubernetes的標準網絡CNI接口，為PaaS層的網絡調度編排提供驅動，從而實現了虛擬機與容器網絡方案的融合。

具體而言，Kuryr-Kubernetes使用Neutron LbaaS v2代替kube-proxy組件，解決了Kubernetes service映射到pod endpoints的問題。將service中的ClusterIP映射為LbaaS的vip，將service后面對應的podIP：port添加到LbaaS的pool中作為member。通過Kuryr-Kubernetes將Kubernetes和OpenStack網絡融合，在Kubernetes網絡實現的同時，確保了OpenStack Neutron作為統一的網絡方案對容器和虛擬機的管理。容器間網絡直接連接，不需要向下再包一層虛擬機網絡，解決兩次overlay性能差的問題。容器網絡也可以使用Neutron中security group和floatingIP等功能，如圖10所示。

圖10 Kuryr-Kubernetes架構圖

3.3 方案優勢

虛擬機和容器的超融合技術實現了虛擬機和容器資源的共享，實現了資源統一管理，同時實現了容器的編排調度，可以帶來如下優勢：

(1) 提高資源利用率，降低成本。采用虛擬機技術和容器技術共同支撐應用，可以大幅增強資源的靈活調度，同時通過計算力的精細化調度進一步提升了應用性能。

(2) 實現容器虛擬機聯合調度，可直接看到資源分配情況。完成虛擬機和容器資源的統一管理，實現運行大數據集群的容器和虛擬機的聯合調度，虛擬機資源和容器資源互相感知。

(3) 對OpenStack構建的容器應用，通過與Kubernetes的融合，實現了高效的編排調度，提升對硬件資源的利用效率。

4 原型系統實踐與實驗結果

4.1 實驗環境

整個原型系統由OpenStack控制節點、Kubernetes控制節點、OpenStack計算節點三部分組成。本實驗搭建了8臺物理服務器規模的實驗環境，其中：1臺為OpenStack控制節點，1臺為Kubernetes控制節點，其余6臺為OpenStack計算節點。整體實驗環境部署架構如圖11所示。

圖11 原型系統部署架構

在網絡規劃上，為實現平臺流量的安全隔離，整體原型系統有管理網、業務網和存儲網三張網。管理網承載OpenStack及Kubernetes的服務數據，由于數據量較小，采用千兆網進行承載；業務網與存儲網則負責具體計算與業務數據的傳送，數據量大，對性能要求高，因此采用萬兆網絡進行承載。

本原型系統所有組件均基于OpenStack、Kubernetes、MariaDB等開源軟件設計研發，相應軟件版本情況如表1所示。

表1 實驗環境軟件信息

4.2 效果展示

1) 功能描述。為了展示容器與虛擬機超融合效果，該方案在OpenStack的DashBoard組件上(物理機信息頁面)開發了資源使用情況信息展示功能。如圖12所示，本文提出在物理節點上統一呈現所有已創建虛擬機與容器情況的思路，并給予實現。從中可以看到各自使用的NUMA架構信息——CPU信息和內存信息。

圖12 物理機資源使用情況

2) 應用部署實驗。在利用Kubernetes編排能力方面，實驗通過模版導入的方式創建了基于容器的Hadoop集群，如圖13所示。

圖13 Hadoop容器集群信息

為了驗證此架構的性能，與在物理機上運行的Hadoop集群性能進行了測試對比，對比結果如表2所示。可以看出，在運行相同任務的情況下，基于NUMA架構的精細化管理的容器集群取得了比物理機更好的效果。

表2 物理機和容器運行Hadoop集群性能對比

5 結 語

虛擬機技術和容器技術作為數據中心重要的虛擬化技術，在降低成本的同時為用戶提供了高效便捷的服務，但虛擬機不夠便捷，容器不夠安全，未來數據中心將會融合兩種方案為用戶服務。本文針對目前數據中心融合方案進行了分析并提出了一種新的融合方案，在資源融合調度等方面取得了顯著優勢，進一步降低了數據中心的運營成本，融合方案也解決了融合后容器的編排問題，并通過實驗驗證融合方案可行。容器和虛擬機共存已成必然，統一的資源管理也會變得更加快捷、簡單，在同一臺物理機上部署虛擬機和容器勢必會推動云計算技術向著更加完備的方向發展。下一步會繼續對融合方案進行優化和完善，推動方案向生產應用快速演進。