打造完全自主可控的云操作系統(tǒng)-云平臺

［完仝目主可控云操作系

打造完全自主可控的

云操作系統(tǒng)

可行性分析與設計

王智民2015-3

［完仝目主可控云操作系統(tǒng)可行性分析5殳計］--------------------------------------------------

目錄

目錄..................................................................................2

1云計算帶來的歷史機遇...............................................................1

2云操作系統(tǒng)安全自主可控的必要性....................................................2

3自主安全可控的可行性分析...........................................................3

3.1自主安全可控云操作系統(tǒng)定位....................................................34

3.2自主開發(fā)的可行性分析..........................................................34

3.3安全可控的可行性分析..........................................................98

4云操作系統(tǒng)設計...................................................................108

4.1計算機操作系統(tǒng)...............................................................1Q8

4.2云操作系統(tǒng)與云角色...........................................................119

4.3體系結(jié)構(gòu)....................................................................1240

4.3.1總體設計....................................................................1240

4.3.2運行部署....................................................................1342

4.3.3組件通信....................................................................1443

4.3.4微內(nèi)核........................................................................16

4.3.5云控制.....................................................................3132

4.3.6云交付.....................................................................4346

4.3.7云管理.....................................................................46&1-

4.4安全可控設計...............................................................

4.4.1安全風險分析................................................................5165

4.4.2安全可控評估模型...........................................................5459

4.4.3如何做到安全可控...........................................................5459

5總結(jié)............................................................................7585

6附錄............................................................................Z585

6.1KVM運行原理...............................................................76&5

6.1.1基本術語....................................................錯誤!未定義書簽。85

1

［完仝目主可控云操作系統(tǒng)可行性分析5殳計］

6.1.2KVM框架Z687

6.1.3KVM運行視圖............................ZZ88

6.1.4KVM內(nèi)核模塊,錯誤!未定義書簽。9Q

6.2VIRTIO性能數(shù)據(jù)...........................7990

621性能測試環(huán)境7990

6.2.2性能數(shù)據(jù)7994

7參考資料.......................................................................Z994

4

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］------------------------------------------------

1云計算帶來的歷史機遇

中國IT產(chǎn)業(yè)的發(fā)展大致經(jīng)歷了三個階段：

第一個階段是80年代中期90年代的個人計算機時代，這個時代將昂貴的大型的計算機變

成個人可負擔的電腦，極大的提高了個人勞動效率。

第二個階段是90年代中期到20世紀的互聯(lián)網(wǎng)時代，這個時代將各種信息孤島匯成非常龐

大網(wǎng)絡，解決了人與人、人與物的有效溝通、共享與協(xié)作的效率。

第三個階段是云計算時代，這個時代將IT資源從分散再次回歸到集中的模式，通過提高IT

資源的利用率從而極大的降低了II消費的成本。

那么云計算發(fā)展給中國帶來了哪些重大歷史機遇呢？

1.云計算的規(guī)模效應會更加顯著

傳統(tǒng)數(shù)據(jù)中心的IT資源利用率目前大多不到50%,通過云計算技術可以使得服務器的利用

率提升到80%以上。

中國人口眾多，高峰時段對服務資源的需求與正常時段之間的差距會非常大，相比歐美等其

他國家，在服務需求的低峰時段，我們國家會有更過的資源被閑置，這樣造成了資源的大量

浪費。如果利用云計算的技術，實現(xiàn)資源的集中和共享，把空閑時段的資源補充到其他需要

的服務上，那么資源利用率提升的規(guī)模效應相對歐美等人口較少的國家就大得多。

2.云計算發(fā)展推動中國自主創(chuàng)新，縮短中國與歐美國家的差距

現(xiàn)在不論在國內(nèi)還是在國外，云計算還處于起步階段，云計算的技術在逐步完善，云計算之

上的應用在不斷增多。云計算作為一種創(chuàng)新的IT基礎架構(gòu)管理方法和創(chuàng)新的商業(yè)模式，代

表了未來IT發(fā)展的方向。如果我們國家能趕在其他國家之前，加大云計算的投資，培養(yǎng)云

計算相關人才，建立云計算標準，推動云計算技術的發(fā)展，將會在未來IT競爭中，縮短與

歐美國家之間的差距，并在國家競爭中占據(jù)一定的有利地位。

3.云計算的高效與彈性將加速我國關系國計民生的重大行業(yè)的信息化建設

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

在中國，關系國計民生的重大行業(yè)包括銀行、交通、能源、醫(yī)療等等，每個行業(yè)都面臨信息

化建設的變革，以提升服務效率。

云計算技術方便的實現(xiàn)現(xiàn)有IT資源的重新利用，現(xiàn)有應用向云平滑遷移，同時在自動化、

彈性、控制等方面具有先天的優(yōu)勢，可以使得云計算技術、產(chǎn)品、服務大規(guī)模應用在國家重

大行業(yè)，加速這些行業(yè)的信息化建設與變更，以適應中國當前高速發(fā)展的需要。

2云操作系統(tǒng)安全自主可控的必要性

信息技術的前兩個階段，中國由于受限于當時的國情和歷史背景都未能把握。這在客觀上也

造成了中國信息產(chǎn)業(yè)當下仍落后于發(fā)達國家的現(xiàn)狀。而第三次浪潮一云計算變革則方興未

艾，處于發(fā)展初期。中國應當保持高度敏銳的“嗅覺”，在已經(jīng)具備▼相當?shù)男畔a(chǎn)業(yè)的基

礎上，密切跟蹤云計算變革的發(fā)展情況，緊跟產(chǎn)業(yè)發(fā)展潮流，提前進行產(chǎn)業(yè)規(guī)劃和引導，積

極制定云計算服務標準，力爭在本次信息產(chǎn)業(yè)變革的浪潮中奪取主動地位，促進中國經(jīng)濟結(jié)

構(gòu)的調(diào)整，擺脫長期以來在全球經(jīng)濟分工中的被動地位。

未來信息服務競爭的關鍵是“效率”之爭，而提升效率的技術路徑無外乎硬件和軟件。云計

算浪潮則從硬件和軟件兩個方面同時推動信息技術和服務效率達到前所未有的高度。

云計算變革勢不可擋，對中國來說是一次重大的商業(yè)機會，但同時也是一次重大的國家戰(zhàn)略

布局的機會。云計算的特點是數(shù)據(jù)的大集中，所有的應用都要通過云平臺與硬件進行交互，

所以它需要一個超大規(guī)模的、高效的云操作系統(tǒng)。但是如果中國沒有自主的云操作系統(tǒng)，中

國企業(yè)80%-90%的應用都運行在別人的云操作系統(tǒng)上，會是什么結(jié)吳？我們失掉的恐怕不

僅僅是市場，而是國家戰(zhàn)略。

所以中國在這個技術變革的關鍵歷史時刻，需要有自主的云操作系統(tǒng)，而且是“完全自主知

識產(chǎn)權的”、“安全可控的”云操作系統(tǒng)。

所以相對云服務提供商的系統(tǒng)管理員來說，需要安全可控的云操作系統(tǒng)，因為系統(tǒng)管理員需

要確保云服務可持續(xù)提供、高質(zhì)量提供、確保云不被利用等安全性；

相對于信息安全官員、審計者來說，需要安全可控的云操作系統(tǒng)，因為他需要對云的可控性、

可信性、可靠性和安全性進行全面的關注；

相對于信息技術編程者來說，需要安全可控的云操作系統(tǒng),一方面底層編程者通過自己設計、

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

編碼、測試確保云操作系統(tǒng)是完全自主可控的，另一方面云服務編程者需要底層操作系統(tǒng)提

供的支撐是可信的、可靠的、安全的；

相對于政府信息技術服務采購者來說，需要安全可控的云操作系統(tǒng)，需要確保采購使用的云

服務是在國家層面絕對可控的、可信的。

相對于公共云服務使用者來說,需要安全可控的云操作系統(tǒng)，因為他們更關注云服務的可信、

可靠。

3自主安全可控的可行性分析

3.1自主安全可控云操作系統(tǒng)定位

1）能夠適應私有云、公有云、社區(qū)云和混合云等幾種云部署模式

2）能夠適應laaS、PaaSsSaaS等幾種云服務模式

3.2自主開發(fā)的可行性分析

3.2.1計算機操作系統(tǒng)的運行原理

計算機操作系統(tǒng)是計算機中最基本的系統(tǒng)軟件，它控制計算機的所有資源并提供應用程序開

發(fā)和運行的基礎。所以操作系統(tǒng)的兩個基本功能就在于“資源控制”與“為應用程序提供開

發(fā)和運行的環(huán)境”。

從不同的角度來看，操作系統(tǒng)所表現(xiàn)的形式是不同的。從用戶的角度看，操作系統(tǒng)所體現(xiàn)是

它所提供的各式各樣的服務；從程序員的角度來看，操作系統(tǒng)體現(xiàn)的是提供給用戶的界面和

接口；而從設計人員的角度來看，操作系統(tǒng)又是一大堆模塊和它們之間的相互聯(lián)系［1］。

資源控制

資源控制一般涉及到資源的申請、釋放與使用，而資源使用則會涉及到資源的分割、重組、

調(diào)配。

計算機資源一般包括計算、存儲和網(wǎng)絡，所以計算機操作系統(tǒng)的資源控制基本都困繞這三個

方面來進行的。

［完仝自主可控云操作系統(tǒng)可行性分

為應用程序提供開發(fā)與運行環(huán)境

計算機應用程序是利用計算機資源完成特定工作的計算機程序。所以應用程序一方面會使用

計算機操作系統(tǒng)提供的接口申請、使用和釋放計算、網(wǎng)絡和存儲資源，另一方面會使用計算

機操作系統(tǒng)提供的接口與用戶進行交互，交互的界面有多種，比如字符視窗界面、聲音光電、

網(wǎng)絡等。

對于計算機操作系統(tǒng)來說，可能服務多個應用程序，所以操作系統(tǒng)還需要考慮多個應用程序

的資源競爭的協(xié)調(diào)與調(diào)度。

我們知道，計算機操作系統(tǒng)經(jīng)歷了簡單結(jié)構(gòu)、單體內(nèi)核結(jié)構(gòu)、層次式結(jié)構(gòu)、微內(nèi)核結(jié)構(gòu)、外

核結(jié)構(gòu)等發(fā)展過程，但是計算機操作系統(tǒng)的核心組件仍然是CPU調(diào)度、內(nèi)存管理、進程調(diào)

度、文件系統(tǒng)、網(wǎng)絡管理、設備驅(qū)動等。下圖是單體內(nèi)核結(jié)構(gòu)的操作系統(tǒng)結(jié)構(gòu)圖：

CPUMemoryNetworkDiskI/O

圖單體結(jié)構(gòu)計算機操作系統(tǒng)示意圖

3.2.2云操作系統(tǒng)的核心部件

云操作系統(tǒng)與計算機操作系統(tǒng)在一定程度上具有較大的相似性，從資源的角度來看，云操作

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］4^

系統(tǒng)的資源控制仍然離不開計算、網(wǎng)絡和存儲的控制，為運行在云操作系統(tǒng)上的云應用提供

開發(fā)和運行的環(huán)境。但是云操作系統(tǒng)在這兩個方面的實現(xiàn)方式上由于底層物質(zhì)基礎的不同而

有較大的差異。

一臺個人計算機的內(nèi)部結(jié)構(gòu)圖如下:

南橋

磁盤陣列控制器

VVWWV

圖個人計算機結(jié)構(gòu)

我們知道，云計算的本質(zhì)是要求“按需”提供信息技術服務，則要求n■資源能夠做到集中

控制與使用，足夠的細粒度可控、足夠的靈活調(diào)度，并能夠做到資源調(diào)度的自動化。

為了實現(xiàn)云計算，人們就自然的與計算機操作系統(tǒng)做對比，CPU、內(nèi)存、硬盤資源能否再

分割以便于做到足夠的細粒度可控，CPU、內(nèi)存、硬盤資源能否做到集群分布式運行以便

于做到資源的大規(guī)模集中控制與使用，CPUs內(nèi)存、硬盤資源能否用靈活的網(wǎng)絡連接以便

于做到資源的擴充或縮減；CPU、內(nèi)存、硬盤資源的調(diào)度能否支撐更大規(guī)模更加有效等，

所以數(shù)據(jù)中心逐步演化為下面的邏輯結(jié)構(gòu)：

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

圖云數(shù)據(jù)中心基礎設施結(jié)構(gòu)

所以云操作系統(tǒng)的核心組件主要有：

1）計算、網(wǎng)絡、存儲的池化

2）計算、網(wǎng)絡、存儲的集群管理

3）計算、網(wǎng)絡、存儲的組裝與卸載

4）資源對外交互與呈現(xiàn)

5）安裝與部署

3.2.3參考資源

涉及領域可參考開源項目參考價值

CoreOS適用于虛擬化的專用宿主操作系統(tǒng)

計算機操作系統(tǒng)

IntelDPDK專用賓客操作系統(tǒng)

系統(tǒng)架構(gòu)OpenStack整體框架的包容性、適應性

CloudStack計算虛擬化的經(jīng)典模型

組件通信Message組件解耦、異步通信、并發(fā)性能提升

Queue(RabbitMQs

Qpid、ZeroMQ)

FMN基于信令憑證的一種高速通信方式

計算虛擬化KVMsXEN經(jīng)典Hypervisor

libvirt多hypervisor的控制與管理

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］4^

namespaceLinux容器實現(xiàn)的基礎

virtioI/O設備虛擬化

SR-IOVsmacvtapI/Opass-through

KVMGTIntel@GVT-g在kvm上實現(xiàn)的一個完整GPU

虛擬化解決方案

FreeRDP開源的遠程桌面顯示協(xié)議

spice開源的遠程桌面顯示協(xié)議

網(wǎng)絡虛擬化OpenFlow基于流表實現(xiàn)網(wǎng)絡路徑的虛擬化

Overlay基于隧道實現(xiàn)網(wǎng)絡路徑的虛擬化

OpenvSwitch一種虛擬交換機的實現(xiàn)

存儲虛擬化LVMsCLVMLinux集成的邏輯卷管理

資源管理與運行控制OpenStack計算:Nova

網(wǎng)絡：Neutron

塊存儲：Cinder

對象存儲：Swift

身份管理：KeyStone

鏡像管理:Glance

度量監(jiān)控：Ceilometer

部署編排:Heat

大數(shù)據(jù)：Sahara

OpenDaylightSDNcontroller的一個實現(xiàn)

OpenContrail借鑒MPLS的一種SDN實現(xiàn)

LXCLinux實現(xiàn)的應用容器引擎

DockerdotCloud開源的一個基于LXC的高級容器

引擎

KubernetesGoogle開源的Docker容器集群管理系統(tǒng)

Niagara物聯(lián)網(wǎng)自動化控制系統(tǒng)之一

Sedonac開源的用于嵌入式設備編程和開發(fā)的軟件平臺

1

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］------------------------------------------------

3.2.4人才基礎

自主開發(fā)完成云操作系統(tǒng)，主要的人才需求與現(xiàn)狀分析:

角色技能要求主要職責我國人才現(xiàn)狀

系統(tǒng)架至少10年以上直接參從頂層設計云操作系統(tǒng)的已經(jīng)具備相當數(shù)量

構(gòu)師與設計代碼規(guī)模超過體系結(jié)構(gòu)

100萬行大型軟件項

目經(jīng)歷

掌握云計算、基礎網(wǎng)

絡、信息安全相關領

域的知識

項目經(jīng)至少10年以上直接參組建、主導、指導、計劃、已經(jīng)具備相當數(shù)量

理與管理人員規(guī)模超過監(jiān)控整個云操作系統(tǒng)開發(fā)

100人的項目團隊經(jīng)項目

歷

熟練掌握與應用項目

管理技能

軟件工至少2年以上自主設云操作系統(tǒng)相關開發(fā)大量

程師計、編碼、測試代碼

規(guī)模累計超過10萬行

軟件模塊經(jīng)歷

熟練掌握云計算、基

礎網(wǎng)絡、信息安全相

關領域之一的知識

測試工至少2年以上主導測云操作系統(tǒng)的集成、系統(tǒng)、大量

程師試超過10萬行軟件模驗收測試，為交付的質(zhì)量把

塊的測試經(jīng)歷關

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

熟練掌握云計算、基

礎網(wǎng)絡、信息安仝相

關領域之一的知識

質(zhì)量保至少5年以上主導過項目過程中流程引導、工程人才稍微欠缺，大部分集中

障員超過10萬行軟件模塊方法指導、質(zhì)量監(jiān)控與審計在大型民營企業(yè)中

的質(zhì)量保障工作

熟練掌握軟件質(zhì)量保

障的相關知識與技能

安全保至少2年以上主導過體系框架、設計、代碼等領人才相對比較短缺

障員超過10萬行軟件模塊域的漏洞挖掘、脆弱性分

的漏洞挖掘、脆性性析，將安全意識和措施落實

分析與測試等工作到從設計到交付整個過程，

熟練掌握代碼審計、盡可能減少系統(tǒng)的安全漏

脆弱性分析等的相關洞、不安全因素

知識與工具

3.3安全可控的可行性分析

3.3.1開源代碼的參考與使用

在參考和使用開源代碼的過程中，我們需要堅持幾個原則:

D參考但不照搬

2）先消化吸收，經(jīng)過加固后有選擇的采納

3）逐步重構(gòu)，達到所有組件自主可控

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］------------------------------------------------

3.3.2系統(tǒng)本身的安全性評估與加固

針對系統(tǒng)本身的安全性評估，從以下三個方面加以評估和著手解決：

①對操作系統(tǒng)代碼本身的安全審計，即代碼靜態(tài)審查”

可以組件攻防實驗里，定期地對云操作系統(tǒng)代碼進行安全審計，并及時整改。

②漏洞主動挖掘

建立完善的系統(tǒng)運行漏洞檢測機制，即“動態(tài)審查”，運用漏洞掃描平臺、攻擊掃描平臺主

動挖掘潛在的安全漏洞。

③加固采納的開源代碼

有些開源項目已經(jīng)比較成熟、穩(wěn)定、沒有太多必要再次開發(fā)，所以可能會直接采納使用，但

無論開源代碼是否存在不為人知的“后門”，都給云操作系統(tǒng)的安全帶來隱患。為此，對于

所有采納的開源組件，需要進行組件“加固”。

4云操作系統(tǒng)設計

4.1計算機操作系統(tǒng)

云計算涉及到的操作系統(tǒng)有：

1）服務器節(jié)點底層支持虛擬化的操作系統(tǒng)，通常稱之為宿主操作系統(tǒng)（hostos）

2）運行在虛機里面的操作系統(tǒng)，通常稱之為賓客操作系統(tǒng)（guestos）

3）支持遠程桌面的操作系統(tǒng)，可能是常見的嵌入式操作系統(tǒng)，也可能是普通的個人電腦操

作系統(tǒng)

宿主操作系統(tǒng)，大部分情況下使用Linux操作系統(tǒng)，但如果要考慮安全可控和性能因素，則

需要專門的宿主操作系統(tǒng)：

1）國產(chǎn)操作系統(tǒng)比如詹其麟操作系統(tǒng)，可以從理論上確保宿主操作系統(tǒng)的安全可控

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

2)專門用于云的宿主操作系統(tǒng)，針對云計算的特定需求做裁剪和優(yōu)化，以便于更好的支持

KVM.,XEN-.容器等虛擬化需求

運行在虛機里面的賓客操作系統(tǒng)通常情況下與個人電腦操作系統(tǒng)無異，但由于底層的各種資

源都是虛擬的，性能相對運行在實體物理機器上下降很多，特別是一些I。密集型應用性能

更是下降得厲害，所以針對特定的應用，也有必要專門的賓客操作系統(tǒng)。

一些運行在虛機里面的網(wǎng)絡吞吐密集型的應用，比如交換機、防火墻、負載均衡等需要網(wǎng)絡

10性能相對物理機不能下降太多：甚至要求無損耗，則需要采取一些優(yōu)化措施，比如賓客

操作系統(tǒng)繞過宿主操作系統(tǒng)，甚至是hypervisor,直接與網(wǎng)卡(HBA或以太網(wǎng)卡)通信，Intel

的DPDK技術就是這種優(yōu)化方式的代表，國內(nèi)漢柏安全操作系統(tǒng)ISOS也采用了類似的優(yōu)

化思路。

通常云應用程序更新都比較快，但底層的操作系統(tǒng)千差萬別，就windows操作系統(tǒng)版本差

異也較大，給云應用程序開發(fā)帶來不小的負擔，于是就出現(xiàn)一種訴求，希望能夠有一個軟件

層屏蔽底層操作系統(tǒng)的差異，這樣應用程序開發(fā)不考慮底層操作系統(tǒng)差異，大大簡化和加快

了云應用程序的開發(fā)和上線。Java虛擬機JVM是一個不錯的選擇，但JVM由于在賓客操

作系統(tǒng)上又加了一層封裝，所以應用運行性能再次下降，在一些對性能要求較高的場景下，

JVM就無法適應。最近的“容器'：技術又開始受到關注，并得到逐步的認可。

容器的基本思想是給應用程序提供基本運行環(huán)境，這個環(huán)境不是一個完整的操作系統(tǒng)，而是

一個父進程，應用程序當做它的子進程運行。Docker.GoogleAppEngine(GAE)都是應

用容器實現(xiàn)的代表。所以容器在一定程度上可以看做是一個輕量級的應用操作系統(tǒng)。

4.2云操作系統(tǒng)與云角色

美國國家標準與技術研究院NIST制定的《云計算參考架構(gòu)》將云角色分為云消費者(Cloud

Consumer)、云審計者(CloudAuditor)、云服務提供商(CloudProvider)、云管道提

供商(CloudCarrier)和云經(jīng)紀商(CloudBroker)等角色⑴。

本文設計的云操作系統(tǒng)定位在云服務提供商提供云服務的操作系統(tǒng)，功能覆蓋云計算參考模

型中的ServiceLayer、ResourceAbstractionandControlLayer和CloudService

Management11^

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

云操作系統(tǒng)

CloudOS

CloudProvider

Cloud

ServiceOrchestrationBroker

CloudService

Management

Service

IntermediationI

Business

Support

Service

Aggregation)

ResourceAbstractionandProvisioning/

ControlLayer

ConfigurationService

Arbitrage

PhysicalResourceLayer

Portability/

Interoperability

z

CloudCarrier

圖云操作系統(tǒng)在云計算參考模型中的位置

云操作系統(tǒng)直接或間接的與其他幾個云角色都有交互。

云操作系統(tǒng)不像計算機操作系統(tǒng)大多運行在單臺個人電腦或服務器上面，而是運行在大規(guī)模

的服務器、網(wǎng)絡設備、存儲設備、安全設備等硬件基礎設施之上，云服務消費者主要有個人

用戶、程序員、企業(yè)用戶、第三方應用程序等。

4.3體系結(jié)構(gòu)

本文設計的云操作系統(tǒng)不僅實現(xiàn)通用云操作系統(tǒng)的基本需求，還需要做到安全可控，所以在

進行體系結(jié)構(gòu)設計的時候必須將此要求考慮進入。

431總體設計

為了更好的設計適用于云計算的操作系統(tǒng)，我們先簡單的回顧一下計算機操作系統(tǒng)的體系結(jié)

構(gòu)。計算機操作系統(tǒng)體系結(jié)構(gòu)大致有簡單結(jié)構(gòu)、單體內(nèi)核結(jié)構(gòu)、層次式結(jié)構(gòu)、微內(nèi)核結(jié)構(gòu)、

外核結(jié)構(gòu)等⑶。層次式結(jié)構(gòu)減少了各模塊之間的緊密依賴、相互調(diào)用的關系，特別是消除循

環(huán)調(diào)用現(xiàn)象，實現(xiàn)有序調(diào)用。微內(nèi)核結(jié)構(gòu)的思想是盡可能減少操作系統(tǒng)的組件，只是留下必

須的組件以內(nèi)核態(tài)運行，確保核心基礎的高穩(wěn)定性。

所以，我們參考計算機操作系統(tǒng)的層次式和微內(nèi)核結(jié)構(gòu)，將云操作系統(tǒng)的核心組件以微內(nèi)核

的方式設計（微內(nèi)核設計借鑒計算機微內(nèi)核操作系統(tǒng)在系統(tǒng)健壯性方面設計理念，單并不代

表一定運行在內(nèi)核態(tài)），擴展組件放在微內(nèi)核之外。擴展組件與核心組件之間、擴展組件之

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

間采用半序?qū)哟谓Y(jié)構(gòu)。

下圖是云操作系統(tǒng)的休系結(jié)構(gòu):

合作伙食程序開發(fā)由

公操作系統(tǒng)

交忖Delivery

laaSPaaSSaaSSecaaS

虛機、桌面交付API、容器交付應用交付安全交付

控制Controller

計算資源控制網(wǎng)絡資源控制存儲資源控制安全資源控制

做內(nèi)核Microkernel

計算虛擬化網(wǎng)絡虛擬化存砧虛擬化安全虛擬化

本文設計的云操作系統(tǒng)底層硬件只支持X86服務器，以太網(wǎng)交換機，以太網(wǎng)絡共享存儲與

分布式存儲，以太網(wǎng)絡防火墻。

微內(nèi)核Microkernel是整個云操作系統(tǒng)的最小可運行單元,對外以各種接口提供支撐和服務,

即使外部組件出現(xiàn)問題，也不會影響到微內(nèi)核的運行。

控制Controller組件負責云操作系統(tǒng)各種資源池管理和運行控制，比如資源池的分配、調(diào)度

等，其并行計算和分布式計算是此組件的重要要素。

交付Delivery組件負責利用控制組件提供的資源管理接口，按照云消費者的要求以服務形

式提供，比如基礎設施即服務laaS等。

管理Management組件負責云的所有層面的管理，包括云基礎設施運維管理、云服務支撐

系統(tǒng)管理、云服務界面等。

安全Security組件確保云操作系統(tǒng)可控、可靠、可信及安全。

各個組件可以單獨部署，每個組件內(nèi)部會有大量的服務進程，每個服務進程至少有三個實例

以分布式方式運行，防止服務進程的單點故障。

4.3.2運行部署

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

本文設計的云操作系統(tǒng)由一群相對獨立的服務進程通過邏輯處理構(gòu)成的，這些服務進程按照

作用功能劃分為微內(nèi)核、控制、交付、管理和安全五個組件。每個服務進程至少運行三個實

例，所以理論上每個服務進程都可以任意運行在數(shù)據(jù)中心的節(jié)點上，服務進程之間通過網(wǎng)絡

或計算機內(nèi)部總線通信。不過為了減少復雜度，最好按照組件為大類來部署運行。

建議運行部署參照下面兩種，圖模式有管理控制集中的思維，將控制、交付、管理、安全

組件的服務集中部署，為了避免單節(jié)點故障，建議集群部署，至少三臺物理節(jié)點。

閨ntEj

x86取務潛

X86服務器X86服務器交換機防火墻磁盤陣列

圖運行部署模式1

圖以完全分布式的方式部署,以B/S或C/S方式訪問云操作系統(tǒng)。

瀏覽器或客戶桀

冉口10

X86服務器X86服務器x86服務器x86服務潺x86服務揩X86服務器

圖運行部署模式2

這兩種部署方式都涉及到對傳統(tǒng)交換機、防火墻的管理控制。將云操作系統(tǒng)的組件部署到傳

統(tǒng)交換機或防火墻系統(tǒng)上是不現(xiàn)實的，除非要求交換機或防火墻軟件系統(tǒng)做改造。所以在設

計云操作系統(tǒng)的時候需要考慮如何兼容傳統(tǒng)硬件交換機、硬件防火墻，甚至硬件存儲設備。

4.3.3組件通信

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］4^]

OpenStack為了減少組件之間耦合度，同時能夠高效的交互通信，專門設計了Message

Queue蛆件，實現(xiàn)方式有多種，比如RabbitMQ、Qpid、ZeroMQ等。

本文設計的云操作系統(tǒng)針對組件之間通信，借鑒消息環(huán)的設計理念，所有需要通信的組件或

服務進程向消息環(huán)MR(MessageRing)注冊成為一個站點(Station),如下圖所示:

圖組件通信消息環(huán)MR

Station管理

圖MR管理

MRController負責各個Station之間通信擁塞控制、狀態(tài)監(jiān)控等。Station負責消息的發(fā)送

和接收處理。

通信方式

Station是組件向MR注冊的組件標識，是通信雙方的地址。

Station之間通信是雙向的，每個Station會擁有兩個隊列，一個接收隊列，一個發(fā)送隊列。為了

實現(xiàn)擁塞控制，發(fā)送隊列分配一定憑證Credit,當Credit使用完畢后就k能再發(fā)送消息。

由于注冊到MR的組件內(nèi)部可能還會有更小的模塊，更小模塊或程序服務之間也可能需要通信,

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

所以在接收隊列里面又設置了256個令牌桶Bucket,一個或多個Bucket分配給更小模塊使用。

在組件注冊的時候設置.

StaHon之間通信通道可能共享內(nèi)存（比如多個station在同一臺物理節(jié)點上運行），也可能是以

太網(wǎng)（比如多個station運行在不同的物理節(jié)點上）。

其處理邏輯如下圖所示：

MRController

圖Station通信

擁塞控制

MR通道的帶寬總是有限，為了避免擁塞，MR通道帶寬會在系統(tǒng)初始化階段按照預先設定好的

策略分配給各個Station,各個Station自動管理分配給自己的帶寬。

消息流量控制基于憑證credit,Stalion必須擁有足夠的credit才能夠發(fā)送消息。每個Station都

會針對每個目的bucket維護一定量的credito

在每個Station中都有一個發(fā)送憑證credit管理器，負責管理屬于每個目的bucket的credito整

個MR會有固定數(shù)量的bucket,每個Station會維護相同數(shù)量的credit計算器，其決定該Station

是否擁有足夠的credit可以發(fā)送消息。每個消息對應一個credit。當發(fā)送消息的時候，credit管

理器會檢查credit個數(shù)是否大于待發(fā)送的消息個數(shù)，如果大于，則可以發(fā)送，否則會繼續(xù)重試,

直到有足夠credit時。

當發(fā)送成功，目的Station并成功接收到消息后，目的Station需要將相同數(shù)目的credit還給源

Station<,

4.3.4微內(nèi)核

微內(nèi)核是云操作系統(tǒng)的最小運行單元，主要有四個組件，如下圖所示:

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］------------------------------------------------

微內(nèi)核Microkernel

廣―卜，—「丁―

圖微內(nèi)核結(jié)構(gòu)

計算虛擬化負責計算所涉及的CPU、內(nèi)存、I/O等資源的分割、調(diào)度、管理等，以對外提供

計算資源池。

網(wǎng)絡虛擬化負責網(wǎng)絡所涉及的網(wǎng)絡I/。、網(wǎng)絡帶寬、網(wǎng)絡功能、網(wǎng)絡延遲等資源的分割、調(diào)

度、管理等，以對外提供網(wǎng)絡資源池。

存儲虛擬化負責存儲所涉及的存儲I/O、存儲塊設備、存儲對象、存儲文件等資源的分割、

調(diào)度、管理等，以對外提供存儲資源池。

安全虛擬化負責信息安全所涉及的安全策略、安全防護功能等澆源的分割、調(diào)度、管理等，

以對外提供安全資源池。

每個組件都會提供API,供其他組件使用。處于安全性考慮，這些API都會有調(diào)用認證、授

權和審計的設計。

4.3.4.1計算虛擬化

前期計算虛擬化后提供的主要是虛擬計算機，簡稱虛機（VM）,當前容器成為另外一種發(fā)

展比較快的虛擬技術。

1.虛機

計算虛擬化當前技術發(fā)展比較成熟，開源系統(tǒng)主要有XEN和KVM,商業(yè)系統(tǒng)主要有vmware

的vSphere、Microsoft的Hyper-Vo

開源的XEN和KVM開源，經(jīng)過多年的發(fā)展和完善，實踐證明已經(jīng)比較穩(wěn)定。本文設計的

云操作系統(tǒng)必須安全、可控，如果直接采用KVM或XEN會存在諸多安全性風險，但如果

重新開發(fā)也沒有太多的必要，所以我們采用“加固”思路來設計計算虛擬化：

1）采用硬件輔助的完全虛擬化模型，當前只是支持Intel和AMD公司的x86指令體系

2）計算虛擬化涉及的CPU、內(nèi)存、設備虛擬化直接使用KVM已有的代碼

3）屏蔽KVM原始對外的所有API,重新封裝計算虛擬化對外提供的API,稱之為s-API,

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］4^

同時最小化API集，即只是對外提供必要的S-API

4)S-API是KVM被動對外提供的API,為了防范KVM主動向外提供“接口”，比如利用

某些不可知的硬件組件或特性主動向外發(fā)送信息，主動或被動觸發(fā)向外發(fā)送加密信息等，設

計一個“安全監(jiān)控”模塊，一旦發(fā)現(xiàn)除了S-API交互通道之外的信息傳輸，則立即阻斷并報

警

5)qemu-kvm是KVM為了提供完整的虛擬化而基于標準QEMU,紜合KVM特點做的針

對性改進的一個用戶態(tài)組件。所以我們可以參考qemu-kvm,自主開發(fā)類似的功能模塊

s-qemu-kvm,做到虛機運行行為的完全可控。

下圖是本文設計的云操作系統(tǒng)計算虛擬化的邏輯結(jié)構(gòu)：

VMVM_VM

virtiovirtiovirtio

frontenddriverfrontenddriverfrontenddriver

hypervisor

Hardware(VT-x)Hardware(SVM)

圖計算虛擬化邏輯結(jié)構(gòu)

KVM運行機制請閱讀附錄KVM運行原理章節(jié)，這里重點介紹自主開發(fā)的S-API、安全監(jiān)控

和s-qemu-kvm三個模塊的設計思路。

KVM的框架如下圖：

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

VMVM

virtio

frontenddri^rfrontenddriver

hypervisor

LinuxkernelwithKVM

Hardware(VT-x)Hardware(SVM)

圖KVM邏輯框架

對比上圖可知，本設計用s-API替換/dev/kvm以及KVM處理有關I/O請求處理接口，用

s-qemu-kvm替換標準的qemu-kvm,同時在linux內(nèi)核增加“安全監(jiān)控”模塊。

s-API

s-API設計的目的有三個：

?屏蔽原來KVM對外提供的所有接口

?加固KVM對外提供的必要接口

?更緊密與安全地與s-qemu-kvm組件進行適配與融合

KVM對用戶態(tài)暴漏一個字符文件；dev/kvm,qemu-kvm通過操作文件和ioctl方式與KVM

交互，KVM不提供針對/dev/kvm的read和write接口，只提供文件wen和close的接口,

其他的都是通過ioctl接口交自。

s-API為了加固接口，提高安全性，封裝單獨的ioctl接口，在封裝ioctl接口中確保按照既

定的定義執(zhí)行相應的操作。

s-API需要針對下面三類操作做封裝：

?system指令，針對虛擬化系統(tǒng)的全局性參數(shù)設置和控制

KVM_CREATE_VM倉ij建KVM虛擬機

KVM_GET_API_VERSION查詢當前KVMAPI版本

KVM_GET_MSR_INDEX_LIST獲得MSR索弓|列表

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］---------------------------------------------------

KVM_CHECK_EXTENSION檢查擴展支持情況

KVM_GET_VCPU_MMAP_SIZE運行虛擬機和用戶態(tài)空間共享的一片內(nèi)存區(qū)域的大小

?VM指令，針對VM虛擬機進行控制，如：內(nèi)存設置、創(chuàng)建VCPU等

KVM_CREATE_VCPU為虛擬機倉U建VCPU

KVM_RUN根據(jù)kvmjun結(jié)構(gòu)體信息，運行VM虛擬機

KVM_CREATE_IRQCHIP創(chuàng)建虛擬APIC,且隨后創(chuàng)建的VCPU都關聯(lián)到此APIC

KVM」RQ_LINE對某虛擬APIC發(fā)出中斷信號

KVM_GET_IRQCHIP讀取APIC的中斷標志信息

KVM_SET_IRQCHIP寫入APIC的中斷標志信息

KVM_GET_DIRTY_LOG返回臟內(nèi)存頁的位圖

?VCPU指令，針對具體的VCPU進行參數(shù)設置。如：相關寄存器的讀寫、中斷控制等

寄存器控制相關，包括：

KVM_GET_REGS獲取通用寄存器信息

KVM_SET_REGS設置通用寄存器信息

KVM_GET_SREGS獲取特殊寄存器信息

KVM_SET_SREGS設置特殊寄存器信息

KVM_GET_MSRS獲取MSR寄存器信息

KVMSETMSRS設置MSR寄存器信息

KVMGETFPU獲取浮點寄存器信息

KVM_SET_FPU設置浮點寄存器信息

KVM_GET_XSAVE獲取VCBU的xsavc奇存器信息

KVM_SET_XSAVE設置VCPU的xsave寄存器信息

KVM_GET_XCRS獲取VCPU的xcr寄存器信息

KVM_SET_XCRS設置VCPU的xcr寄存器信息

中斷和事件管理相關，包括：

KVM_INTERRUPT在VCPU上產(chǎn)生中斷（當APTC無效時）

KVM_SET_SIGNAL_MASK設置某個VCPU的中斷信號屏蔽掩碼

KVM_GET_CPU_EVENTS獲取VCPU中被掛起待延時處理的事件，如中斷、NMI或異常

4-

［完仝自主可控云操作系統(tǒng)可行性分析與段計］---------------------------------------------------

KVM_SET_CPU_EVENTS設置VCPU的事件，如中斷、NMI或異常

內(nèi)存管理相關，包括：

KVM_TRANSLATE將VCPU的物理地址翻譯成HPA

KVM_SET_USER_MEMORY_REGION修改VCPI；的內(nèi)存區(qū)域

KVMSETTSSADDR初始化TSS內(nèi)存區(qū)域（Intel架構(gòu)專用）

KVM_SET_IDENTITY_MAPADDR創(chuàng)建EPT頁表（Intel架構(gòu)專用）

其他，包括CPUID的設置、調(diào)試接口等。

凡是在s-qemu-kvm與內(nèi)核KVM模塊之間發(fā)生的I/。請求與反饋都需要經(jīng)過s-API提供的

I/O處理接口。

安全監(jiān)控

安全監(jiān)控主要是防止KVM主動向外發(fā)起的不安全通信，其設計框架圖如下：

圖安全監(jiān)控邏輯結(jié)構(gòu)

從設計上說，安全監(jiān)控模塊不僅僅是針對KVM的監(jiān)控，也會針對Linux內(nèi)核的其他模塊進

行外發(fā)通信的監(jiān)控，畢竟Linux宿主操作系統(tǒng)也存在較大的不安全性，

當然開啟安全監(jiān)控，會影響系統(tǒng)的性能，可以考慮在緊急時刻開啟此功能。

s-qemu-kvm

由于虛機運行的行為控制完全在qemu-kvm,所以qemu-kvm必須重新設計和開發(fā)。

s-qemu-kvm的主體框架與qemwkvm相同，只是代碼重新，南向與KVM交互的接口需要

替換成s-API的相應接口，北向與虛機交互仍然用標準的virtio接口，以兼容客戶機virti。

前端驅(qū)動程序。

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

2.容器

下圖是開源LXC項目提供的基于Linux的容器解決方案:

容器1容器2容器3

容器4容器n

VMM

Linuxkernelwithnamespaceandcgroup

Hardware(VT-x)Hardware(SVM)

圖LXC容器

下圖是我們經(jīng)過加固和重構(gòu)后的容器解決方案:

Hardware(VT-x)Hardware(SVM)

圖加固與重構(gòu)的容器

Namespace是Linux內(nèi)核原生支持，我們沒有必要去修改，cgroup是內(nèi)核針對一組進程的

資源進行控制，比如進程所使用的CPU、內(nèi)存等資源，從代碼的角度看，cgroup就是對多

個task_struct數(shù)據(jù)結(jié)構(gòu)的管理。正是cgroup對進程資源進行控制，所以從安全可控的角度

來看，必須針對cgroup做重構(gòu)，以確保資源使用方面絕對可控。

Lxc是用戶態(tài)的一個容器管理工具，同樣也涉及到資源使用控制，也必須自主開發(fā)與重構(gòu)。

4-

［完仝自主可控云操作系統(tǒng)可行性分析與i殳計］

網(wǎng)絡虛擬化

網(wǎng)絡虛擬化主要包括網(wǎng)絡I/O虛擬化、網(wǎng)絡轉(zhuǎn)發(fā)路徑虛擬化、網(wǎng)絡帶寬虛擬化和網(wǎng)絡功能虛

擬化。隨著云技術和云服務需求的發(fā)展，還可能要求網(wǎng)絡轉(zhuǎn)發(fā)延遲等網(wǎng)絡屬性也要做到虛擬

化，本設計暫不涉及這部分。

網(wǎng)絡虛擬化

網(wǎng)絡I/O虛擬化■網(wǎng)絡轉(zhuǎn)發(fā)路徑虛擬化■網(wǎng)絡帶寬虛擬化I網(wǎng)絡功能虛擬化I網(wǎng)絡其他屬性虛擬化

x86服務器以太網(wǎng)交換機

圖網(wǎng)絡虛擬化

網(wǎng)絡I/O虛擬化

網(wǎng)絡I/O虛擬化包括10速率、10帶寬、10協(xié)商等虛擬化,這些屬性都屬于網(wǎng)絡接口（網(wǎng)卡），

所以如果將網(wǎng)卡虛擬化后，相關屬性也就做到了虛擬化，但虛擬化的‘顆粒度“不夠細，不

過在絕大多數(shù)情況下已經(jīng)足夠。所以這里設計的網(wǎng)絡I/。虛擬化采用網(wǎng)卡虛擬化的方式。

網(wǎng)卡虛擬化不但X86計算服務器需要，以太網(wǎng)交換機也可能需要，主要是看云操作系統(tǒng)采

用何種技術實現(xiàn)“軟件定義網(wǎng)絡”，這里主要說明X86