摘要：本文并非虛擬化的科普文章，主要將我們在私有云實(shí)踐過程中的一些思想和遇到的問題拿出來跟大家討論分享。我們虛擬化實(shí)踐包含了傳統(tǒng)的基于協(xié)議的以及目前流行的。

這里的虛擬化等于私有云。本文并非虛擬化的科普文章，主要將我們在私有云實(shí)踐過程中的一些思想和遇到的問題拿出來跟大家討論分享。我們虛擬化實(shí)踐包含了傳統(tǒng)的基于libvirt協(xié)議的KVM以及目前流行的docker。

虛擬化的目的各家公司原因應(yīng)該都差不多，一般都是為了實(shí)現(xiàn)如下目標(biāo)：

* 資源交付效率

傳統(tǒng)物理機(jī)的時代，一個服務(wù)器交付要經(jīng)歷找資源，網(wǎng)絡(luò)配置，idc安裝，配置初始化等過程，效率很慢。在瞬息萬變的互聯(lián)網(wǎng)環(huán)境中，產(chǎn)品周期的變的越來越短，對開發(fā)和運(yùn)維的要求越來越高，對于運(yùn)維來說，資源交付效率就至關(guān)重要。

虛擬化可以將物理機(jī)的初始化時間前置，應(yīng)用上線使用機(jī)器時，虛擬機(jī)交付可以做到秒級交付，可以很大縮短上線時間。

* 資源利用率

有了現(xiàn)代多核、多處理器系統(tǒng)，單個服務(wù)器可以很容易地支持十幾個或者更多的虛擬機(jī)，讓更多的應(yīng)用程序能夠受益于高可用的硬件配置，榨干硬件的紅利，降低公司硬件成本。

* 自動化運(yùn)維

虛擬化更容易提供統(tǒng)一的抽象資源和抽象接口，有利于平臺化運(yùn)維。

我們虛擬化的目標(biāo)主要是實(shí)現(xiàn)一個統(tǒng)一的資源管理和交付平臺，在運(yùn)維中的位置大致如下：

在技術(shù)上同時具備如下目標(biāo)：

* 跨平臺，支持libvirt虛擬機(jī)和docker容器

支持libvirt主要是為了支持傳統(tǒng)的虛擬化技術(shù)，如kvm，xen；支持docker主要是為了使用容器的靈活性和高密度。

* 支持用戶自助

申請和準(zhǔn)備資源在運(yùn)維的日常工作中占了相當(dāng)大的一部分工作量，我們很懶，我們想將這個工作放給各個部分負(fù)責(zé)人或者開發(fā)人員。
自助的服務(wù)包括：自助增刪改查、自助擴(kuò)容、自助打鏡像。

* 可運(yùn)維性

一項(xiàng)技術(shù)再牛逼，如不可運(yùn)維，那結(jié)果絕對是災(zāi)難性的。因此我們希望我們的私有云是可控、穩(wěn)定，同時兼顧數(shù)據(jù)的準(zhǔn)確性。

* 彈性計(jì)算

實(shí)時監(jiān)控各個虛擬機(jī)或者容器的性能指標(biāo)，彈性的擴(kuò)容和縮容，合理的分配利用資源。

* IAAS化

為了和當(dāng)前的運(yùn)維體系對接，我們要求虛擬化平臺統(tǒng)一對外提供IAAS服務(wù)，虛擬機(jī)均配置IP，可ssh。

簡單，可控，穩(wěn)定是設(shè)計(jì)的基本原則.

我們是分了如下7點(diǎn)來設(shè)計(jì)和規(guī)劃我們的vcloud平臺。

容器最近很熱，其確實(shí)也很靈活，但是大規(guī)模的使用時機(jī)還不成熟；所以我們選擇傳統(tǒng)虛擬化技術(shù)KVM+docker，確保線上應(yīng)用的穩(wěn)定的同時，測試環(huán)境可以利用到docker的輕量，高性能和靈活。

但如何抽象管理docker和KVM呢，KVM支持的是libvirt，docker的是API，為此我們自己開發(fā)了一個cloudagent，部署在各個宿主機(jī)上，對外提供統(tǒng)一的管理接口。

支持MQ為了進(jìn)行復(fù)雜的調(diào)度算法和大規(guī)模部署，支持http可以方便調(diào)試。

考慮到私有云無自建私有網(wǎng)和隔離的需求，我們選擇的網(wǎng)絡(luò)解決方案是網(wǎng)橋，來簡化網(wǎng)絡(luò)的設(shè)計(jì)，所有VM網(wǎng)絡(luò)都是聯(lián)通的，如有跨環(huán)境隔離需求，統(tǒng)一使用網(wǎng)絡(luò)ACL控制；虛擬機(jī)的IP統(tǒng)一在web平臺指定（按規(guī)則生成），不使用libvirt或者docker本身的自動分配，防止DHCP帶來的不可控問題。

本地存儲使用ssd的LVM，虛擬機(jī)跑在LVM上，讓運(yùn)行的虛擬機(jī)有非常好的IO性能。同時用ceph作為鏡像管理中心和快照中心，提供一個大，但性能不是太好的附加存儲。

PS：強(qiáng)烈建議大家私有云配置ssd，而且單盤裸盤足夠，我們前期使用過SAS和SATA盤，性能慘不忍睹，IOwait經(jīng)常大于50。

KVM和docker如果使用兩套鏡像管理，帶來的管理成本太高，為此我們kvm使用tgz鏡像，docker使用官方的registry v2，這樣kvm和docker的鏡像可以相互轉(zhuǎn)換，可以做到鏡像內(nèi)容統(tǒng)一。

PS：由于最新的docker registery v2不支持ceph的S3，我們自己寫了一個模塊來支持。

是開源還是自己開發(fā)？目前功能最全的openstack，大而全，特別是在網(wǎng)絡(luò)和存儲這塊，很多公司都用openstack開發(fā)自己的私有云和公有云。但對于我們來說，openstack很多功能用不到，特別是它最復(fù)雜的網(wǎng)絡(luò)；而且openstack維護(hù)復(fù)雜，需要有專門的commiter來跟進(jìn)和修改，以滿足自動化運(yùn)維的需要。
考慮到工作量和后期開發(fā)維護(hù)成本，我們選擇自己開發(fā)一個簡單靈活的管理平臺，主要具備如下功能：

用戶管理

虛擬機(jī)管理

ip地址池管理

監(jiān)控管理

鏡像管理

API

我們沒有使用swarm或者kubernetes，主要原因有兩個：第一，我們需要的功能很簡單，實(shí)現(xiàn)起來并不復(fù)雜；第二，swarm和kubernetes版本更新太快，會增加運(yùn)維成本。

我們的使用滿足單機(jī)之間沒有交互，每一個單機(jī)都可以獨(dú)立運(yùn)行，互不影響；所有的調(diào)度都在平臺上控制，保持架構(gòu)簡單、穩(wěn)定、高效、可控。

調(diào)度算法很簡單：

管理員人工指定物理機(jī)，這個優(yōu)先級最高。

在不指定的情況下（普通用戶不能人工指定），秉持最少使用（CPU and 內(nèi)存）和同一應(yīng)用盡量分散的原則選擇物理機(jī)。

PS：kubernetes是一個好東西，特別是他的pods理念很好，很值得借鑒。

監(jiān)控很關(guān)鍵，是調(diào)度，彈性管理和故障遷移的前提，這個的要求是不入侵虛擬機(jī)，監(jiān)控?cái)?shù)據(jù)采集統(tǒng)一在宿主機(jī)上通過cloudagent采集。

傳統(tǒng)虛擬機(jī)可以通過libvirt接口，docker可以通過cgroup+docker API，來計(jì)算虛擬機(jī)的CPU利用率，內(nèi)存使用率，磁盤IOPS，磁盤吞吐量和網(wǎng)絡(luò)速率。

如下是我們vloud平臺的架構(gòu)圖：

* zone集群

zone是一個最小集群管理單元，遷移，擴(kuò)容，批量創(chuàng)建都是一個zone里操作。
一個zone必須在一個網(wǎng)段，一個zone對應(yīng)的IP池，IP由一個統(tǒng)一算法分配，也可以管理員手工指定。
一個zone內(nèi)的物理機(jī)不相互通信，所有的動作都在平臺上控制，由cloudagent接收指令并執(zhí)行。

* IP地址池

IP地址池歸屬于一個zone，IP地址池需要人工配置；定期檢查IP地址池未分配IP地址的連通性，防止IP地址沖突。

* 鏡像管理

docker的鏡像管理使用docker registry v2，kvm使用http的tgz，docker的鏡像和kvm的tgz鏡像，我們按需要進(jìn)行相互轉(zhuǎn)換。

* cloudagent

這個是我們自己開發(fā)的統(tǒng)一的管理agent，部署在各個物理機(jī)器上，封裝了libvirt的API、docker API。對外抽象出統(tǒng)一的接口，含創(chuàng)建、刪除、擴(kuò)容、暫停、監(jiān)控等。

* 性能監(jiān)控

使用不入侵容器和虛擬機(jī)的方式，通過cgroup統(tǒng)一抓取cpu、mem、iops、網(wǎng)絡(luò)；監(jiān)控?cái)?shù)據(jù)作為擴(kuò)容和縮容的一個依據(jù)。

* 創(chuàng)建一臺虛擬機(jī)

我們拿創(chuàng)建虛擬機(jī)這個工作，簡單看一下我們的內(nèi)部調(diào)用流程：

由于kvm這塊比較成熟，網(wǎng)上說的也比較多，本文不做太多的闡述，這里簡單介紹一下我們是如何使用docker。

docker的技術(shù)清單如下：

我們現(xiàn)在最高的密度已經(jīng)達(dá)到了單臺50個，服務(wù)器運(yùn)行毫無壓力，應(yīng)用無異常，估計(jì)可以跑到100個。

* CPU限制

CPU限制，為了管理方便，只用cpuset來限制CPU。在選取綁定的CPU時，按照最少使用原則，同時需要考慮不要跨NUMA。

node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31

"CpusetCpus": "14,15,12,13",

* 內(nèi)存限制

我們選擇了3個參數(shù)來控制內(nèi)存，Memory限定最大可用物理機(jī)內(nèi)存，MemorySwap限定物理內(nèi)存+物理機(jī)內(nèi)存總大小，OomKillDisable標(biāo)記內(nèi)存超過限定是否KILL容器。
原則上是Memory=MemorySwap，即不使用swap，因?yàn)槲覀兿Ｍ萜鲀?nèi)存溢出時可以被直接kill掉，不要影響其他容器。

"Memory": 4294967296,
"MemoryReservation": 0,
"MemorySwap": 4294967296,
"MemorySwappiness": 1,
"OomKillDisable": false,

* 網(wǎng)絡(luò)

網(wǎng)絡(luò)使用網(wǎng)橋，--bridge=docker0，且和物理機(jī)共享一個vlan，簡化網(wǎng)絡(luò)架構(gòu)。
由于docker目前還不支持指定IP，所以這里使用了pipwork來為容器指定我們需求的IP。

/root/cloudagent/script/pipework docker0 -i eth0 idc01-dev-devgroup-101104 1.1.1.1/[email protected] 02:42:c0:01:65:68

* docker registry V2

后端存儲使用ceph，能夠提供幾乎無限大的存儲，方便用戶自定義做快照和鏡像。
由于是在內(nèi)網(wǎng)，registry 沒有使用驗(yàn)證。

* docker 本地存儲

我們用的是devicemapper + direct-lvm，LVM用的是一個800G ssd裸盤。

 --storage-opt dm.basesize=40G --storage-driver=devicemapper --storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool --storage-opt dm.use_deferred_removal=true

經(jīng)過半年的開發(fā)和使用，目前vcloud1.0已經(jīng)的在微店內(nèi)部使用，虛擬化也全部推開。

* 普通用戶管理視圖

* 用戶權(quán)限管理

用戶按zone授權(quán)，資源控制到CPU，內(nèi)存和總個數(shù)。

* 監(jiān)控?cái)?shù)據(jù)

我們的監(jiān)控?cái)?shù)據(jù)統(tǒng)一由cloudagent抓取，并且計(jì)算的都是每個VM實(shí)際使用的。

* 為什么不提供PAAS？

這個看如何理解PAAS和IAAS，在私有云里PAAS應(yīng)該理解為應(yīng)用是否可以自動化上下線。創(chuàng)建一個容器提供出一個nginx服務(wù)，在私有云里叫不上PAAS，一般都還需要SRE將這個nginx服務(wù)暴漏出去，所以我們將我們的Vcloud叫做IAAS平臺；當(dāng)自動化上線實(shí)現(xiàn)了其實(shí)才是真正的PAAS。

* 用什么語言開發(fā)，考慮開源嗎？

我們平臺用的是java，后端cloudagent用的是python；暫時還不考慮開源，主要是沒有時間整理我們的代碼，等后續(xù)平臺穩(wěn)定和功能完善后，會抽出空來整理我們的代碼和規(guī)范，開源給大家參考一下。

* 如何實(shí)現(xiàn)KVM和docker的統(tǒng)一管理？

我們之所以可以做到統(tǒng)一管理，主要原因有兩個，第一：cloudagent，由其來抽象libvirt API及docker API；第二就是KVM使用tgz的模板裝機(jī)，tgz的模板可以和docker的image相互轉(zhuǎn)換，這點(diǎn)特別重要。要不然需要管理兩套的image，那就談不來統(tǒng)一管理了。

* 物理機(jī)掛了或者load過高怎么辦？

這里解釋一下我們這邊的遷移功能（重新創(chuàng)建功能）：將之前的節(jié)點(diǎn)銷毀，然后在zone里重新找一臺機(jī)器來創(chuàng)建,如果之前有快照，可以選擇之前的快照。

當(dāng)物理機(jī)掛了，我們只要將物理機(jī)從zone中剔除，然后逐個遷移，然后重新發(fā)布（無快照情況）；由于IP等信息不變，無需修改CMDB 和LB配置。

* 為什么不全部使用docker？

相比KVM比較成熟的虛擬化技術(shù)，容器目前還有很多不完善的地方，除了集群管理、網(wǎng)絡(luò)和存儲，最重要的還是穩(wěn)定性。容器的隔離性不是很好，當(dāng)一個容器出現(xiàn)問題，很可能影響到整個物理機(jī)。

* 后續(xù)還有什么規(guī)劃？

后續(xù)我們將重點(diǎn)圍繞docker經(jīng)行更多功能的開發(fā)，編排，jenkins對接，自動上下線和分布式附加存儲。

我們的虛擬化（私有云）之路還剛起步，后面vcloud2.0 vcloud3.0還有很多事情要去做和完善，歡迎有興趣的同學(xué)加入微店，加入我們，簡歷請郵件[email protected]。