分布式操作系統Yarn

分布式操作系統Yarn

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

　　基于Yarn的分布式操作系統

　　前言

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

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

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

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

　　隨著大數據以及計算機計算能力的發展，條件具備了，才讓現在的深度學習成為可能。

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

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

　　現在國內有人在提‘數據分布式操作系統’，基于Mesos來實現的，完成了一套大數據棧的集成，為分布式操作系統賣出了比較堅實的一步。

　　分布式操作系統組件

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

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

　　分布式文件系統 (HDFS)

　　進程模型 (Docker容器)

　　服務注冊API(Zookeeper)

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

　　進程通訊模型(HTTP/RPC)

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

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

　　UI系統(Web化可視界面)

　　在分布式系統中，一個應用的計算能力是通過多進程多線程協調來完成的。而單機的應用則更多的是依賴于多線程來完成。

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

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

　　Yarn 分布式操作系統調度內核

　　大資源的概念

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

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

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

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

　　MapReduce/Spark/MPI等工具在分布式系統的定位

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

　　分布式系統的自動容量規劃機制

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

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

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

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

　　服務注冊API(Zookeeper)

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

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

　　進程模型

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