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

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

虛擬化的目的各家公司原因應該都差不多，一般都是為了實現如下目標：

* 資源交付效率

傳統物理機的時代，一個服務器交付要經歷找資源，網絡配置，idc安裝，配置初始化等過程，效率很慢。在瞬息萬變的互聯網環境中，產品周期的變的越來越短，對開發和運維的要求越來越高，對于運維來說，資源交付效率就至關重要。

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

* 資源利用率

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

* 自動化運維

虛擬化更容易提供統一的抽象資源和抽象接口，有利于平臺化運維。

我們虛擬化的目標主要是實現一個統一的資源管理和交付平臺，在運維中的位置大致如下：

在技術上同時具備如下目標：

* 跨平臺，支持libvirt虛擬機和docker容器

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

* 支持用戶自助

申請和準備資源在運維的日常工作中占了相當大的一部分工作量，我們很懶，我們想將這個工作放給各個部分負責人或者開發人員。
自助的服務包括：自助增刪改查、自助擴容、自助打鏡像。

* 可運維性

一項技術再牛逼，如不可運維，那結果絕對是災難性的。因此我們希望我們的私有云是可控、穩定，同時兼顧數據的準確性。

* 彈性計算

實時監控各個虛擬機或者容器的性能指標，彈性的擴容和縮容，合理的分配利用資源。

* IAAS化

為了和當前的運維體系對接，我們要求虛擬化平臺統一對外提供IAAS服務，虛擬機均配置IP，可ssh。

簡單，可控，穩定是設計的基本原則.

我們是分了如下7點來設計和規劃我們的vcloud平臺。

容器最近很熱，其確實也很靈活，但是大規模的使用時機還不成熟；所以我們選擇傳統虛擬化技術KVM+docker，確保線上應用的穩定的同時，測試環境可以利用到docker的輕量，高性能和靈活。

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

支持MQ為了進行復雜的調度算法和大規模部署，支持http可以方便調試。

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

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

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

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

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

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

用戶管理

虛擬機管理

ip地址池管理

監控管理

鏡像管理

API

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

我們的使用滿足單機之間沒有交互，每一個單機都可以獨立運行，互不影響；所有的調度都在平臺上控制，保持架構簡單、穩定、高效、可控。

調度算法很簡單：

管理員人工指定物理機，這個優先級最高。

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

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

監控很關鍵，是調度，彈性管理和故障遷移的前提，這個的要求是不入侵虛擬機，監控數據采集統一在宿主機上通過cloudagent采集。

傳統虛擬機可以通過libvirt接口，docker可以通過cgroup+docker API，來計算虛擬機的CPU利用率，內存使用率，磁盤IOPS，磁盤吞吐量和網絡速率。

如下是我們vloud平臺的架構圖：

* zone集群

zone是一個最小集群管理單元，遷移，擴容，批量創建都是一個zone里操作。
一個zone必須在一個網段，一個zone對應的IP池，IP由一個統一算法分配，也可以管理員手工指定。
一個zone內的物理機不相互通信，所有的動作都在平臺上控制，由cloudagent接收指令并執行。

* IP地址池

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

* 鏡像管理

docker的鏡像管理使用docker registry v2，kvm使用http的tgz，docker的鏡像和kvm的tgz鏡像，我們按需要進行相互轉換。

* cloudagent

這個是我們自己開發的統一的管理agent，部署在各個物理機器上，封裝了libvirt的API、docker API。對外抽象出統一的接口，含創建、刪除、擴容、暫停、監控等。

* 性能監控

使用不入侵容器和虛擬機的方式，通過cgroup統一抓取cpu、mem、iops、網絡；監控數據作為擴容和縮容的一個依據。

* 創建一臺虛擬機

我們拿創建虛擬機這個工作，簡單看一下我們的內部調用流程：

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

docker的技術清單如下：

我們現在最高的密度已經達到了單臺50個，服務器運行毫無壓力，應用無異常，估計可以跑到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",

* 內存限制

我們選擇了3個參數來控制內存，Memory限定最大可用物理機內存，MemorySwap限定物理內存+物理機內存總大小，OomKillDisable標記內存超過限定是否KILL容器。
原則上是Memory=MemorySwap，即不使用swap，因為我們希望容器內存溢出時可以被直接kill掉，不要影響其他容器。

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

* 網絡

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

/root/cloudagent/script/pipework docker0 -i eth0 idc01-dev-devgroup-101104 1.1.1.1/24@1.1.1.254 02:42:c0:01:65:68

* docker registry V2

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

* 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

經過半年的開發和使用，目前vcloud1.0已經的在微店內部使用，虛擬化也全部推開。

* 普通用戶管理視圖

* 用戶權限管理

用戶按zone授權，資源控制到CPU，內存和總個數。

* 監控數據

我們的監控數據統一由cloudagent抓取，并且計算的都是每個VM實際使用的。

* 為什么不提供PAAS？

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

* 用什么語言開發，考慮開源嗎？

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

* 如何實現KVM和docker的統一管理？

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

* 物理機掛了或者load過高怎么辦？

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

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

* 為什么不全部使用docker？

相比KVM比較成熟的虛擬化技術，容器目前還有很多不完善的地方，除了集群管理、網絡和存儲，最重要的還是穩定性。容器的隔離性不是很好，當一個容器出現問題，很可能影響到整個物理機。

* 后續還有什么規劃？

后續我們將重點圍繞docker經行更多功能的開發，編排，jenkins對接，自動上下線和分布式附加存儲。

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