吳金壇 陳路路 李智鑫

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

2(復(fù)旦大學(xué)計算機科學(xué)技術(shù)學(xué)院 上海 200433)

0 引 言

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

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

1 背景介紹

1.1 虛擬化技術(shù)介紹

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

經(jīng)過多年發(fā)展和優(yōu)勝劣汰，目前主流的虛擬機技術(shù)是KVM硬件虛擬化技術(shù)，主流的容器技術(shù)是docker容器，其架構(gòu)分別如圖1和圖2所示。虛擬機虛擬化包括硬件虛擬化技術(shù)和指令集虛擬化技術(shù)，此處以硬件虛擬化技術(shù)為例說明。

圖1 虛擬機虛擬化架構(gòu)圖

圖2 容器虛擬化架構(gòu)圖

在圖1所示的虛擬機虛擬化架構(gòu)圖下，每個虛擬機在Hypervisor的管理下?lián)碛凶约邯毩⒌目蛻舨僮飨到y(tǒng)，互不干擾，在每個客戶操作系統(tǒng)之上可以運行獨立軟件和應(yīng)用。而容器則在Docker引擎的控制下，直接運行在宿主機的操作系統(tǒng)之上，多個Docker可以共享主機操作系統(tǒng)。相比之下，虛擬機架構(gòu)安全，隔離性強；容器則輕便，開銷小，易于快速部署。

1.2 虛擬機和容器應(yīng)用場景

虛擬機管理程序直接與宿主機硬件對接，虛擬機的操作系統(tǒng)和應(yīng)用程序構(gòu)成了一個單獨的環(huán)境，與物理機能力相同，同時應(yīng)用從物理機遷移到虛擬機的過程簡單，安全性有保障。虛擬機高度發(fā)展，技術(shù)成熟，因此企業(yè)普遍把虛擬機方案作為其核心業(yè)務(wù)的首選方案。

但是隨著技術(shù)的演變，容器方案也取得了一席之地。隨著微服務(wù)架構(gòu)發(fā)展，軟件應(yīng)用解耦為小功能，而容器能夠?qū)④浖蛛x開來，使得應(yīng)用程序更快地進行創(chuàng)建，更易于維護。在私有云數(shù)據(jù)中心中，借助私有云的安全內(nèi)控機制，在不用多考慮安全隔離的場景下，容器可以更好地服務(wù)于密集打包部署應(yīng)用。同時，容器僅對應(yīng)用實例進行隔離，資源開銷更低，大規(guī)模部署下更能節(jié)省計算資源成本[3]。

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

2 當前融合方案

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

2.1 虛擬機中運行容器

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

圖3 虛擬機中運行容器架構(gòu)圖

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

2.2 虛擬機和容器邏輯并存

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

圖4 虛擬機和容器邏輯共存架構(gòu)圖

這種架構(gòu)下，前端用戶可以在統(tǒng)一資源申請界面上申請?zhí)摂M機資源或容器資源，而后臺會將請求分發(fā)給對應(yīng)的服務(wù)器來處理請求。如中國銀聯(lián)公司采用獨立的物理資源池部署，虛擬機專用部分物理資源，容器專用另外的物理資源，相互獨立，虛擬機由OpenStack[9]管理，容器由Kubernetes[10]管理，兩個開源工具均直接部署在物理機之上。

2.3 當前融合方案優(yōu)缺點分析

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

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

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

3 虛擬化超融合技術(shù)方案

3.1 設(shè)計思路與架構(gòu)

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

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

(2) 實現(xiàn)底層資源池統(tǒng)一管理，由云計算的IaaS層對虛擬機與容器資源進行統(tǒng)一分配，實現(xiàn)異構(gòu)資源的聯(lián)合調(diào)度，打破數(shù)據(jù)中心資源墻。

(3) 實現(xiàn)容器編排，在云計算的PaaS層對容器進行統(tǒng)一編排管理，從而充分發(fā)揮容器的優(yōu)勢。

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

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

圖5 統(tǒng)一資源調(diào)度圖

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

圖6 容器編排架構(gòu)圖

3.2 虛擬化超融合解決方案

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

圖7 整體技術(shù)框架示意圖

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

針對上述問題，分別提出了相應(yīng)的解決方案，并進行了架構(gòu)原型系統(tǒng)的實現(xiàn)，描述如下：

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

圖8 OpenStack中Placement調(diào)度過程

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

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

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

圖9 OpenStack與Kubernetes融合設(shè)計架構(gòu)圖

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

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

圖10 Kuryr-Kubernetes架構(gòu)圖

3.3 方案優(yōu)勢

虛擬機和容器的超融合技術(shù)實現(xiàn)了虛擬機和容器資源的共享，實現(xiàn)了資源統(tǒng)一管理，同時實現(xiàn)了容器的編排調(diào)度，可以帶來如下優(yōu)勢：

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

(2) 實現(xiàn)容器虛擬機聯(lián)合調(diào)度，可直接看到資源分配情況。完成虛擬機和容器資源的統(tǒng)一管理，實現(xiàn)運行大數(shù)據(jù)集群的容器和虛擬機的聯(lián)合調(diào)度，虛擬機資源和容器資源互相感知。

(3) 對OpenStack構(gòu)建的容器應(yīng)用，通過與Kubernetes的融合，實現(xiàn)了高效的編排調(diào)度，提升對硬件資源的利用效率。

4 原型系統(tǒng)實踐與實驗結(jié)果

4.1 實驗環(huán)境

整個原型系統(tǒng)由OpenStack控制節(jié)點、Kubernetes控制節(jié)點、OpenStack計算節(jié)點三部分組成。本實驗搭建了8臺物理服務(wù)器規(guī)模的實驗環(huán)境，其中：1臺為OpenStack控制節(jié)點，1臺為Kubernetes控制節(jié)點，其余6臺為OpenStack計算節(jié)點。整體實驗環(huán)境部署架構(gòu)如圖11所示。

圖11 原型系統(tǒng)部署架構(gòu)

在網(wǎng)絡(luò)規(guī)劃上，為實現(xiàn)平臺流量的安全隔離，整體原型系統(tǒng)有管理網(wǎng)、業(yè)務(wù)網(wǎng)和存儲網(wǎng)三張網(wǎng)。管理網(wǎng)承載OpenStack及Kubernetes的服務(wù)數(shù)據(jù)，由于數(shù)據(jù)量較小，采用千兆網(wǎng)進行承載；業(yè)務(wù)網(wǎng)與存儲網(wǎng)則負責(zé)具體計算與業(yè)務(wù)數(shù)據(jù)的傳送，數(shù)據(jù)量大，對性能要求高，因此采用萬兆網(wǎng)絡(luò)進行承載。

本原型系統(tǒng)所有組件均基于OpenStack、Kubernetes、MariaDB等開源軟件設(shè)計研發(fā)，相應(yīng)軟件版本情況如表1所示。

表1 實驗環(huán)境軟件信息

4.2 效果展示

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

圖12 物理機資源使用情況

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

圖13 Hadoop容器集群信息

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

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

5 結(jié) 語

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