背景

公司內部的云平臺為各個業務線提供了大量的實體機和虛擬機來運行業務的服務，經過統計發現，這些分配給業務的機器cpu, memory等資源利用并不充分;

如果能夠充分利用這些機器上的空閑資源同時又能保證業務服務的正常運行，將會節省不少的機器資源;

選型

一提到多任務運行和調度，大部分人可能首先都會想到Kubernetes(k8s) + Docker, 跑起來如清風拂面, 順暢無比。然而我們的業務機器大部分為centos 6.2, linux kernel 2.6的環境,而docker的運行需要Linux kernel的版本是 3.10+

因為想利用業務正在使用的機器，又不能影響現有已在跑的服務, 所以不能升級內核， 不能重啟機器，顯然k8s這條路走不通;

還好，這個世界總是提供給我們多樣的選擇，除了Kubernetes(k8s) + Docker, 我們還有mesos;

Mesos簡介

先放上官方網站, 上面有很詳細的說明;

簡單來說，Mesos就是用于整個計算中心的操作系統，它統一管理計算中心所有機器的cpu, memory, disk, network等計算資源，按任務所需分配資源，調度任務，支持故障轉移等等;

Mesos特性

Mesos最大特點是兩級資源調度, 如下圖：

上面架構圖的簡要說明如下:

在Mesos上可以運行Spark， Storm， Hadoop， Marathon等多種Framework;

Mesos系統架構

針對任務隔離這塊, Mesos除了支持docker容器技術，還提供了它自己的Mesos Containerizer, 這正是我們所需要的.其實Mesos Containerizer目前也是利用Linux Cgroup作資源限制, 用Linux namespace作資源隔離.

面臨挑戰

我們的多任務調度系統需要解決的幾個問題

多任務調度系統總體架構

架構設計圖 

Mesos agent在業務機器上非侵入式部署

我們采用的是Mesos 1.4.1版本，用C++11編寫，Mesos項目本身非常龐大,依賴庫必然也很多，解決這些運行依賴問題首當其沖;

部署原則就是不改變,不污染所部署的機器環境，針對libstdc++和其他一些so, 我們不會將其安裝到例如/usr/local/lib這樣的系統目錄, 而是在打包時采用動態更改可執行程序的rpath的方法，使其運行時從我們的安裝目錄加載相應的so庫, 具體作法就是

這樣部署完，Mesos agent只是一個單獨的目錄，卸載只需要停掉進程，刪除目錄就好;

說一下編譯過程,雖然官網上已經介紹得比較詳細,但在編譯過程中還是會遇到一些問題:

實時監控和調整Agent所能使用的計算資源

自行開發了Monitor程序，和Agent一同部署在業務機器上，周期性的監測機器上可用資源和Agent本身所用資源;

Mesos為我們提供了動態資源保留這個超實用的功能，可以限制Agent當前針對某個Role可以使用的計算資源:

Monitor的監控評估結果就是當前Agent可以使用的計算資源;

本想著到這里這個問題就結束了，測試時發現Agent并不能在線實時調整這個動態資源保留，需要在配置文件時更新好當前能夠使用的動態資源,然后重啟Agent;

重啟Agent是我們不能忍受的,因此我們修改了源碼，通過http接口在線調整動態資源保留, 這部分其實不難,mesos http接口定義十分清晰,依葫蘆畫瓢就好了.

task的部署目前我們采用Marathon，上手簡單，功能夠用; 如果需要更靈活的調整策略，可能就需要自己開采框架或基于某一框架二次開發了;

task其實是有重要，緊急之分，占用資源也不盡相同。對于重要緊急任務，為了保障任務的更好運行，我們會利用Mesos attribute,在調度任務時讓特定任務只跑在具有特定attributes的agent上, 這就需要為每個mesos agent設置相應的attributes;

遇到了同樣的問題，mesos不能在線動態調整attributes :-(, 其實也比較簡單，稍微梳理下mesos源碼結構，改起來不難;

還有一個問題，attributes是動態調整的，agent如果重啟了怎么辦？我們為此部署了etcd集群來管理，每臺agent都是etcd上的一個node, 通過etcd提供的http接口更新其attribrtes, agent會周期性的從etcd上同步;同時各agent 上的attributes信息也很容易從etcd上獲得;

直接操作etcd, 刪除某臺agent上的attribute, 那依賴于這種attribute部署的任務會自動別調度走,不再在這臺agent上運行;

task隔離問題，針對cpu和memory，mesos都是通過cgroup來完成，對于cpu的限制， 我們使用cfs方式，前提是需要判斷當前kernel是否支持.對于disk的限制，目前mesos使用的是du命令周期性檢測的方式;

對于cpu的限制,mesos有兩種方式:

在我們的大部分環境中，受限于kernel版本，mount namespace不支持，因此我們采用rootfs + chroot的方式來作簡單的資源隔離;

我們定制了若干版本的rootfs, 任務打包就是將任務本身的依賴和相應rootfs結合的過程, 打包好可以放到s3等存儲上，供marathon部署任務時調用。

這里我們結合marathon的一個任務部署的json配置來講一下, 先看一個這個配置, 我將說明直接寫在里面