本篇內(nèi)容介紹了“如何利用Mesos構(gòu)建多任務(wù)調(diào)度系統(tǒng)”的有關(guān)知識,在實(shí)際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
成都創(chuàng)新互聯(lián)專注于商城企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站開發(fā)。商城網(wǎng)站建設(shè)公司,為商城等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站設(shè)計(jì),專業(yè)設(shè)計(jì),全程項(xiàng)目跟蹤,成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
背景
公司內(nèi)部的云平臺為各個(gè)業(yè)務(wù)線提供了大量的實(shí)體機(jī)和虛擬機(jī)來運(yùn)行業(yè)務(wù)的服務(wù),經(jīng)過統(tǒng)計(jì)發(fā)現(xiàn),這些分配給業(yè)務(wù)的機(jī)器cpu, memory等資源利用并不充分;
如果能夠充分利用這些機(jī)器上的空閑資源同時(shí)又能保證業(yè)務(wù)服務(wù)的正常運(yùn)行,將會節(jié)省不少的機(jī)器資源;
選型
一提到多任務(wù)運(yùn)行和調(diào)度,大部分人可能首先都會想到Kubernetes(k8s) + Docker, 跑起來如清風(fēng)拂面, 順暢無比。然而我們的業(yè)務(wù)機(jī)器大部分為centos 6.2, linux kernel 2.6的環(huán)境,而docker的運(yùn)行需要Linux kernel的版本是 3.10+
(可參考: https://docs.docker.com/engine/faq/#how-do-i-connect-docker-containers)
因?yàn)橄肜脴I(yè)務(wù)正在使用的機(jī)器,又不能影響現(xiàn)有已在跑的服務(wù), 所以不能升級內(nèi)核, 不能重啟機(jī)器,顯然k8s這條路走不通;
還好,這個(gè)世界總是提供給我們多樣的選擇,除了Kubernetes(k8s) + Docker, 我們還有mesos;
Mesos簡介
先放上官方網(wǎng)站, 上面有很詳細(xì)的說明;
http://mesos.apache.org/
簡單來說,Mesos就是用于整個(gè)計(jì)算中心的操作系統(tǒng),它統(tǒng)一管理計(jì)算中心所有機(jī)器的cpu, memory, disk, network等計(jì)算資源,按任務(wù)所需分配資源,調(diào)度任務(wù),支持故障轉(zhuǎn)移等等;
Mesos特性
Mesos最大特點(diǎn)是兩級資源調(diào)度, 如下圖:
上面架構(gòu)圖的簡要說明如下:
各個(gè)Agent上報(bào)自已的計(jì)算資源給Master;
Master給各個(gè)二級調(diào)度框架Framework發(fā)送resource offer;
Framework將其上等待調(diào)度的task與收到的resource offer作匹配,反饋給Master;
Master將相應(yīng)Framework反饋的task和resource offer發(fā)送到對應(yīng)的Agent;
Agent使用Executor來運(yùn)行task, 并限定資源使用;
在Mesos上可以運(yùn)行Spark, Storm, Hadoop, Marathon等多種Framework;
Mesos系統(tǒng)架構(gòu)
官方文檔:
http://mesos.apache.org/documentation/latest/architecture/;
針對任務(wù)隔離這塊, Mesos除了支持docker容器技術(shù),還提供了它自己的Mesos Containerizer, 這正是我們所需要的.其實(shí)Mesos Containerizer目前也是利用Linux Cgroup作資源限制, 用Linux namespace作資源隔離.
Mesos Containerizer:
http://mesos.apache.org/documentation/latest/mesos-containerizer/
面臨挑戰(zhàn)
我們的多任務(wù)調(diào)度系統(tǒng)需要解決的幾個(gè)問題
Mesos agent在業(yè)務(wù)機(jī)器上需要非侵入式地部署,不能污染所部署的機(jī)器的環(huán)境;
實(shí)時(shí)監(jiān)控和調(diào)整Mesos Agent所能使用的計(jì)算資源;
Task的快速部署和資源隔離;
集群整體運(yùn)行情況的監(jiān)控;
多任務(wù)調(diào)度系統(tǒng)總體架構(gòu)
架構(gòu)設(shè)計(jì)圖
各組件簡介:
1.1 主體還是Mesos master + Mesos agent;
1.2 二級調(diào)度框架使用的是Marathon;
1.3 在部署了Mesos agent的機(jī)器上同時(shí)部署monitor用于實(shí)時(shí)監(jiān)控和調(diào)整Agent的可用計(jì)算資源;
系統(tǒng)運(yùn)行流程,按上圖中標(biāo)號順序
2.1 Monitor實(shí)時(shí)監(jiān)控組件收集所在機(jī)器上的可用資源;
2.2 Monitor根據(jù)所在機(jī)器上的可用資源動態(tài)調(diào)整agent的保留資源;
2.3 Agent動態(tài)實(shí)時(shí)的將自已的保留資源上報(bào)到Mesos master;
2.4 Mesos Master在resource offer發(fā)到Marathon;
2.5 Marathon根據(jù)收到的resource offer和需要運(yùn)行的task作資源分配, 將分配結(jié)果反饋給Mesos Master;
2.6Mesos Master將task分配到具體的Agent上執(zhí)行;
Mesos agent在業(yè)務(wù)機(jī)器上非侵入式部署
我們采用的是Mesos 1.4.1版本,用C++11編寫,Mesos項(xiàng)目本身非常龐大,依賴庫必然也很多,解決這些運(yùn)行依賴問題首當(dāng)其沖;
部署原則就是不改變,不污染所部署的機(jī)器環(huán)境,針對libstdc++和其他一些so, 我們不會將其安裝到例如/usr/local/lib這樣的系統(tǒng)目錄, 而是在打包時(shí)采用動態(tài)更改可執(zhí)行程序的rpath的方法,使其運(yùn)行時(shí)從我們的安裝目錄加載相應(yīng)的so庫, 具體作法就是
我們將mesos運(yùn)行所需要的所有l(wèi)ib文件都集中放在libs目錄下;
編譯出來的mesos可執(zhí)行文件,使用patchelf來更新rpath路徑,指向我們自已的libs目錄即可;
patchelf這個(gè)工具可以在不影響可執(zhí)行文件運(yùn)行的前提下,修改其elf文件結(jié)構(gòu)中的某些屬性值,具體可參考:https://nixos.org/patchelf.html
這樣部署完,Mesos agent只是一個(gè)單獨(dú)的目錄,卸載只需要停掉進(jìn)程,刪除目錄就好;
說一下編譯過程,雖然官網(wǎng)上已經(jīng)介紹得比較詳細(xì),但在編譯過程中還是會遇到一些問題:
官網(wǎng)編譯步驟: 請參考
http://mesos.apache.org/documentation/latest/building/;
gcc官方要求是 4.8.1+, 我用了 gcc 5.4, 自己在 centos 6.2,linux 2.6.32上重新編譯的;
編譯默認(rèn)是編譯java語言的binding的, 但在 編譯 "Build and attach javadoc"時(shí)缺 protobuffer的jar包,沒編譯過, 解決方案:修改 src/java/mesos.pom.in,先找到 ``, 在它下面的
實(shí)時(shí)監(jiān)控和調(diào)整Agent所能使用的計(jì)算資源
自行開發(fā)了Monitor程序,和Agent一同部署在業(yè)務(wù)機(jī)器上,周期性的監(jiān)測機(jī)器上可用資源和Agent本身所用資源;
Mesos為我們提供了動態(tài)資源保留這個(gè)超實(shí)用的功能,可以限制Agent當(dāng)前針對某個(gè)Role可以使用的計(jì)算資源:
Monitor的監(jiān)控評估結(jié)果就是當(dāng)前Agent可以使用的計(jì)算資源;
本想著到這里這個(gè)問題就結(jié)束了,測試時(shí)發(fā)現(xiàn)Agent并不能在線實(shí)時(shí)調(diào)整這個(gè)動態(tài)資源保留,需要在配置文件時(shí)更新好當(dāng)前能夠使用的動態(tài)資源,然后重啟Agent;
重啟Agent是我們不能忍受的,因此我們修改了源碼,通過http接口在線調(diào)整動態(tài)資源保留, 這部分其實(shí)不難,mesos http接口定義十分清晰,依葫蘆畫瓢就好了.
Task的快速部署和資源隔離
task的部署目前我們采用Marathon,上手簡單,功能夠用; 如果需要更靈活的調(diào)整策略,可能就需要自己開采框架或基于某一框架二次開發(fā)了;
task其實(shí)是有重要,緊急之分,占用資源也不盡相同。對于重要緊急任務(wù),為了保障任務(wù)的更好運(yùn)行,我們會利用Mesos attribute,在調(diào)度任務(wù)時(shí)讓特定任務(wù)只跑在具有特定attributes的agent上, 這就需要為每個(gè)mesos agent設(shè)置相應(yīng)的attributes;
遇到了同樣的問題,mesos不能在線動態(tài)調(diào)整attributes :-(, 其實(shí)也比較簡單,稍微梳理下mesos源碼結(jié)構(gòu),改起來不難;
還有一個(gè)問題,attributes是動態(tài)調(diào)整的,agent如果重啟了怎么辦?我們?yōu)榇瞬渴鹆薳tcd集群來管理,每臺agent都是etcd上的一個(gè)node, 通過etcd提供的http接口更新其attribrtes, agent會周期性的從etcd上同步;同時(shí)各agent 上的attributes信息也很容易從etcd上獲得;
直接操作etcd, 刪除某臺agent上的attribute, 那依賴于這種attribute部署的任務(wù)會自動別調(diào)度走,不再在這臺agent上運(yùn)行;
task隔離問題,針對cpu和memory,mesos都是通過cgroup來完成,對于cpu的限制, 我們使用cfs方式,前提是需要判斷當(dāng)前kernel是否支持.對于disk的限制,目前mesos使用的是du命令周期性檢測的方式;
對于cpu的限制,mesos有兩種方式:
cpu shared方式:這種方式對 cpu 沒有嚴(yán)格限制,機(jī)器上的任何task都可以訪問機(jī)器上所有cpu資源,比如你限定的cpu使用資源是2, 這種方式可能使用到4,6或更高;
cpu CFS方式: 相當(dāng)于配置了獨(dú)占 cpu, 比如cpu配置為1,那么這個(gè)任務(wù)的 cpu 使用率就不會超過 100%, 相當(dāng)于設(shè)定了一個(gè)hard limit;
在我們的大部分環(huán)境中,受限于kernel版本,mount namespace不支持,因此我們采用rootfs + chroot的方式來作簡單的資源隔離;
我們定制了若干版本的rootfs, 任務(wù)打包就是將任務(wù)本身的依賴和相應(yīng)rootfs結(jié)合的過程, 打包好可以放到s3等存儲上,供marathon部署任務(wù)時(shí)調(diào)用。
這里我們結(jié)合marathon的一個(gè)任務(wù)部署的json配置來講一下, 先看一個(gè)這個(gè)配置, 我將說明直接寫在里面
“如何利用Mesos構(gòu)建多任務(wù)調(diào)度系統(tǒng)”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!