分布式操作系統(tǒng)Yarn

　　基于Yarn的分布式操作系統(tǒng)我們要怎么構(gòu)想呢?下面由學(xué)習(xí)啦小編為大家整理了分布式操作系統(tǒng)Yarn相關(guān)知識(shí)，希望對(duì)大家有幫助!

　　基于Yarn的分布式操作系統(tǒng)

　　前言

　　很多東西都不是突然被發(fā)明的，一定會(huì)有積累的過(guò)程，也就是說(shuō)他依賴的一些關(guān)鍵技術(shù)得到解決，這好比燃燒，一定要到了燃點(diǎn)才能燒的起來(lái)。

　　比如，深度學(xué)習(xí)，很早之前就提出來(lái)了，但是現(xiàn)在才火起來(lái)，究其原因，是因?yàn)閯偺岢鰜?lái)的時(shí)候有兩個(gè)硬性條件當(dāng)時(shí)達(dá)不到

　　計(jì)算能力不足(現(xiàn)在GPU都搞起來(lái)了，而且動(dòng)則幾千臺(tái)服務(wù)器，單機(jī)服務(wù)器性能也提升不是一丁點(diǎn))

　　數(shù)據(jù)規(guī)模(如果數(shù)據(jù)太少，解決不了過(guò)擬合問題)

　　隨著大數(shù)據(jù)以及計(jì)算機(jī)計(jì)算能力的發(fā)展，條件具備了，才讓現(xiàn)在的深度學(xué)習(xí)成為可能。

　　同樣的，關(guān)于分布式操作系統(tǒng)，很早就被提出來(lái)了，但是卻一直沒有被實(shí)現(xiàn)，也沒有被重視，原因也在此，以前的條件不具備，但是現(xiàn)在具備了。

　　同樣的，關(guān)于分布式操作系統(tǒng)，很早就被提出來(lái)了，但是卻一直沒有被實(shí)現(xiàn)，也沒有被重視，原因也在此，以前的條件不具備，但是現(xiàn)在具備了。

　　現(xiàn)在國(guó)內(nèi)有人在提‘數(shù)據(jù)分布式操作系統(tǒng)’，基于Mesos來(lái)實(shí)現(xiàn)的，完成了一套大數(shù)據(jù)棧的集成，為分布式操作系統(tǒng)賣出了比較堅(jiān)實(shí)的一步。

　　分布式操作系統(tǒng)組件

　　作為一個(gè)分布式操作系統(tǒng)，我們看看到都有哪些組件：

　　分布式調(diào)度內(nèi)核 (Yarn，通常我們會(huì)將Yarn再Wrap一層，也就是說(shuō)Yarn是內(nèi)核，再Wrap的那一層就是用戶層了)

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

　　進(jìn)程模型 (Docker容器)

　　服務(wù)注冊(cè)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ì)算能力是通過(guò)多進(jìn)程多線程協(xié)調(diào)來(lái)完成的。而單機(jī)的應(yīng)用則更多的是依賴于多線程來(lái)完成。

　　進(jìn)程的交互一般避免使用共享內(nèi)存，而是通過(guò)‘進(jìn)程異步通訊模型’中的消息隊(duì)列，或者直接通過(guò)HTTP/RPC來(lái)完成進(jìn)程之間通訊。

　　進(jìn)程通訊無(wú)法直接感知對(duì)方，而必須通過(guò)分布式系統(tǒng)的內(nèi)核級(jí)別服務(wù)’服務(wù)注冊(cè)API’來(lái)完成。

　　Yarn 分布式操作系統(tǒng)調(diào)度內(nèi)核

　　大資源的概念

　　我在之前的文章里面提到：

　　未來(lái)應(yīng)用服務(wù)的話，也應(yīng)該是放到一個(gè)資源池中，而不是傳統(tǒng)的單一應(yīng)用池。比如現(xiàn)在很多公司是把不同的服務(wù)種類單獨(dú)成一個(gè)池子來(lái)進(jìn)行維護(hù)管理，其實(shí)是將一個(gè)大池子劃分為N個(gè)小池子，每個(gè)小池子功能比較單一。也就是說(shuō)，現(xiàn)在的部署模式是大池子的一個(gè)特定實(shí)現(xiàn)而已。通過(guò)Yarn將所有的節(jié)點(diǎn)管理起來(lái)后，未來(lái)部署只是做資源申請(qǐng)，比如我要多少內(nèi)存，多少CPU,啟動(dòng)多少個(gè)實(shí)例，然后Yarn根據(jù)大池子將資源分配出來(lái)，啟動(dòng)起來(lái)。啟動(dòng)后的實(shí)例都運(yùn)行在Docker容器里。Yarn的資源隔離做的很差的，但是Docker在這塊做的很好。按我剛才說(shuō)的，如果調(diào)度策略是小池子，單一服務(wù)，那么就會(huì)形成現(xiàn)在傳統(tǒng)的部署方式。如果是完全動(dòng)態(tài)彈性的，則看起來(lái)會(huì)比較混亂，不同服務(wù)的實(shí)例混合運(yùn)行，但對(duì)機(jī)器來(lái)說(shuō)卻沒有混亂的概念。另外我們基于Yarn也可以完全取代kubernetes,比如完全可以基于Yarn來(lái)實(shí)現(xiàn)實(shí)例數(shù)穩(wěn)定的功能。我們可以基于Yarn開發(fā)一套長(zhǎng)期運(yùn)行的程序，然后監(jiān)控實(shí)例數(shù)，如果實(shí)例低于閾值，則重新做資源申請(qǐng)，保證實(shí)例不低于閾值。

　　Yarn這種分布式調(diào)度系統(tǒng)有效的將多機(jī)變成了一個(gè)大的資源池，并且提供了一個(gè)很好的編程接口讓你去控制對(duì)應(yīng)的節(jié)點(diǎn)。

　　其實(shí)很多公司現(xiàn)在的服務(wù)器利用率都很低，因?yàn)闄C(jī)器申請(qǐng)是按峰值來(lái)算的，為了保證穩(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ī)劃?rùn)C(jī)制

　　我們發(fā)現(xiàn)單機(jī)桌面軟件運(yùn)行時(shí)，大部分情況是不需要你寫資源申請(qǐng)的。而事實(shí)上，即使在實(shí)際的線上部署，部署者也很難確切的知道我應(yīng)該要多少CPU,多少內(nèi)存比較合理，當(dāng)然，磁盤理論可以預(yù)估的。

　　前面我們提到，類似于Windows的注冊(cè)表，一個(gè)進(jìn)程啟動(dòng)后需要將自己告知系統(tǒng)，而且他如果要調(diào)用其他的進(jìn)程需要通過(guò)分布式系統(tǒng)的注冊(cè)API來(lái)完成，一旦獲得依賴的其他進(jìn)程信息，則通過(guò)操作系統(tǒng)提供的異步通訊模型-消息隊(duì)列，或者直接的通訊模型(HTTP/RPC)來(lái)完成實(shí)際的數(shù)據(jù)傳遞。

　　由此，我們可以知道，當(dāng)一個(gè)服務(wù)被啟動(dòng)，分布式系統(tǒng)很容獲取到這個(gè)應(yīng)用的依賴，包括對(duì)外的RPC調(diào)用,Http調(diào)用，數(shù)據(jù)庫(kù)調(diào)用，緩存調(diào)用(比如在ServiceFramework里，這些調(diào)用關(guān)系是可以通過(guò)配置文件靜態(tài)分析出來(lá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)然，用戶也可以直接通過(guò)配置文件告訴系統(tǒng)自己需要的資源申請(qǐng)。

　　系統(tǒng)一旦計(jì)算出來(lái)后，用戶確認(rèn)即可，防止出現(xiàn)錯(cuò)誤，這個(gè)時(shí)候，系統(tǒng)采用的是貪婪算法，它會(huì)采用比預(yù)估值大一倍的容量來(lái)啟動(dòng)這個(gè)服務(wù)群集。接著根據(jù)實(shí)際運(yùn)行結(jié)果，比如一周的運(yùn)行數(shù)據(jù)(各個(gè)容器的CPU,內(nèi)存等))，來(lái)確定一個(gè)更合適的值，這個(gè)時(shí)候可以通過(guò)服務(wù)的自動(dòng)伸縮性來(lái)解決減少服務(wù)的。

　　服務(wù)注冊(cè)API(Zookeeper)

　　我們都知道Windows有注冊(cè)表，而Linux則是通過(guò)一些環(huán)境變量甚至默認(rèn)的存儲(chǔ)路徑來(lái)讓一個(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變成注冊(cè)表的標(biāo)準(zhǔn)實(shí)現(xiàn)，我想也不為過(guò)。

　　進(jìn)程模型

　　分布式系統(tǒng)中，任何應(yīng)用都需要被被容器給包裹后才能運(yùn)行(除了一些系統(tǒng)組件除外)。容器解決了分布式系統(tǒng)中的資源隔離，環(huán)境打包兩個(gè)非常重要的特性。因?yàn)榉植际较到y(tǒng)大資源池的概念使得多租戶是必須的。