利用Mesos構建多任務調度系統

背景

• 公司內部的雲平臺爲各個業務線提供了大量的實體機和虛擬機來運行業務的服務，經過統計發現，這些分配給業務的機器cpu, memory等資源利用並不充分;
• 如何充分利用這些機器上的空閒資源又能保證業務服務的正常運行，這是個問題;

選型

• 一提到任務運行和調度，大部分人可能首先都會想到Kubernetes(k8s) + Docker, 跑起來如清風拂面。然而我們的業務機器大部分爲centos 6.2, linux kernel 2.6的配置;
• 業務正在使用的機器，不能升級內核， 不能重啓機器，k8s這條路走不通;
• 還好，這個世界總是給我們多樣選擇，除了k8s, 我們還有mesos;

Mesos簡介

• 先放上官方網站
• 簡單來說，Mesos就是用於整個計算中心的操作系統，它統一管理計算中心所有機器的cpu, memory, disk等計算資源，按任務所需分配資源，調度任務，支持故障轉移等等;
• Mesos最大特點是兩級資源調度, 如下圖：

m2.png

1. 各個Agent上報自的 已計算資源給Master;
2. Master給各個二級調度框架Framework發送resource offer;
3. Framework將其上的task與收到的resource offer作匹配，反饋給Master;
4. Master將相應Framework反饋的task和resource offer發送到對應的Agent;
5. Agent使用Executor來運行task, 並限定資源使用;

• Mesos系統架構：http://mesos.apache.org/documentation/latest/architecture/
• 任務隔離除了支持docker容器技術，還提供了它自己的Mesos Containerizer, 這正是我們所需要的;

我們需要解決的幾個問題

• Mesos agent在業務機器上非侵入式地純淨式部署;
• 實時監控和調整Agent所能使用的計算資源;
• Task的快速部署和資源隔離;
• 集羣整體運行情況的監控;

我們在以下面會依次來聊一聊這些問題～

多任務調度系統總體架構

• 架構設計圖:

mesos.jpeg

1. 主體還是Mesos master + Mesos agent;
2. 二級調度框架使用的是Marathon;
3. 在部署了Mesos agent的機器上同時部署monitor用於實時監控和調整Agent的可用計算資源;

• 系統運行流程，按上圖中標號順序
  1. Monitor實時監控收集所在機器上的可用資源;
  2. Monitor根據所在機器上的可用資源動態調整agent的保留資源;
  3. Agent動態實時的將自已的保留資源上報到Mesos master;
  4. Mesos Master在resource offer發到Marathon;
  5. Marathon根據收到的resource offer和需要運行的task作資源分配, 將分配結果反饋給Mesos Master;
  6. Mesos Master將task分配到具體的Agent`上執行;

解決： Mesos agent在業務機器上非侵入式地純淨式部署

• 我們採用的是Mesos 1.4.1版本，用C++11編寫，衆所周知，C++的依賴問題是夢魘啊～～
• 部署原則就是不改變原有機器環境，針對libstdc++和其他一些so, 我們在打包時採用動態更改可執行程序的rpath的方法，使其運行時從我們的安裝目錄加載相應的so庫;
• 這樣部署完，Mesos agent只是一個單獨的目錄，卸載只需要停掉進程，刪除目錄就好;

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

• 開發Monitor程序，和Agent一同部署在業務機器上，週期性的監測機器上可用資源和Agent本身所用資源;
• Mesos爲我們提供了動態資源保留這個超實用的功能，可以限制Agent當前針對某個Role可以使用的計算資源;
• Monitor的監控評估結果就是當前Agent可以使用的計算資源;
• 本想着到這裏這個問題就結束了，測試時發現Agent並不能在線調整這個動態資源保留，需要重啓Agent;
• 不得已，我們修改了源碼，通過http接口在線調整動態資源保留

解決：Task的快速部署和資源隔離

• task的部署目前我們採用Marathon，上手簡單，功能夠用; 如果需要更靈活的調整策略，可能就需要自己開採框架或基於某一框架二次開發了;
• task其實是有重要，緊急之分，佔用資源也不盡相同。對於重要緊急任務，爲了保障任務的更好運行，我們會利用Mesos attribute,在調度任務時讓特定任務只跑在具有特定attributes的agent上;
• 遇到了同樣的問題，mesos不能在線動態調整attributes :-( 來來來，源碼改起來～～～其實都比較簡單，稍微梳理下mesos源碼結構，改起來不難;
• 還有一個問題，attributes是動態調整的，agent如果重啓了怎麼辦？我們爲此部署了etcd集羣，這臺agent都是etcd上的一個node, 通過etcd提供的http接口更新其attribrtes, agent會週期性的從etcd上同步;同時各agent 上的attributes信息也很容易從etcd上獲得。
• task隔離問題，針對cpu和memory，mesos都是通過cgroup來完成，對於cpu的限制， 我們使用cfs方式，前提是需要判斷當前kernel是否支持.對於disk的限制，目前mesos使用的是du命令週期性檢測的方式;
• 在我們的大部分環境中，受限於kernel版本，mount namespace不支持，因爲我們採用rootfs + chroot的方式;
• 我們定製了若干版本的rootfs, 任務打包就是將任務本身的依賴和相應rootfs結合的過程, 打包好可以放到s3等存儲上，供marathon等調用。

解決：集羣整體運行情況的監控

• 機器本身的基礎監控由公司統一監控;
• 我們主要關注task的調整運行情況，目前的方案是mesos-exporter和mesos-agent(或mesos-master)一起部署，上報監控信息到prometheus，使用grafana來展示。

到此我們利用Mesos構建的多任務調度系統就簡單介紹完成，其中還有很多不完善的地方，有興趣的同學可以一起討論，互相學習～～～