虛擬化實踐

引言

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

爲何要虛擬化

虛擬化的目的各家公司緣由應該都差很少，通常都是爲了實現以下目標：

* 資源交付效率

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

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

* 資源利用率

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

* 自動化運維

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

目標

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

在技術上同時具有以下目標：

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

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

* 支持用戶自助

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

* 可運維性

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

* 彈性計算

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

* IAAS化

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

設計

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

關鍵點設計

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

1.虛擬化技術選擇

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

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

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

2.網絡選擇

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

3.存儲選擇

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

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

4.鏡像管理

KVM和docker若是使用兩套鏡像管理，帶來的管理成本過高，爲此咱們kvm使用tgz鏡像，docker使用官方的registry v2，這樣kvm和docker的鏡像能夠相互轉換，能夠作到鏡像內容統一。

PS：因爲最新的docker registery v2不支持ceph的S3，咱們本身寫了一個模塊來支持。

5.管理平臺選擇

是開源仍是本身開發？目前功能最全的openstack，大而全，特別是在網絡和存儲這塊，不少公司都用openstack開發本身的私有云和公有云。但對於咱們來講，openstack不少功能用不到，特別是它最複雜的網絡；並且openstack維護複雜，須要有專門的commiter來跟進和修改，以知足自動化運維的須要。
考慮到工做量和後期開發維護成本，咱們選擇本身開發一個簡單靈活的管理平臺，主要具有以下功能：

• 用戶管理

• 虛擬機管理

• ip地址池管理

• 監控管理

• 鏡像管理

• API

6.集羣調度

咱們沒有使用swarm或者kubernetes，主要緣由有兩個：第一，咱們須要的功能很簡單，實現起來並不複雜；第二，swarm和kubernetes版本更新太快，會增長運維成本。

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

調度算法很簡單：

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

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

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

7.監控

監控很關鍵，是調度，彈性管理和故障遷移的前提，這個的要求是不入侵虛擬機，監控數據採集統一在宿主機上經過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、網絡；監控數據做爲擴容和縮容的一個依據。

* 建立一臺虛擬機

咱們拿建立虛擬機這個工做，簡單看一下咱們的內部調用流程：

docker關鍵技術

因爲kvm這塊比較成熟，網上說的也比較多，本文不作太多的闡述，這裏簡單介紹一下咱們是如何使用docker。

docker的技術清單以下：

項目	參數
docker版本	1.10.1
存儲	本地ssd devicemapper
網絡	網橋，–net=none，pipwork種IP
image管理	docker registry V2
物理機配置	32核 128G內存 800Gssd
密度	4核4G容器 單臺 60個
管理方式	Cloudagent+docker API

咱們如今最高的密度已經達到了單臺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實際使用的。

QA

* 爲何不提供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。