分布式操作系統(tǒng)Yarn
分布式操作系統(tǒng)Yarn
基于Yarn的分布式操作系統(tǒng)我們要怎么構(gòu)想呢?下面由學(xué)習(xí)啦小編為大家整理了分布式操作系統(tǒng)Yarn相關(guān)知識(shí),希望對(duì)大家有幫助!
基于Yarn的分布式操作系統(tǒng)
前言
很多東西都不是突然被發(fā)明的,一定會(huì)有積累的過程,也就是說他依賴的一些關(guān)鍵技術(shù)得到解決,這好比燃燒,一定要到了燃點(diǎn)才能燒的起來。
比如,深度學(xué)習(xí),很早之前就提出來了,但是現(xiàn)在才火起來,究其原因,是因?yàn)閯偺岢鰜淼臅r(shí)候有兩個(gè)硬性條件當(dāng)時(shí)達(dá)不到
計(jì)算能力不足(現(xiàn)在GPU都搞起來了,而且動(dòng)則幾千臺(tái)服務(wù)器,單機(jī)服務(wù)器性能也提升不是一丁點(diǎn))
數(shù)據(jù)規(guī)模(如果數(shù)據(jù)太少,解決不了過擬合問題)
隨著大數(shù)據(jù)以及計(jì)算機(jī)計(jì)算能力的發(fā)展,條件具備了,才讓現(xiàn)在的深度學(xué)習(xí)成為可能。
同樣的,關(guān)于分布式操作系統(tǒng),很早就被提出來了,但是卻一直沒有被實(shí)現(xiàn),也沒有被重視,原因也在此,以前的條件不具備,但是現(xiàn)在具備了。
同樣的,關(guān)于分布式操作系統(tǒng),很早就被提出來了,但是卻一直沒有被實(shí)現(xiàn),也沒有被重視,原因也在此,以前的條件不具備,但是現(xiàn)在具備了。
現(xiàn)在國內(nèi)有人在提‘數(shù)據(jù)分布式操作系統(tǒng)’,基于Mesos來實(shí)現(xiàn)的,完成了一套大數(shù)據(jù)棧的集成,為分布式操作系統(tǒng)賣出了比較堅(jiān)實(shí)的一步。
分布式操作系統(tǒng)組件
作為一個(gè)分布式操作系統(tǒng),我們看看到都有哪些組件:
分布式調(diào)度內(nèi)核 (Yarn,通常我們會(huì)將Yarn再Wrap一層,也就是說Yarn是內(nèi)核,再Wrap的那一層就是用戶層了)
分布式文件系統(tǒng) (HDFS)
進(jìn)程模型 (Docker容器)
服務(wù)注冊API(Zookeeper)
進(jìn)程異步通訊模型(消息隊(duì)列)
進(jìn)程通訊模型(HTTP/RPC)
系統(tǒng)組件(針對(duì)Yarn編程即可)
應(yīng)用程序(Web,MySQl,Hadoop/Spark等)
UI系統(tǒng)(Web化可視界面)
在分布式系統(tǒng)中,一個(gè)應(yīng)用的計(jì)算能力是通過多進(jìn)程多線程協(xié)調(diào)來完成的。而單機(jī)的應(yīng)用則更多的是依賴于多線程來完成。
進(jìn)程的交互一般避免使用共享內(nèi)存,而是通過‘進(jìn)程異步通訊模型’中的消息隊(duì)列,或者直接通過HTTP/RPC來完成進(jìn)程之間通訊。
進(jìn)程通訊無法直接感知對(duì)方,而必須通過分布式系統(tǒng)的內(nèi)核級(jí)別服務(wù)’服務(wù)注冊API’來完成。
Yarn 分布式操作系統(tǒng)調(diào)度內(nèi)核
大資源的概念
我在之前的文章里面提到:
未來應(yīng)用服務(wù)的話,也應(yīng)該是放到一個(gè)資源池中,而不是傳統(tǒng)的單一應(yīng)用池。比如現(xiàn)在很多公司是把不同的服務(wù)種類單獨(dú)成一個(gè)池子來進(jìn)行維護(hù)管理,其實(shí)是將一個(gè)大池子劃分為N個(gè)小池子,每個(gè)小池子功能比較單一。也就是說,現(xiàn)在的部署模式是大池子的一個(gè)特定實(shí)現(xiàn)而已。通過Yarn將所有的節(jié)點(diǎn)管理起來后,未來部署只是做資源申請,比如我要多少內(nèi)存,多少CPU,啟動(dòng)多少個(gè)實(shí)例,然后Yarn根據(jù)大池子將資源分配出來,啟動(dòng)起來。啟動(dòng)后的實(shí)例都運(yùn)行在Docker容器里。Yarn的資源隔離做的很差的,但是Docker在這塊做的很好。按我剛才說的,如果調(diào)度策略是小池子,單一服務(wù),那么就會(huì)形成現(xiàn)在傳統(tǒng)的部署方式。如果是完全動(dòng)態(tài)彈性的,則看起來會(huì)比較混亂,不同服務(wù)的實(shí)例混合運(yùn)行,但對(duì)機(jī)器來說卻沒有混亂的概念。另外我們基于Yarn也可以完全取代kubernetes,比如完全可以基于Yarn來實(shí)現(xiàn)實(shí)例數(shù)穩(wěn)定的功能。我們可以基于Yarn開發(fā)一套長期運(yùn)行的程序,然后監(jiān)控實(shí)例數(shù),如果實(shí)例低于閾值,則重新做資源申請,保證實(shí)例不低于閾值。
Yarn這種分布式調(diào)度系統(tǒng)有效的將多機(jī)變成了一個(gè)大的資源池,并且提供了一個(gè)很好的編程接口讓你去控制對(duì)應(yīng)的節(jié)點(diǎn)。
其實(shí)很多公司現(xiàn)在的服務(wù)器利用率都很低,因?yàn)闄C(jī)器申請是按峰值來算的,為了保證穩(wěn)定還要溢出25%–50%的計(jì)算/存儲(chǔ)能力,所以一般一個(gè)集群利用率能達(dá)到50%就了不起了。大資源意味著可以動(dòng)態(tài)調(diào)度,極端情況可以在低峰時(shí)引入離線計(jì)算任務(wù),保證了服務(wù)器高利用率。
MapReduce/Spark/MPI等工具在分布式系統(tǒng)的定位
Yarn的可編程性讓我們可以開發(fā)一些系統(tǒng)組件,從而讓系統(tǒng)有了新的能力,比如MapReduce/Spark 等,讓分布式系統(tǒng)有了執(zhí)行批量離線(或者準(zhǔn)實(shí)時(shí))的功能。我們認(rèn)為這是對(duì)分布式系統(tǒng)的一種增強(qiáng)。因?yàn)檫@套應(yīng)用是直接基于分布式系統(tǒng)內(nèi)核編程的。
分布式系統(tǒng)的自動(dòng)容量規(guī)劃機(jī)制
我們發(fā)現(xiàn)單機(jī)桌面軟件運(yùn)行時(shí),大部分情況是不需要你寫資源申請的。而事實(shí)上,即使在實(shí)際的線上部署,部署者也很難確切的知道我應(yīng)該要多少CPU,多少內(nèi)存比較合理,當(dāng)然,磁盤理論可以預(yù)估的。
前面我們提到,類似于Windows的注冊表,一個(gè)進(jìn)程啟動(dòng)后需要將自己告知系統(tǒng),而且他如果要調(diào)用其他的進(jìn)程需要通過分布式系統(tǒng)的注冊API來完成,一旦獲得依賴的其他進(jìn)程信息,則通過操作系統(tǒng)提供的異步通訊模型-消息隊(duì)列,或者直接的通訊模型(HTTP/RPC)來完成實(shí)際的數(shù)據(jù)傳遞。
由此,我們可以知道,當(dāng)一個(gè)服務(wù)被啟動(dòng),分布式系統(tǒng)很容獲取到這個(gè)應(yīng)用的依賴,包括對(duì)外的RPC調(diào)用,Http調(diào)用,數(shù)據(jù)庫調(diào)用,緩存調(diào)用(比如在ServiceFramework里,這些調(diào)用關(guān)系是可以通過配置文件靜態(tài)分析出來的)。這和安卓一樣,一個(gè)應(yīng)用需要申明他是否需要聯(lián)網(wǎng),是否需要自啟動(dòng),是否需要XXX。用戶只需要提供一個(gè)預(yù)估調(diào)用量,或者需要他能承受的一個(gè)調(diào)用量給系統(tǒng),系統(tǒng)結(jié)合這些數(shù)值,可以自動(dòng)計(jì)算出需要啟動(dòng)多少個(gè)容器,配置多少CPU,多少內(nèi)存,計(jì)算的方式非常多,其中還有一個(gè)小技巧,是可以參看有著類似外部依賴的已經(jīng)部署在線上的服務(wù),參看他的數(shù)值。當(dāng)然,用戶也可以直接通過配置文件告訴系統(tǒng)自己需要的資源申請。
系統(tǒng)一旦計(jì)算出來后,用戶確認(rèn)即可,防止出現(xiàn)錯(cuò)誤,這個(gè)時(shí)候,系統(tǒng)采用的是貪婪算法,它會(huì)采用比預(yù)估值大一倍的容量來啟動(dòng)這個(gè)服務(wù)群集。接著根據(jù)實(shí)際運(yùn)行結(jié)果,比如一周的運(yùn)行數(shù)據(jù)(各個(gè)容器的CPU,內(nèi)存等)),來確定一個(gè)更合適的值,這個(gè)時(shí)候可以通過服務(wù)的自動(dòng)伸縮性來解決減少服務(wù)的。
服務(wù)注冊API(Zookeeper)
我們都知道Windows有注冊表,而Linux則是通過一些環(huán)境變量甚至默認(rèn)的存儲(chǔ)路徑來讓一個(gè)應(yīng)用可以感知到另一個(gè)應(yīng)用。
在分布式操作系統(tǒng)中,對(duì)應(yīng)的組件API是Zookeeper?,F(xiàn)在有大量的應(yīng)用依賴于Zookeeper,從而實(shí)現(xiàn)進(jìn)程之間的消息互通,實(shí)現(xiàn)協(xié)調(diào)。所以把Zookeeper變成注冊表的標(biāo)準(zhǔn)實(shí)現(xiàn),我想也不為過。
進(jìn)程模型
分布式系統(tǒng)中,任何應(yīng)用都需要被被容器給包裹后才能運(yùn)行(除了一些系統(tǒng)組件除外)。容器解決了分布式系統(tǒng)中的資源隔離,環(huán)境打包兩個(gè)非常重要的特性。因?yàn)榉植际较到y(tǒng)大資源池的概念使得多租戶是必須的。