大家好，我是徐安，一位虛擬化老兵。2010年開始在世紀(jì)互聯(lián)（云快線）接觸云計算和虛擬化技術(shù)，應(yīng)該算是國內(nèi)較早的一批人吧。目前在漢柏科技有限公司，負(fù)責(zé)服務(wù)器虛擬化以及桌面虛擬化產(chǎn)品的技術(shù)工作。

我將從虛擬化的主流技術(shù)介紹，前沿技術(shù)介紹，Docker技術(shù)介紹，MixSAN技術(shù)介紹四個方面展開今天的分享。由于筆者水平和知識所限，難免有理解不正確的地方，請各位大牛批評指正。

首先讓我們看看主流虛擬化技術(shù)有哪些，無非就是CPU虛擬化，內(nèi)存虛擬化，網(wǎng)卡虛擬化，磁盤虛擬化。

KVM是目前最主流的虛擬化技術(shù)，自Linux 2.6.20之后集成在各主要Linux發(fā)行版本中。KVM分為四個模式，分別是客戶（虛擬機(jī)）用戶模式，客戶（虛擬機(jī)）內(nèi)核模式，Host Linux用戶模式，Host Linux內(nèi)核模式。虛擬機(jī)的用戶模式和內(nèi)核模式與虛擬化之前的操作系統(tǒng)對應(yīng)，沒有什么好解釋的。Qemu-kvm是一個Host Linux用戶態(tài)程序，就是一個進(jìn)程，代表著一個虛擬機(jī)。Qemu-kvm主要負(fù)責(zé)為虛擬機(jī)模擬硬件，Qemu-kvm通過ioctl控制KVM內(nèi)核模塊。

一個虛擬機(jī)就是一個進(jìn)程，那一個vCPU就是一個線程，它被Main線程創(chuàng)建。這么設(shè)計的好處是無需單獨設(shè)計vCPU的調(diào)度算法了，就用Linux的線程調(diào)度即可。所以，對于一個vCPU來說，它就是拼了老命runing，看圖可以見到兩個while循環(huán)，第二個while就是讓KVM內(nèi)核運行該vCPU的上下文，一旦KVM內(nèi)核運行不下去了，就看看是什么原因，qemu-kvm根據(jù)原因執(zhí)行下一步動作，比如需要讀寫磁盤了，那就用qemu-kvm去打開該磁盤對應(yīng)的文件，執(zhí)行read，write操作。

整個虛擬機(jī)的虛擬地址到實際物理內(nèi)存地址的訪問（轉(zhuǎn)換）過程為：GVA（虛擬機(jī)虛擬地址），通過VM頁表轉(zhuǎn)換為GPA（虛擬機(jī)物理地址），然后通過一個數(shù)據(jù)結(jié)構(gòu)映射為HVA（物理機(jī)虛擬地址），再通過Host頁表，轉(zhuǎn)換為HPA（物理機(jī)物理地址）。

從上頁可以看出，這么轉(zhuǎn)換太慢了，需要加速。有兩個辦法來加速上一頁的翻譯過程。1）影子頁表，2）EPT功能。那KVM使用哪個呢？如CPU支持EPT功能，那就走EPT。

EPT是利用硬件自動翻譯GPA到HPA的地址映射：在構(gòu)建VM的頁表時，EPT硬件把翻譯好的HPA地址反饋給VM頁表，VM直接使用物理地址。

利用軟件“欺騙VM”直接構(gòu)建GVA到HPA的頁表，VM還正常走頁表翻譯的流程，當(dāng)需要加載頁表的物理內(nèi)存時，KVM接管起來，然后把頁表里的內(nèi)容直接替換成真實的HPA地址即可。

左邊是普通網(wǎng)卡的虛擬化，首先qemu-kvm會模擬”E1000″的物理網(wǎng)卡，Guest OS通過模擬的中斷和DMA操作與E1000交互，E1000在Qemu-kvm內(nèi)用內(nèi)部調(diào)用把這些請求轉(zhuǎn)發(fā)到”tap代理”上，tap代理實際是open的Host OS的一個tap設(shè)備，所以收發(fā)包的流程就轉(zhuǎn)換為針對tap設(shè)備的read，write操作。tap設(shè)備連接在bridge上，再通過TCP/IP協(xié)議?；騜ridge上的物理網(wǎng)卡把網(wǎng)絡(luò)包收發(fā)起來。

右邊是virtio網(wǎng)卡，與普通網(wǎng)卡不同的地方在DMA模擬操作變成了內(nèi)存共享。

這是具體的函數(shù)調(diào)用過程，強(qiáng)調(diào)一下：tap的操作都會經(jīng)過Qemu-kvm進(jìn)程的poll處理。左邊的是收包過程，右邊的是發(fā)包過程。

這是virtio-net收發(fā)包的調(diào)用流程。

vrio-blk與網(wǎng)卡虛擬化類似，首先模擬一個硬件設(shè)備，對硬件設(shè)備的讀寫操作都轉(zhuǎn)換為磁盤代理的讀寫操作。這個磁盤代理可能是一個文件，一個塊設(shè)備，一個網(wǎng)絡(luò)設(shè)備，或者僅僅是一個模擬。

有興趣的可以私下討論，時間關(guān)系先過。

這個講起來有點復(fù)雜，總之可設(shè)定虛擬機(jī)某個磁盤的緩沖策略，write-back，none，write-thru。實際上就是qemu-kvm打開文件的類型不同。write-back的意思是數(shù)據(jù)寫入page cache中就不管了，none的話會寫入buffer cache（設(shè)備緩沖中），write-thru那么設(shè)備緩沖也要跨過，直接寫入設(shè)備中。

所謂前沿技術(shù)，只是個人的認(rèn)識，不一定正確，請批評指正。

所謂的FT技術(shù)就是建立兩個VM，一主一備。隔一段時間主VM暫停下，做一個checkpoint，然后恢復(fù)VM，在下一次checkpoint點之前，把上兩次checkpoint之間的差異（CPU，內(nèi)存）數(shù)據(jù)傳遞給備份VM，備份VM同步更新這些差異數(shù)據(jù)。

這里的困難點就是checkpoint之間的時間間距盡量短，如果這段時間內(nèi)存數(shù)據(jù)變化比較大，那傳輸?shù)臄?shù)據(jù)流就會巨大，那對主備之間的網(wǎng)絡(luò)帶寬壓力就會比較大。

三級緩沖是這樣的，以Widows系統(tǒng)舉例，把C盤的母盤放在內(nèi)存中，C盤的link clone出來的子盤放在SSD中，D盤放入機(jī)械硬盤中。這樣的VM啟動速度，我們測試的結(jié)果是60個桌面，90秒內(nèi)可啟動完。

預(yù)讀機(jī)制是指，虛擬機(jī)讓我讀取1k的數(shù)據(jù)，我自動幫你讀1M的數(shù)據(jù)讓在內(nèi)存中。

如果還嫌VM啟動太慢了，那還有辦法，我們看一個虛擬機(jī)啟動的過程無非是這樣的：CPU轉(zhuǎn)起來，讀取Disk里的數(shù)據(jù)放入內(nèi)存中。那啟動多個一模一樣虛擬機(jī)的時候能不能不走這個流程呢，直接把內(nèi)存和CPU的數(shù)據(jù)從虛擬機(jī)A拷貝到虛擬機(jī)B，那理論上虛擬機(jī)B的啟動速度等于內(nèi)存對拷的時間。還可以再加速，如果虛擬機(jī)基本差不多，有些內(nèi)存數(shù)據(jù)根本不會變化，那內(nèi)存拷貝的時候能不能只是做一個link鏈接，當(dāng)子內(nèi)存某一塊有變化時，再從母內(nèi)存中copy on write即可。

網(wǎng)卡性能加速第一方向是使用vhost-net，網(wǎng)絡(luò)數(shù)據(jù)包轉(zhuǎn)發(fā)可拋掉qemu-kvm，直接走到vhost設(shè)備，在內(nèi)核中轉(zhuǎn)發(fā)到tap設(shè)備，然后走h(yuǎn)ost內(nèi)核的bridge走出去。說的直白點，在創(chuàng)建VM時，給qemu-kvm的網(wǎng)卡設(shè)備文件是vhost的。DPDK可加速交換模塊OVS的轉(zhuǎn)發(fā)效率，這部分我們還沒有深入研究，就一筆帶過了。

針對KVM的vGPU方案還比較少，時間關(guān)系，也一筆帶過了。

關(guān)于Docker，我們也是剛剛開始研究，算是學(xué)習(xí)筆記吧。有說的不對的地方，請各位大牛批評指正。

左邊是常用的對比圖，可以明顯看出Docker少了Guest OS Kernel這一層，所以它的密度更高，啟動速度更快。但用戶使用Docker和虛擬機(jī)，不會直接使用命令，一般是使用一個系統(tǒng)。所以，正確的對比辦法是對比它們的系統(tǒng)。右邊是從這么幾個方面我認(rèn)識到的對比?？梢悦黠@看出，Docker在啟動速度，密度，更新管理上占有比較大的優(yōu)勢，其他方面，比如對Windows的支持行，穩(wěn)定性，安全性，監(jiān)控成熟度，高可用性，管理平臺成熟度上來看，都低于虛擬化技術(shù)。當(dāng)然，再次強(qiáng)調(diào)這個是我個人的認(rèn)識，不一定正確。歡迎批評指正。

可以看出，這是個群雄涿鹿的時代，主要有OpenStack、Mesos、Kubernetes、Docker公司（社區(qū)）四個玩家。它們爭奪的當(dāng)然是云時代，開源平臺的份額，也就是云時代的控制權(quán)。

筆者一直認(rèn)為，云消費者并不關(guān)心，你這個服務(wù)商使用的是虛擬化技術(shù)還是Docker，更不關(guān)心你自己寫的還是基于開源平臺改的。他關(guān)心的是你的服務(wù)是否可靠，是否穩(wěn)定，是否便宜，是否安全。所以，根據(jù)你團(tuán)隊的特點，選擇你們自己最擅長的技術(shù)，為云消費者提供有競爭力的服務(wù)，才是未來我們能否立足的核心。

筆者認(rèn)為融合了Docker與虛擬化的云平臺應(yīng)該包括三個層次：資源管理層，虛擬化層，服務(wù)層。當(dāng)然docker與虛擬化會共用大部分模塊，這也是筆者認(rèn)為要構(gòu)筑融合平臺的好處。資源管理層至少包括：計算資源管理，存儲資源管理，網(wǎng)絡(luò)管理，安全管理。虛擬化層肯定包括：虛擬化引擎（一般情況下就是KVM），容器引擎（一般情況下就是Docker）。服務(wù)層至少包括：高可用性，編排管理，容災(zāi)備份，服務(wù)發(fā)現(xiàn)，應(yīng)用發(fā)布，應(yīng)用升級，自感擴(kuò)容，編排管理，平臺高可用性，生命周期管理，用戶權(quán)限認(rèn)證，監(jiān)控報警，日志審計，負(fù)載均衡，鏡像管理，系統(tǒng)維護(hù)等模塊。

Kubernetes的優(yōu)勢在于它是第一個Docker集群管理平臺，第一個提出并實現(xiàn)了Pod，Replication，Services Discovery等概念。關(guān)于技術(shù)細(xì)節(jié)，筆者在此不做過多介紹，請自行百度，Google，或者自己搭建平臺體驗。下面的其他方案也相同。

Swarm是Docker在2014年12月份新發(fā)布的Docker集群管理工具。Swarm可管理Docker集群，管理和分配計算資源，也包含服務(wù)發(fā)現(xiàn)（可以選用etcd、ZooKeeper、Consul），容器編排等功能。Swarm的優(yōu)勢是與Docker接口API統(tǒng)一。

Mesos的目標(biāo)是下一代數(shù)據(jù)中心操作系統(tǒng)（DCOS），其最核心功能在于集群管理，計算資源管理，任務(wù)分發(fā)，原本用作Hadoop等分布式任務(wù)管理。從0.20版開始，Mesos支持Docker形式的任務(wù)調(diào)度（主要看中Docker的任務(wù)隔離，資源限制，隨鏡像發(fā)布）。在Mesos之上，Marathon可以用作為Docker編排和生命周期管理。

為保證云計算領(lǐng)域的領(lǐng)先地位，2015年5月份溫哥華峰會上，OpenStack提出了“集成引擎”的思路。其實說白了就是在Kubernetes、Swarm和Mesos的上面套一層，用OpenStack Magnum的接口來管理它們。OpenStack的優(yōu)勢在于在虛擬化上積累的多租戶，編排，存儲以及網(wǎng)絡(luò)能力。筆者認(rèn)為這個方案有點另類，OpenStack不會甘心僅僅做個”集成商”的。筆者大膽猜測，憑借強(qiáng)大的內(nèi)生能力，OpenStack Magnum一定會慢慢學(xué)習(xí)和消化Kubernetes、Swarm和Mesos的優(yōu)勢，并最終替代它們變成另一個”Nova”，這個”Nova”操作和管理Docker。

對四種方案進(jìn)行全方位的比較，按照0（沒有此項功能），1（有，但不完善），2（有，且比較完善）。結(jié)果是Kubernets稍稍勝出，個人認(rèn)識，不一定正確。

關(guān)于存儲

1. 將Docker的rootfs以及Volume跑在Ceph集群中。據(jù)說Docker社區(qū)即將實現(xiàn)Ceph RBD Graph Driver。

2. Ceph模塊Docker化，與Docker節(jié)點統(tǒng)一起來，實現(xiàn)超融合理念。

關(guān)于網(wǎng)絡(luò)

1. 與虛擬化一體實現(xiàn)DHCP，實際IP分配通過Docker 1.9以上的–ip參數(shù)設(shè)定。

2. 利用OVS實現(xiàn)Docker與VM互聯(lián)互通。

服務(wù)發(fā)現(xiàn)可以讓一個應(yīng)用或者組件發(fā)現(xiàn)其運行環(huán)境以及其它應(yīng)用或組件的信息。當(dāng)一個服務(wù)啟動時，注冊自身信息，例如，一個MySQL數(shù)據(jù)庫服務(wù)會在這注冊它運行的ip和端口。負(fù)載均衡的策略可根據(jù)負(fù)載在Ngnix和DNS上體現(xiàn)，不如發(fā)現(xiàn)某個負(fù)載太高，就Ngnix或者DNS到另外的Docker Server上。

1. 靜態(tài)遷移&Docker HA：Ceph共享存儲 + IP設(shè)定 == 可實現(xiàn)Docker遷移功能。

2. 動態(tài)遷移： 熱遷移CRIU（凍結(jié)進(jìn)程 –> 保存在存儲上 –> 讀取并恢復(fù)出來）。 

一個Set跑一個業(yè)務(wù)，由多個Docker組成，支持灰度升級，如果監(jiān)控到負(fù)載太高，也可在Set內(nèi)增加Docker數(shù)量。

這里說的MixSAN就是Ceph。

Ceph是一種為優(yōu)秀的性能、可靠性和可擴(kuò)展性而設(shè)計的統(tǒng)一的（同時提供對象存儲、塊存儲和文件系統(tǒng)存儲三種功能）、分布式的存儲系統(tǒng)（高可靠性；高度自動化；高可擴(kuò)展性）。

RADOS的系統(tǒng)邏輯結(jié)構(gòu)如右圖所示：

1. OSD和monitor之間相互傳輸節(jié)點狀態(tài)信息，共同得出系統(tǒng)的cluster map。

2. 客戶端程序通過與OSD或者monitor的交互獲取cluster map，然后直接在本地進(jìn)行計算，得出對象的存儲位置后，便直接與對應(yīng)的OSD通信，完成數(shù)據(jù)的各種操作。

pool，rbd卷，pg，osd之間的關(guān)系如圖所示。在Pool內(nèi)建立rbd卷，按照4M分為許多object，一個object對應(yīng)一個pg，一個pg分發(fā)到不同的osd上把數(shù)據(jù)存儲起來，一般就是存儲在一個文件中。

左圖可以明顯看出，一次寫會寫三次，所以有寫放大的問題。

讀的話分為幾種算法，一種是只去找primary，一種是在三個osd上隨機(jī)找一個去讀，另一個是盡可能靠近自己去讀。

這種情況我們在萬兆情況下，測試出來的性能等同于萬兆iSCSI存儲性能。

這么做的好處：冷熱數(shù)據(jù)分離，用相對快速/昂貴的存儲設(shè)備如SSD盤，組成一個Pool來作為Cache層，后端用相對慢速/廉價的設(shè)備來組建冷數(shù)據(jù)存儲池。

tier Cache策略有兩種模式：

1. Write-back模式 Ceph客戶端直接往cache-pool里寫數(shù)據(jù)，寫完立即返回，Tiering Agent再及時把數(shù)據(jù)flush到base-pool。當(dāng)客戶端要讀的數(shù)據(jù)不在cache-pool時，Tiering Agent負(fù)責(zé)把數(shù)據(jù)從base-pool遷移到cache-pool。

2. read-only模式 Ceph客戶端在寫操作時往base-pool上直接寫。讀數(shù)據(jù)時先從cache-pool上讀取，如果不在則從base-pool上讀取，同時把數(shù)據(jù)緩沖在cache-pool。

我們使用的Cache策略是write-back模式。

我們的虛擬機(jī)在分配時，考慮Ceph的第一個object的primary Node，通過計算，發(fā)現(xiàn)這種方式比不指定情況下的速度提升30%左右。主要是一個object中存儲了qcow2的表頭數(shù)據(jù)。

該圖是osd的狀態(tài)遷移圖，大致看下就會發(fā)現(xiàn)巨復(fù)雜，我們也發(fā)現(xiàn)有很多坑，目前正在填。

Q：虛機(jī)遷移是否有涉及？不論是負(fù)載觸發(fā)還是容災(zāi)觸發(fā)或者業(yè)務(wù)邏輯觸發(fā)。

A：負(fù)載觸發(fā)的有DRS，省電模式?；究紤]是負(fù)載高時往低負(fù)載上遷移，省電模式則正好相反，把虛擬機(jī)集中起來，關(guān)閉那些不需要的虛擬機(jī)。

Q：KVM的Host內(nèi)核參數(shù)開啟IP轉(zhuǎn)發(fā) 作用是啥，如果使用的是橋接網(wǎng)絡(luò)是否一樣需要開啟？

A：一般情況下都是需要開啟的，如果物理機(jī)需要給虛擬機(jī)網(wǎng)絡(luò)通信的話。

Q：容器化取代虛擬化真的只是時間問題嗎？

A：虛擬化技術(shù)源于以CPU為核心的硬件能力溢出，一虛多也綽綽有余。帶來的結(jié)果：1.降低x86硬件平臺的差異性，VM隨便漂移；2.可統(tǒng)一管理池化后的資源，提高管理性和利用效率；3.不同guest os的vm可同時運行在同一個主機(jī)里；4.各層級，各種類軟件近乎零成本往上遷移。

容器的本質(zhì)是Linux上“相對獨立的更好管理的程序運行環(huán)境”。帶來的結(jié)果：1.適當(dāng)降低linux操作系統(tǒng)的差異性；2.統(tǒng)一管理“應(yīng)用”，提高部署與運行的效率；3.“一統(tǒng)天下”的理想極致世界：從庫上下載任何想要的應(yīng)用，快速且高密度的啟動；4.未統(tǒng)一前，應(yīng)用程序往上遷移有一定成本。

所以，短期未來更有可能的是：虛擬化與容器各負(fù)責(zé)自己擅長的部分，由于更容易與現(xiàn)有世界“兼容”，虛擬化占的市場份額可能會更大。長期未來，當(dāng)統(tǒng)一的世界什么都提供時，哪里都可運行時，虛擬化，容器，你，我可能都已不存在。

Q：請問桌面虛擬化有什么痛點，或者難點么？

A：業(yè)務(wù)上的疼點：

技術(shù)上的難點有兩個：

1）終端尤其usb設(shè)備的適配性工作，太磨人了。
2）協(xié)議的分析，研究，以及改進(jìn)。

Q：KVM虛擬化中Linux內(nèi)核的兩個模塊kvm和kvm_intel具體起到什么作用？

A：我有段時間沒有摸具體的代碼了，kvm和kvm_intel組合在一起完成KVM內(nèi)核相關(guān)的工作。

kvm_intel主要是針對Intel硬件的具體實現(xiàn)，比如CPU上下文結(jié)構(gòu)等信息。KVM完成相對上層一些的工作，比如qemu-kvm下發(fā)ioctol指令解析，內(nèi)存虛擬化等工作。

@Container容器技術(shù)大會正在火熱報名中，知名公司的Docker、Kubernetes、Mesos應(yīng)用案例，點擊下圖可查看大會具體內(nèi)容。