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

　　基于Yarn的分布式操作系統(tǒng)我們要怎么構想呢?下面由學習啦小編為大家整理了分布式操作系統(tǒng)Yarn相關知識，希望對大家有幫助!

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

　　前言

　　很多東西都不是突然被發(fā)明的，一定會有積累的過程，也就是說他依賴的一些關鍵技術得到解決，這好比燃燒，一定要到了燃點才能燒的起來。

　　比如，深度學習，很早之前就提出來了，但是現(xiàn)在才火起來，究其原因，是因為剛提出來的時候有兩個硬性條件當時達不到

　　計算能力不足(現(xiàn)在GPU都搞起來了，而且動則幾千臺服務器，單機服務器性能也提升不是一丁點)

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

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

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

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

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

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

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

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

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

　　進程模型 (Docker容器)

　　服務注冊API(Zookeeper)

　　進程異步通訊模型(消息隊列)

　　進程通訊模型(HTTP/RPC)

　　系統(tǒng)組件(針對Yarn編程即可)

　　應用程序(Web,MySQl,Hadoop/Spark等)

　　UI系統(tǒng)(Web化可視界面)

　　在分布式系統(tǒng)中，一個應用的計算能力是通過多進程多線程協(xié)調(diào)來完成的。而單機的應用則更多的是依賴于多線程來完成。

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

　　進程通訊無法直接感知對方，而必須通過分布式系統(tǒng)的內(nèi)核級別服務’服務注冊API’來完成。

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

　　大資源的概念

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

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

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

　　其實很多公司現(xiàn)在的服務器利用率都很低，因為機器申請是按峰值來算的，為了保證穩(wěn)定還要溢出25%–50%的計算/存儲能力，所以一般一個集群利用率能達到50%就了不起了。大資源意味著可以動態(tài)調(diào)度，極端情況可以在低峰時引入離線計算任務，保證了服務器高利用率。

　　MapReduce/Spark/MPI等工具在分布式系統(tǒng)的定位

　　Yarn的可編程性讓我們可以開發(fā)一些系統(tǒng)組件，從而讓系統(tǒng)有了新的能力，比如MapReduce/Spark 等，讓分布式系統(tǒng)有了執(zhí)行批量離線(或者準實時)的功能。我們認為這是對分布式系統(tǒng)的一種增強。因為這套應用是直接基于分布式系統(tǒng)內(nèi)核編程的。

　　分布式系統(tǒng)的自動容量規(guī)劃機制

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

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

　　由此，我們可以知道，當一個服務被啟動，分布式系統(tǒng)很容獲取到這個應用的依賴，包括對外的RPC調(diào)用,Http調(diào)用，數(shù)據(jù)庫調(diào)用，緩存調(diào)用(比如在ServiceFramework里，這些調(diào)用關系是可以通過配置文件靜態(tài)分析出來的)。這和安卓一樣，一個應用需要申明他是否需要聯(lián)網(wǎng)，是否需要自啟動，是否需要XXX。用戶只需要提供一個預估調(diào)用量，或者需要他能承受的一個調(diào)用量給系統(tǒng)，系統(tǒng)結(jié)合這些數(shù)值，可以自動計算出需要啟動多少個容器，配置多少CPU,多少內(nèi)存，計算的方式非常多，其中還有一個小技巧，是可以參看有著類似外部依賴的已經(jīng)部署在線上的服務，參看他的數(shù)值。當然，用戶也可以直接通過配置文件告訴系統(tǒng)自己需要的資源申請。

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

　　服務注冊API(Zookeeper)

　　我們都知道Windows有注冊表，而Linux則是通過一些環(huán)境變量甚至默認的存儲路徑來讓一個應用可以感知到另一個應用。

　　在分布式操作系統(tǒng)中，對應的組件API是Zookeeper?，F(xiàn)在有大量的應用依賴于Zookeeper,從而實現(xiàn)進程之間的消息互通，實現(xiàn)協(xié)調(diào)。所以把Zookeeper變成注冊表的標準實現(xiàn)，我想也不為過。

　　進程模型

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