本文是WOT2016互聯(lián)網(wǎng)運(yùn)維與開發(fā)者大會的現(xiàn)場干貨，新一屆主題為WOT2016企業(yè)安全技術(shù)峰會將在2016年6月24日-25日于北京珠三角JW萬豪酒店隆重召開!

在本次WOT峰會上，黃繼老師分享了《小米運(yùn)維動態(tài)部署和資源管理實踐》，主要內(nèi)容包括小米運(yùn)維在業(yè)務(wù)部署中由人工進(jìn)入自動化過程中有哪些設(shè)計和整合，Docker/Mesos等熱門技術(shù)如何運(yùn)用，規(guī)?；^程中走過哪些彎路，以及小米運(yùn)維實踐的分享。

【講師簡介】

[[167550]]

黃繼，小米運(yùn)維部高級運(yùn)維研發(fā)工程師， 負(fù)責(zé)消息、推送系統(tǒng)運(yùn)維管理工作，主導(dǎo)負(fù)責(zé)小米資源管理和動態(tài)調(diào)度部署相關(guān)系統(tǒng)的設(shè)計和開發(fā)工作，在部署、資源管理和系統(tǒng)優(yōu)化方面有豐富的經(jīng)驗。

小米運(yùn)維發(fā)展和演進(jìn)

開場，黃繼先展示了小米整個運(yùn)維自動化發(fā)展和演進(jìn)的過程，如圖1所示。

圖1：小米運(yùn)維發(fā)展和演進(jìn)

黃繼指出，小米服務(wù)樹的概念幾年前就提出來了，目前，前三個部分：全量部署、監(jiān)控管理、資源定位都已經(jīng)成型，并且開始使用了，此次主要講的是機(jī)器管理、資源隔離、動態(tài)調(diào)度。

為什么要做資源管理和資源隔離

以動制動，動態(tài)維護(hù)，不靠人工干預(yù)，是整個運(yùn)維和管理中的一個目標(biāo)。具體來說，運(yùn)維中有三個基本點(diǎn)：監(jiān)控、業(yè)務(wù)、主機(jī)。這三個部分的關(guān)系如圖2所示：

圖2：需求和目標(biāo)

小米的目標(biāo)是讓這三者之間的部署做到完全自動化，如此以來，就不需要再有資源預(yù)算，也不需要做人為規(guī)劃，比如設(shè)定機(jī)器組是放前端還是后端，只要告訴機(jī)器前端要部署即可。從而實現(xiàn)拋棄資源預(yù)算和規(guī)劃，提高部署效率，容量調(diào)整，故障快速自愈的目的。

PaaS與運(yùn)維

黃繼先從PaaS的優(yōu)缺點(diǎn)講起。

優(yōu)點(diǎn)：

1. 對業(yè)務(wù)來講是透明的，而且是一個***的資源池。

2. PaaS模塊化的基礎(chǔ)設(shè)施和組件，便于擴(kuò)展。

3. 天然自帶標(biāo)準(zhǔn)化 ，對開發(fā)來講，是有利的。

缺點(diǎn)：

1. 架構(gòu)標(biāo)準(zhǔn)化程度要求高 。

2. 業(yè)務(wù)類型受限，它只是開放了一個業(yè)務(wù)邏輯的層面，前面的接口和存儲都是已經(jīng)固化好的，通常來講只允許接入一些HTTP服務(wù)。

3. 運(yùn)行環(huán)境有特定要求。

所以，我們其實需要的是運(yùn)維角度的PaaS平臺。

小米私有類PaaS平臺

運(yùn)維角度的PaaS應(yīng)該像一個大雜鋪或者大池子，在這個池子里，不用考慮服務(wù)類型，前端和存儲里都可以放服務(wù)。并且具有構(gòu)建集群的能力，擴(kuò)展的能力和自愈能力。

具體的方案選型如圖3所示。

圖3：方案選型

黃繼提到，方案里很多功能都是開源實現(xiàn)的，例如動態(tài)主機(jī)的選擇，集群自動創(chuàng)建，集群維護(hù)，自愈能力等。

接下來，黃繼總結(jié)了三個運(yùn)用中的實際問題。

. 業(yè)務(wù)無縫遷移。其性能和效率要達(dá)到物理機(jī)的程度，才會讓業(yè)務(wù)人員接受。

. 要和周邊的系統(tǒng)，比如服務(wù)樹、監(jiān)控、服務(wù)這些成型的系統(tǒng)相結(jié)合。

. 保證整套動態(tài)系統(tǒng)里邊的資源的正確性。

硬件效率

Docker網(wǎng)絡(luò)模式?jīng)Q定了Container的適用性。Docker的***種模式是Host Only，Host Only只是用了Docker的一些簡單資源，而且是部分功能，無法把整個容器當(dāng)成一個純數(shù)據(jù)化的環(huán)境，因而不符合需求。第二種模式是用NAT，NAT雖然可以解決上述問題，但它也有兩個局限性：一是要管理和維護(hù)物理機(jī)和容器里面IP的預(yù)測關(guān)系，二是對于一些網(wǎng)絡(luò)延遲特別敏感的服務(wù)，運(yùn)行時間在物理機(jī)的基礎(chǔ)上最多可以增加30%，這是不能被接受的。

解決方法

1. 把Docker本身的網(wǎng)槽和物理主機(jī)的網(wǎng)卡調(diào)至一個模塊，為了區(qū)分到底是物理機(jī)還是容器，在調(diào)制過程中讓網(wǎng)絡(luò)設(shè)備做配合，放置一個trunk，這樣一來，物理機(jī)用的是一部分網(wǎng)絡(luò)地址，容器用的是另外一部分網(wǎng)絡(luò)地址，而且可以很容易地把容器這部分的網(wǎng)絡(luò)地址分配交給DHCP SERVER去做，這個容器無論在什么地方啟動，都可以是一個可以訪問到的容器。這樣就解決了容器獨(dú)立性的問題。

2. 直接在物理機(jī)上開LVM，這樣做的好處是和物理機(jī)讀寫這個設(shè)備的效率是一樣的，也就是說在LVM效率上面是沒有損失的。而且，因為設(shè)備的大小有限，所以天然就把存儲空間也限制了。

3. 直接對Docker進(jìn)行修改，讓它在每起一個容器的時候，都生成一條網(wǎng)絡(luò)輸出的限制規(guī)則。

此時，整個容器的環(huán)境相對來說就是一個完整主機(jī)的環(huán)境，各方面的資源相對合理，而且是可以限制的。

編譯和發(fā)布

在新的方式中，業(yè)務(wù)編譯好之后生成Docker lmage，用Docker去分發(fā)。

圖4：編譯發(fā)布

其中，baseimg是必備的，常見的通用組件可選用，上層組件可替換下層組件配置。

環(huán)境依賴和周邊系統(tǒng)接駁：在容器里面放了init，它不僅解決啟動業(yè)務(wù)的程序，還負(fù)責(zé)設(shè)置crontab，在后臺程序啟動stats，采集內(nèi)部的一些信息，注冊lvs，進(jìn)行引流，或者注冊xbox，mysql等。

動態(tài)實例衍生問題

在解決了動態(tài)任務(wù)分配和管理、隔離容器環(huán)境、業(yè)務(wù)平滑遷移、跟其它系統(tǒng)對接等難題后，接下來面對的將是一些動態(tài)實例衍生問題。例如容器IP：如何登錄容器是用戶始終關(guān)心的一個點(diǎn)，比如人工介入管理，白名單授權(quán)，HealthCheck。第二就是數(shù)據(jù)一致性保證，即數(shù)據(jù)回收。

數(shù)據(jù)一致性回收也是需要啟動容器，CIP的上報可以由圖5概括。

圖5：CIP上報

這樣的流程帶來的好處就是真實性，業(yè)務(wù)和IP的對應(yīng)關(guān)系無法偽造，這就給第三方驗證帶來很大方便，這樣，登錄問題就都自然而然地解決了。

同時，在這個過程中，數(shù)據(jù)一致性回收也解決了，因為，在整個系統(tǒng)里，Marathon做的是最完整、最準(zhǔn)確的信息，其它系統(tǒng)里的數(shù)據(jù)都可以和Marathon數(shù)據(jù)作比較，通過這樣的形式來保證所有系統(tǒng)的數(shù)據(jù)最終都是跟動態(tài)部署的是保持一致的。

部署控制

圖6：部署控制

這是一個管理任務(wù)定義、生成部署任務(wù)、控制部署的過程，整合信息之后提供自動化接口。

用戶界面

圖7：用戶界面

綠色表示已經(jīng)上線，白色表示未上線。管理員可以通過這個界面看到整個集群所有節(jié)點(diǎn)的狀態(tài)，如果某個節(jié)點(diǎn)比如說負(fù)載發(fā)生變化了，或者CPU反饋高了，就會在這個節(jié)點(diǎn)上做一些顏色的變化。

現(xiàn)狀和展望

從2014年到目前，小米已經(jīng)擁有2套集群，70多個節(jié)點(diǎn)，5個業(yè)務(wù)上線(其中2個100%承載)，321個常駐實例，主機(jī)利用率提高約50%〜60%。

未來小米要做有狀態(tài)的服務(wù)，包括數(shù)據(jù)存儲、狀態(tài)保持、資源動態(tài)調(diào)整，還要做一些類似VPC的部分。此外，容器的伸縮量也要擴(kuò)展，添加一些像日志分析結(jié)果等數(shù)據(jù)源。

***，黃繼表示，小米運(yùn)維團(tuán)隊的理念口號是Ops Make NoOps，把運(yùn)維的日常工作盡可能的自動化起來，減少手工運(yùn)維操作。