本文是WOT2016互聯網運維與開發者大會的現場干貨，新一屆主題為WOT2016企業安全技術峰會將在2016年6月24日-25日于北京珠三角JW萬豪酒店隆重召開!

在本次WOT峰會上，黃繼老師分享了《小米運維動態部署和資源管理實踐》，主要內容包括小米運維在業務部署中由人工進入自動化過程中有哪些設計和整合，Docker/Mesos等熱門技術如何運用，規模化過程中走過哪些彎路，以及小米運維實踐的分享。

【講師簡介】

[[167550]]

黃繼，小米運維部高級運維研發工程師， 負責消息、推送系統運維管理工作，主導負責小米資源管理和動態調度部署相關系統的設計和開發工作，在部署、資源管理和系統優化方面有豐富的經驗。

小米運維發展和演進

開場，黃繼先展示了小米整個運維自動化發展和演進的過程，如圖1所示。

圖1：小米運維發展和演進

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

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

以動制動，動態維護，不靠人工干預，是整個運維和管理中的一個目標。具體來說，運維中有三個基本點：監控、業務、主機。這三個部分的關系如圖2所示：

圖2：需求和目標

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

PaaS與運維

黃繼先從PaaS的優缺點講起。

優點：

1. 對業務來講是透明的，而且是一個***的資源池。

2. PaaS模塊化的基礎設施和組件，便于擴展。

3. 天然自帶標準化 ，對開發來講，是有利的。

缺點：

1. 架構標準化程度要求高 。

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

3. 運行環境有特定要求。

所以，我們其實需要的是運維角度的PaaS平臺。

小米私有類PaaS平臺

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

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

圖3：方案選型

黃繼提到，方案里很多功能都是開源實現的，例如動態主機的選擇，集群自動創建，集群維護，自愈能力等。

接下來，黃繼總結了三個運用中的實際問題。

. 業務無縫遷移。其性能和效率要達到物理機的程度，才會讓業務人員接受。

. 要和周邊的系統，比如服務樹、監控、服務這些成型的系統相結合。

. 保證整套動態系統里邊的資源的正確性。

硬件效率

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

解決方法

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

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

3. 直接對Docker進行修改，讓它在每起一個容器的時候，都生成一條網絡輸出的限制規則。

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

編譯和發布

在新的方式中，業務編譯好之后生成Docker lmage，用Docker去分發。

圖4：編譯發布

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

環境依賴和周邊系統接駁：在容器里面放了init，它不僅解決啟動業務的程序，還負責設置crontab，在后臺程序啟動stats，采集內部的一些信息，注冊lvs，進行引流，或者注冊xbox，mysql等。

動態實例衍生問題

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

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

圖5：CIP上報

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

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

部署控制

圖6：部署控制

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

用戶界面

圖7：用戶界面

綠色表示已經上線，白色表示未上線。管理員可以通過這個界面看到整個集群所有節點的狀態，如果某個節點比如說負載發生變化了，或者CPU反饋高了，就會在這個節點上做一些顏色的變化。

現狀和展望

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

未來小米要做有狀態的服務，包括數據存儲、狀態保持、資源動態調整，還要做一些類似VPC的部分。此外，容器的伸縮量也要擴展，添加一些像日志分析結果等數據源。

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