利用Mesos構建多工排程系統

HULK一線技術雜談發表於2018-11-05


利用Mesos構建多工排程系統

女主宣言

我們發現公司的伺服器cpu, memory等資源利用並不充分；如果能夠充分利用這些機器上的空閒資源同時又能保證業務服務的正常執行，將會節省不少的機器資源；所以我們研究了Mesos來構建多工排程系統。接下來就為大家介紹下我們的Mesos系統。

PS：豐富的一線技術、多元化的表現形式，盡在“HULK一線技術雜談”，點關注哦！

背景

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

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

選型

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

(可參考: https://docs.docker.com/engine/faq/#how-do-i-connect-docker-containers)

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

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

Mesos簡介

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

http://mesos.apache.org/

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

Mesos特性

Mesos最大特點是兩級資源排程, 如下圖：


利用Mesos構建多工排程系統

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

  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上可以執行Spark， Storm， Hadoop， Marathon等多種Framework;

Mesos系統架構

官方文件：

http://mesos.apache.org/documentation/latest/architecture/;

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

Mesos Containerizer：

http://mesos.apache.org/documentation/latest/mesos-containerizer/

面臨挑戰

我們的多工排程系統需要解決的幾個問題

  1. Mesos agent在業務機器上需要非侵入式地部署,不能汙染所部署的機器的環境;

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

  3. Task的快速部署和資源隔離;

  4. 叢集整體執行情況的監控;

多工排程系統總體架構

架構設計圖 

 利用Mesos構建多工排程系統

  1. 各元件簡介:
    1.1 主體還是Mesos master + Mesos agent;
    1.2 二級排程框架使用的是Marathon;
    1.3 在部署了Mesos agent的機器上同時部署monitor用於實時監控和調整Agent的可用計算資源;


  2. 系統執行流程，按上圖中標號順序

    2.1 Monitor實時監控元件收集所在機器上的可用資源；

    2.2 Monitor根據所在機器上的可用資源動態調整agent的保留資源;

    2.3 Agent動態實時的將自已的保留資源上報到Mesos master;

    2.4 Mesos Master在resource offer發到Marathon;

    2.5 Marathon根據收到的resource offer和需要執行的task作資源分配, 將分配結果反饋給Mesos Master;

    2.6Mesos Master將task分配到具體的Agent上執行;

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

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


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

  1. 我們將mesos執行所需要的所有lib檔案都集中放在libs目錄下；

  2. 編譯出來的mesos可執行檔案,使用patchelf來更新rpath路徑,指向我們自已的libs目錄即可;

  3. patchelf這個工具可以在不影響可執行檔案執行的前提下,修改其elf檔案結構中的某些屬性值,具體可參考:https://nixos.org/patchelf.html

這樣部署完，Mesos agent只是一個單獨的目錄，解除安裝只需要停掉程式，刪除目錄就好;

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

  1. 官網編譯步驟: 請參考

    http://mesos.apache.org/documentation/latest/building/;

  2. gcc官方要求是 4.8.1+, 我用了 gcc 5.4, 自己在 centos 6.2,linux 2.6.32上重新編譯的;

  3. 編譯預設是編譯java語言的binding的, 但在 編譯 "Build and attach javadoc"時缺 protobuffer的jar包,沒編譯過, 解決方案:修改 src/java/mesos.pom.in,先找到 ``, 在它下面的 <configuration>下新增 <skip>true</skip>,這樣不會編譯這個 javdoc, 但不影響 java binding的使用

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

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

利用Mesos構建多工排程系統

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

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

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

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

Task的快速部署和資源隔離

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有兩種方式:

  1. cpu shared方式:這種方式對 cpu 沒有嚴格限制，機器上的任何task都可以訪問機器上所有cpu資源,比如你限定的cpu使用資源是2, 這種方式可能使用到4,6或更高;


  2. cpu CFS方式: 相當於配置了獨佔 cpu, 比如cpu配置為1，那麼這個任務的 cpu 使用率就不會超過 100%, 相當於設定了一個hard limit;

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

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

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

利用Mesos構建多工排程系統

關於chroot, 大家可以參考下面的網址內容，簡單講就是構造了一個沙箱,和已有的檔案系統隔離;

https://www.ibm.com/developerworks/cn/linux/l-cn-chroot/

叢集整體執行情況的監控

機器本身的基礎監控一般公司還有自己的統一監控, 這部分不用投入精力;

我們主要關注task的排程執行情況，目前的方案是mesos-exporter和mesos-agent(或mesos-master)一起部署，上報監控資訊到prometheus，使用grafana來展示;

mesos本身為我們提供了很豐富的http api來獲取當前叢集的屬性,狀態,Framework情況,task的執行狀態等等,結合這些我們自己來作監控其實也不是難事,可以參考這裡:

http://mesos.apache.org/documentation/latest/operator-http-api

仍然存在的問題

打包task沒有實現自動化, 我們雖然定製了若干種不同的rootfs, 比如c++11環境的, python環境的, java環境的等等, 但是想要執行的task依賴千差萬別, 現在都是結合rootfs和業務的程式,手動合成專用的rootfs, 基本上每個task都要走這個手動流程,煩鎖,耗時,容易出錯;

目前只引用了marathon一種排程框架,適用於長期執行的task, 對於需要定時執行的task目前無法支援;

結束

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

HULK一線技術雜談

由360雲平臺團隊打造的技術分享公眾號，內容涉及雲端計算、資料庫、大資料、監控、泛前端、自動化測試等眾多技術領域，通過夯實的技術積累和豐富的一線實戰經驗，為你帶來最有料的技術分享

原文連結：https://mp.weixin.qq.com/s/K2G1mUo_WOhDyAxGgcfqHA

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31555491/viewspace-2218738/，如需轉載，請註明出處，否則將追究法律責任。

相關文章