基于Mesos和Docker的分布式計(jì)算平臺(tái)

責(zé)任編輯:editor006

作者:王璞

2015-06-09 16:02:29

摘自:《程序員》電子刊

針對(duì)“互聯(lián)網(wǎng)+”時(shí)代的業(yè)務(wù)增長(zhǎng)、變化速度及大規(guī)模計(jì)算的需求,廉價(jià)的、高可擴(kuò)展的分布式x86集群已成為標(biāo)準(zhǔn)解決方案,如Google已經(jīng)在幾千萬(wàn)臺(tái)服務(wù)器上部署分布式系統(tǒng)。

針對(duì)“互聯(lián)網(wǎng)+”時(shí)代的業(yè)務(wù)增長(zhǎng)、變化速度及大規(guī)模計(jì)算的需求,廉價(jià)的、高可擴(kuò)展的分布式x86集群已成為標(biāo)準(zhǔn)解決方案,如Google已經(jīng)在幾千萬(wàn)臺(tái)服務(wù)器上部署分布式系統(tǒng)。Docker及其相關(guān)技術(shù)的出現(xiàn)和發(fā)展,又給大規(guī)模集群管理帶來(lái)了新的想象空間。如何將二者進(jìn)行有效地結(jié)合?本文將介紹數(shù)人科技基于Mesos和Docker的分布式計(jì)算平臺(tái)的實(shí)踐。

分布式系統(tǒng)設(shè)計(jì)準(zhǔn)則

可伸縮性

首先分布式系統(tǒng)一定是大規(guī)模的系統(tǒng),有很好的Scalability。出于成本的考慮,很多大規(guī)模的分布式系統(tǒng)一般采用廉價(jià)的PC服務(wù)器,而不是大型的高性能服務(wù)器。

沒(méi)有單點(diǎn)失效

廉價(jià)的PC服務(wù)器在大規(guī)模使用中經(jīng)常會(huì)遇到各種各樣的問(wèn)題,PC服務(wù)器的硬件不可能是高可靠的,比如Google的數(shù)據(jù)中心每天都會(huì)有大量的硬盤(pán)失效,所以分布式系統(tǒng)一定要對(duì)硬件容錯(cuò),保證沒(méi)有任何的單點(diǎn)失效。在這種很不穩(wěn)定、很不可靠的硬件計(jì)算環(huán)境下,搭建一個(gè)分布式系統(tǒng)提供高可靠服務(wù),必須要通過(guò)軟件來(lái)容錯(cuò)。分布式系統(tǒng)針對(duì)不允許有單點(diǎn)失效的要求有兩方面的設(shè)計(jì)考慮,一種是服務(wù)類的企業(yè)級(jí)應(yīng)用,每個(gè)服務(wù)后臺(tái)實(shí)例都要有多個(gè)副本,一兩臺(tái)硬件故障不至于影響所有服務(wù)實(shí)例;另外一種數(shù)據(jù)存儲(chǔ)的應(yīng)用,每份數(shù)據(jù)也必須要有多個(gè)備份,保證即使某幾個(gè)硬件壞掉了數(shù)據(jù)也不會(huì)丟失。

高可靠性

除了單點(diǎn)失效,還要保證高可靠性。在分布式環(huán)境下,針對(duì)企業(yè)級(jí)服務(wù)應(yīng)用,要做負(fù)載均衡和服務(wù)發(fā)現(xiàn)來(lái)保證高可靠性;針對(duì)數(shù)據(jù)服務(wù),為了做到高可靠性,首先要按照某種算法來(lái)把整體數(shù)據(jù)分片(因?yàn)橐慌_(tái)服務(wù)器裝不下),然后按照同樣的算法來(lái)進(jìn)行分片查找。

數(shù)據(jù)本地性

再一個(gè)分布式設(shè)計(jì)理念是數(shù)據(jù)本地性,因?yàn)榫W(wǎng)絡(luò)通信開(kāi)銷是分布式系統(tǒng)的瓶頸,要減少網(wǎng)絡(luò)開(kāi)銷,應(yīng)當(dāng)讓計(jì)算任務(wù)去找數(shù)據(jù),而不是讓數(shù)據(jù)去找計(jì)算。

分布式系統(tǒng)與Linux操作系統(tǒng)的比較

由于縱向拓展可優(yōu)化空間太?。▎闻_(tái)服務(wù)器的性能上限很明顯),分布式系統(tǒng)強(qiáng)調(diào)橫向擴(kuò)展、橫向優(yōu)化,當(dāng)分布式集群計(jì)算資源不足時(shí),就要往集群里面添加服務(wù)器,來(lái)不停地提升分布式集群的計(jì)算能力。分布式系統(tǒng)要做到統(tǒng)一管理集群的所有服務(wù)器,屏蔽底層管理細(xì)節(jié),諸如容錯(cuò)、調(diào)度、通信等,讓開(kāi)發(fā)人員覺(jué)得分布式集群在邏輯上是一臺(tái)服務(wù)器。

和單機(jī)Linux操作系統(tǒng)相比,雖然分布式系統(tǒng)還沒(méi)有成熟到成為“分布式操作系統(tǒng)”,但它和單機(jī)Linux一樣要解決五大類操作系統(tǒng)必需的功能,即資源分配、進(jìn)程管理、任務(wù)調(diào)度、進(jìn)程間通信(IPC)和文件系統(tǒng),可分別由Mesos、Docker、Marathon/Chronos、RabbitMQ和HDFS/Ceph來(lái)解決,對(duì)應(yīng)于Linux下的Linux Kernel、Linux Kernel、init.d/cron、Pipe/Socket和ext4,如圖1所示。

  圖1 分布式系統(tǒng)與Linux操作系統(tǒng)的比較

基于Mesos的分布式計(jì)算平臺(tái)

Mesos資源分配原理

目前我們的Mesos集群部署在公有云服務(wù)上,用100多臺(tái)虛擬機(jī)組成Mesos集群。Mesos不要求計(jì)算節(jié)點(diǎn)是物理服務(wù)器還是虛擬服務(wù)器,只要是Linux操作系統(tǒng)就可以。Mesos可以理解成一個(gè)分布式的Kernel,只分配集群計(jì)算資源,不負(fù)責(zé)任務(wù)調(diào)度?;贛esos之上可以運(yùn)行不同的分布式計(jì)算平臺(tái),如Spark、Storm、Hadoop、Marathon和Chronos等。Spark、Storm和Hadoop這樣的計(jì)算平臺(tái)有任務(wù)調(diào)度功能,可以直接使用Mesos SDK跟Mesos請(qǐng)求資源,然后自行調(diào)度計(jì)算任務(wù),并對(duì)硬件容錯(cuò)。Marathon針對(duì)服務(wù)型分布式應(yīng)用提供任務(wù)調(diào)度,比如企業(yè)網(wǎng)站等這類需要長(zhǎng)時(shí)間運(yùn)行的服務(wù)。通常網(wǎng)站應(yīng)用程序沒(méi)有任務(wù)調(diào)度和容錯(cuò)能力,因?yàn)榫W(wǎng)站程序不太會(huì)處理某個(gè)后臺(tái)實(shí)例掛掉以后要在哪臺(tái)機(jī)器上重新恢復(fù)等這類復(fù)雜問(wèn)題。這類沒(méi)有任務(wù)調(diào)度能力的服務(wù)型分布式應(yīng)用,可以由Marathon來(lái)負(fù)責(zé)調(diào)度。比如,Marathon調(diào)度執(zhí)行了網(wǎng)站服務(wù)的一百個(gè)后臺(tái)實(shí)例,如果某個(gè)實(shí)例掛掉了,Marathon會(huì)在其他服務(wù)器上把這個(gè)實(shí)例恢復(fù)起來(lái)。Chronos是針對(duì)分布式批處理應(yīng)用提供任務(wù)調(diào)度,比如定期處理日志或者定期調(diào)Hadoop等離線任務(wù)。

Mesos最大的好處是能夠?qū)Ψ植际郊鹤黾?xì)粒度資源分配。如圖2所示,左邊是粗粒的資源分配,右邊是細(xì)粒的資源分配。

  圖2 Mesos資源調(diào)度的兩種方式

圖2左邊有三個(gè)集群,每個(gè)集群三臺(tái)服務(wù)器,分別裝三種分布式計(jì)算平臺(tái),比如上面裝三臺(tái)Hadoop,中間三臺(tái)是Spark,下面三臺(tái)是Storm,三個(gè)不同的框架分別進(jìn)行管理。右邊是Mesos集群統(tǒng)一管理9臺(tái)服務(wù)器,所有來(lái)自Spark、Hadoop或Storm的任務(wù)都在9臺(tái)服務(wù)器上混合運(yùn)行。Mesos首先提高了資源冗余率。粗粒資源管理肯定帶來(lái)一定的浪費(fèi),細(xì)粒的資源提高資源管理能力。Hadoop機(jī)器很清閑,Spark沒(méi)有安裝,但Mesos可以只要任何一個(gè)調(diào)度馬上響應(yīng)。最后一個(gè)還有數(shù)據(jù)穩(wěn)定性,因?yàn)樗?臺(tái)都被Mesos統(tǒng)一管理,假如說(shuō)裝的Hadoop,Mesos會(huì)集群調(diào)度。這個(gè)計(jì)算資源都不共享,存儲(chǔ)之間也不好共享。如果這上面跑了Spark做網(wǎng)絡(luò)數(shù)據(jù)遷移,顯然很影響速度。然后資源分配的方法就是resource offers,是在窗口的可調(diào)度的資源自己去選,Mesos是Spark或者是Hadoop等等。這種方法,Mesos的分配邏輯就很簡(jiǎn)單,只要不停地報(bào)告哪些是可用資源就可以了。Mesos資源分配方法也有一個(gè)潛在的缺點(diǎn),就是無(wú)中心化的分配方式,所以有可能不會(huì)帶來(lái)全局最優(yōu)的方式。但這個(gè)數(shù)據(jù)資源缺點(diǎn)對(duì)目前來(lái)講并不是很?chē)?yán)重?,F(xiàn)在一個(gè)計(jì)算中心資源貢獻(xiàn)率很難達(dá)到50%,絕大部分計(jì)算中心都是很閑的狀態(tài)。

Mesos資源分配示例

下面具體舉例說(shuō)明怎么用Mesos資源分配。如圖3所示,中間是Mesos Master,下面是Mesos Slave,上面是Spark和Hadoop運(yùn)行在Mesos之上。Mesos Master把可用資源報(bào)告給Spark或Hadoop。假定Hadoop有一個(gè)任務(wù)想運(yùn)行,Hadoop從Mesos Master上報(bào)的可用資源中選擇某個(gè)Mesos Slave節(jié)點(diǎn),然后這個(gè)任務(wù)就會(huì)在這個(gè)Mesos Slave節(jié)點(diǎn)上執(zhí)行,這是任務(wù)完成一次資源分配,接下來(lái)Mesos Master繼續(xù)進(jìn)行資源分配。

  圖3 Mesos資源分配示例

任務(wù)調(diào)度

Mesos只做一件事情,就是分布式集群資源分配,不管任務(wù)調(diào)度。Marathon和Chonos是基于Mesos來(lái)做任務(wù)調(diào)度。如圖4所示,Mesos集群混合運(yùn)行來(lái)自Marathon和Chronos的不同類型的任務(wù)。Marathon和Chonos基于Mesos做任務(wù)調(diào)度時(shí),一定是動(dòng)態(tài)調(diào)度,也就是每個(gè)任務(wù)在執(zhí)行之前是不知道它將來(lái)在哪一臺(tái)服務(wù)器上執(zhí)行和綁定哪一個(gè)端口。如圖5所示,9臺(tái)服務(wù)器組成的Mesos集群上混合運(yùn)行各種Marathon調(diào)度的任務(wù),中間一臺(tái)服務(wù)器壞掉以后,這臺(tái)服務(wù)器上的兩個(gè)任務(wù)就受影響,然后Marathon把這兩個(gè)任務(wù)遷移到其他服務(wù)器上,這就是動(dòng)態(tài)任務(wù)調(diào)度帶來(lái)的好處,非常容易實(shí)現(xiàn)容錯(cuò)。

  圖4 Mesos集群運(yùn)行不同類型的任務(wù)

  圖5 Marathon動(dòng)態(tài)任務(wù)調(diào)度

為了減少硬件故障對(duì)應(yīng)用服務(wù)的影響,應(yīng)用程序要盡量做到無(wú)狀態(tài)。無(wú)狀態(tài)的好處是在程序受到影響時(shí)不需要進(jìn)行任何恢復(fù),這樣這個(gè)程序只要重新調(diào)度起來(lái)就可以。無(wú)狀態(tài)要求把狀態(tài)數(shù)據(jù)放到存儲(chǔ)服務(wù)器或者是消息隊(duì)列里面,這樣的好處是容錯(cuò)時(shí)恢復(fù)起來(lái)會(huì)變得很方便。

服務(wù)類的高可靠性

對(duì)于服務(wù)類型的任務(wù),分布式環(huán)境保證服務(wù)的高可靠性,這需要負(fù)載均衡和服務(wù)發(fā)現(xiàn)。在分布式環(huán)境下做負(fù)載均衡有一個(gè)難點(diǎn)就是后臺(tái)這些實(shí)例有可能發(fā)生動(dòng)態(tài)變化,比如說(shuō)某一個(gè)節(jié)點(diǎn)壞掉了,這個(gè)節(jié)點(diǎn)上的實(shí)例會(huì)受到影響,然后遷移到其他節(jié)點(diǎn)上。然而傳統(tǒng)負(fù)載均衡器的后臺(tái)實(shí)例地址端口都是靜態(tài)的。所以在分布式環(huán)境下,為了做負(fù)載均衡一定要做服務(wù)發(fā)現(xiàn)。比如,某個(gè)服務(wù)之前有四個(gè)事例,現(xiàn)在新添加了兩個(gè)實(shí)例,需要告訴負(fù)載均衡器新增加的實(shí)例的地址和端口。服務(wù)發(fā)現(xiàn)的過(guò)程是由幾個(gè)模塊配合完成,比如說(shuō)Marathon給某個(gè)服務(wù)增加了新的實(shí)例,把新調(diào)度的實(shí)例地址端口寫(xiě)到Zookeeper,然后Bamboo把Zookeeper里存放的該服務(wù)新的實(shí)例的地址端口信息告訴負(fù)載均衡器,這樣負(fù)載均衡器就知道新的實(shí)例地址端口,完成了服務(wù)發(fā)現(xiàn)。

數(shù)據(jù)類的高可靠性

對(duì)于服務(wù)類型的應(yīng)用,分布式系統(tǒng)用負(fù)載均衡器和服務(wù)發(fā)現(xiàn)來(lái)保證高可靠性的服務(wù)。對(duì)于數(shù)據(jù)類型的應(yīng)用,分布式系統(tǒng)同樣要保證高可靠的數(shù)據(jù)服務(wù)。首先要做數(shù)據(jù)分片,一臺(tái)服務(wù)器存不下所有數(shù)據(jù)就分成多份來(lái)存,但對(duì)數(shù)據(jù)進(jìn)行分片必須按照某個(gè)規(guī)則來(lái)進(jìn)行分片,后面查找時(shí)要按照同樣的規(guī)則來(lái)進(jìn)行分片查找,就是一致性。假定最原始的方案我們用Hash計(jì)算做成方法,在線性空間上分了三份以后,我要在數(shù)據(jù)分成三塊機(jī)器來(lái)存,三臺(tái)機(jī)器都存滿了時(shí),再把數(shù)據(jù)進(jìn)行分配的時(shí)候不再把它分配到直線線性空間上,而是把它分配到環(huán)狀空間上,把起點(diǎn)和終點(diǎn)連接起來(lái),連成一個(gè)數(shù)據(jù)環(huán),如圖6所示,這樣相應(yīng)的數(shù)據(jù)點(diǎn)就放在這一塊。如果要添加一個(gè)新的數(shù)據(jù)中心就在環(huán)上新切出來(lái)這塊,這樣很方便,切出來(lái)這一部分代表這一部分?jǐn)?shù)據(jù)都應(yīng)該放到新的芯片上,所以把原來(lái)子數(shù)據(jù)分片挪到嵌入式的分片上。

  圖6 數(shù)據(jù)分片

還有可能刪除數(shù)據(jù),我們把黃色的數(shù)據(jù)放到紅色的數(shù)據(jù)上,這是環(huán)的好處。實(shí)際為了做到高可靠性,任何一個(gè)數(shù)據(jù)可能假定映射到黃色部分以后,這些黃色的部分只要映射到任何一個(gè)黃色的區(qū)域都會(huì)存在同一片機(jī)器上,同一片機(jī)器底層會(huì)有多個(gè)副本和做數(shù)據(jù)的備份,這是實(shí)際數(shù)據(jù)分片的一個(gè)實(shí)例。這是怎么做數(shù)據(jù)的高可靠性。這些數(shù)據(jù)分片,還有負(fù)載均衡,都是為了對(duì)應(yīng)分布式分片硬件帶來(lái)的不可靠和失效,這是我們用分布式系統(tǒng)最大的特點(diǎn)。

基于Docker的分布式計(jì)算平臺(tái)

Docker工作流

我們主要用Docker來(lái)做分布式環(huán)境下的進(jìn)程管理。Docker工作流如圖7所示,我們不僅把Docker應(yīng)用到生產(chǎn)階段,也應(yīng)用到開(kāi)發(fā)階段,所以我們每天編輯Dockerfile,提升Docker Images,測(cè)試上線,發(fā)Docker鏡像,在我們內(nèi)部私有Docker regis里面,再調(diào)到我們Docker集群生產(chǎn)環(huán)境里面,這和其他的Docker工作流沒(méi)有什么區(qū)別。

  圖7 Docker工作流

在Mesos提交Docker任務(wù)

因?yàn)镸esos和Docker已經(jīng)是無(wú)縫結(jié)合起來(lái)。通過(guò)Marathon和Chronos提交服務(wù)型應(yīng)用和批處理型應(yīng)用。Marathon和Chronos通過(guò)RESTful的方式提交任務(wù),用JSON腳本設(shè)定應(yīng)用的后臺(tái)實(shí)例個(gè)數(shù)、應(yīng)用的參數(shù)、以及Docker Images的路徑等等。

分布式環(huán)境下的進(jìn)程通信

在分布式環(huán)境下應(yīng)用服務(wù)之間通信,是用分布式消息隊(duì)列來(lái)做,我們用的是RabbitMQ。RabbitMQ也是一個(gè)分布式系統(tǒng),它也要保證高可靠性、解決容錯(cuò)的問(wèn)題。首先RabbitMQ也有集群,如圖8所示,六個(gè)節(jié)點(diǎn)組成了一個(gè)RabbitMQ的集群,每個(gè)節(jié)點(diǎn)之間是互為備份的關(guān)系,任何一個(gè)壞掉,其他五個(gè)還可以提供服務(wù),通過(guò)冗余來(lái)保證RabbitMQ的高可靠性。

  圖8 RabbitMQ集群

其次,RabbitMQ也有數(shù)據(jù)分片機(jī)制。因?yàn)橄㈥?duì)列有可能很長(zhǎng),長(zhǎng)到所有的消息不可能都放到一個(gè)節(jié)點(diǎn)上,這時(shí)就要用分片,把很長(zhǎng)的消息隊(duì)列分為幾段,分別放到不同的節(jié)點(diǎn)上。如圖9所示是RabbitMQ的聯(lián)盟機(jī)制,把一個(gè)消息隊(duì)列打成兩段,一段放在上游一段放在下游,假定下游消息隊(duì)列的消息被消費(fèi)完了就自動(dòng)把上游消息隊(duì)列里的消息移到下游,這樣一個(gè)消息隊(duì)列變成非常長(zhǎng)的時(shí)候也不怕,分片到多個(gè)節(jié)點(diǎn)上即可。

  圖9 消息隊(duì)列分片

分布式文件系統(tǒng)

最后講一下分布式文件系統(tǒng)HDFS和Ceph。Hadoop文件系統(tǒng)HDFS,如圖10所示,每個(gè)數(shù)據(jù)塊有三個(gè)備份,必須放在不同的服務(wù)器上,而且三個(gè)備份里面每個(gè)機(jī)架最多放兩份,這么做也是為了容錯(cuò)。Ceph是另一種流行的開(kāi)源分布式文件系統(tǒng)。Ceph把網(wǎng)絡(luò)存儲(chǔ)設(shè)備抽象成一張邏輯硬盤(pán),然后“掛載”到分布式集群的每臺(tái)服務(wù)器上,原理上非常像是Linux操作系統(tǒng)Mount一塊物理硬盤(pán)。這樣一來(lái),用戶程序訪問(wèn)Ceph的文件系統(tǒng)就跟訪問(wèn)Linux本地路徑一樣,非常方便。

  圖10 分布式文件系統(tǒng)

分布式環(huán)境下的監(jiān)控

分布式環(huán)境下,程序不是運(yùn)行在本地,而是在集群上面,沒(méi)有監(jiān)控就等于程序運(yùn)行在黑盒子下,無(wú)法調(diào)優(yōu),必須要有監(jiān)控。分布式環(huán)境下的監(jiān)控分為兩個(gè)部分,一是性能監(jiān)控,另一個(gè)是報(bào)警。性能監(jiān)控要知道每個(gè)應(yīng)用程序運(yùn)行狀態(tài)是什么樣,即每一個(gè)應(yīng)用程序占了多少CPU內(nèi)存、服務(wù)的請(qǐng)求處理延遲等。我們是用Graphite來(lái)做應(yīng)用程序性能監(jiān)控;還有其他系統(tǒng),比如MongoDB、Hadoop等開(kāi)源系統(tǒng),我們用Ganglia來(lái)做性能監(jiān)控,比如CPU內(nèi)存硬盤(pán)的使用情況等。報(bào)警是要在關(guān)鍵服務(wù)出現(xiàn)故障時(shí),通知開(kāi)發(fā)運(yùn)維人員及時(shí)排解故障,我們用Zabbix來(lái)做報(bào)警。(責(zé)編/周建丁)

作者簡(jiǎn)介:王璞,先后在硅谷供職于StumbleUpon、Groupon和Google,擅長(zhǎng)海量數(shù)據(jù)處理、分布式計(jì)算以及大規(guī)模機(jī)器學(xué)習(xí)。2014年回國(guó)創(chuàng)辦數(shù)人科技,基于Mesos和Docker構(gòu)建分布式計(jì)算平臺(tái),為企業(yè)客戶提供大數(shù)據(jù)分析處理一站式解決方案。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號(hào)-6京公網(wǎng)安備 11010502049343號(hào)