2.1SLIDER產生背景
為了解決MR1擴展性差、可靠性差、資源利用率低和無法支持多種計算框架等局限性，Apache社區將其升級了計算框架MRv2。Hadoop將資源管理功能抽象成了一個獨立的通用系統YARN
在以MapReduce為核心的軟件棧中，資源管理系統YARN是可插拔的，比例選擇Mesos替代YARN，一旦MapReduce接口改變，所有的資源管理系統的實現均需要跟著改變。但是以YARN為核心的軟件棧則不同，所有框架都需要實現YARN定義的對外接口以允許在YARN之上，從而形成一個以YARN核心的生態系統。
在YARN中可以運行MapReduce、Spark這樣的短作業，也可以部署向Tomcat、MySQL這種長服務。YARN根據各種計算框架、應用的負載或者需求去調整各自占用的資源，實現集群資源共享計彈性收縮。
開發者為了使YARN支持自己的計算框架或者服務，需要編寫組件Client（客戶端）和ApplicationMaster，向YARN申請資源、任務調度與容錯、網絡容錯，并且要監控各個任務狀態等細節，對開發者要求過高，而且每增加一個框架或者服務都要重新編寫相對應的組件，重復工作；如果想將已有服務運行在YARN中，需要修改服務的代碼，以與YARN框架兼容，代價較大。
為了解決這個問題，Apache社區推出了Slider，其源于Hoya，一個嘗試將HBase運行在YARN中的項目。ApacheSlider目前是孵化項目，可以使用戶在不對已存在服務進行任務修改的情況下部署到YARN集群中，并提供部署、管理及擴展等操作。
同時，Slider可以在集群中部署多版本、異構的應用，每個應用可以根據需求配置不同的參數，在運行過程中動態的擴展或者減少資源的應用，并且對失敗的進程透明的回復。在YARN中，每個應用都以Application的形式運行，每個進程都運，行在Container中，Container目錄中包含了應用的配置、腳本和數據等；在YARN中運行應用，可以使應用充分整合Hadoop生態系統，例如Hadoop數據，計算/存儲資源及安全、管理和操作能力。
2.2SLIDER基礎知識
為了便于下面分析ApacheSlider，本小節對Slider涉及的術語進行比較全面的介紹。
（1)）YARN
YARN是Hadoop2.0中的資源管理系統，它是一個通用的資源管理模塊，可為各類應用程序進行資源管理和調度。YARN不僅局限于MR一種框架使用，也可以提供其他框架，比如TEZ、Spark及Storm等。
（2）Application
可以運行在YARN中的程序都可以成為Application，包括計算框架MapReduce、內存計算、流計算等；常駐服務，如ApacheHBase、Accumulo及Storm等。其中Slider是運行在YARN中用于Application管理的框架，本質也是Application。
（3）Instances
Application程序在YARN中的一次執行，YARNCluster根據應用配置文件啟動的應用實例，實例的狀態可以是運行狀態或者停止狀態，當停止時配置信息或者Instance數據保根據存在HDFS中。同一個Application可以在YARN中同時執行多次（共享相同的服務器）。每個Application
Instance由一個或者多個Componet的集合組成，ApplicationState是Instance的模型，記錄每個Instances的正確狀態、所需要的資源、運行歷史信息等。
（4）Components
Component是ApplicationInstances的組成構件，代表應用的程序的一個運行模塊，例如HBase中的HMaster、HRegionServer、RestServer都可以稱為Component，其以YARNContainer的形式運行在YARN中。不同的Component可以執行不同的程序或者命令，也可以使用不同的配置選項和參數。
（5）Role
ApplicationMaster為了實現對Component（運行在YARNContainer中）進行管理，需要對Component及其Container的實時運行信息進行記錄及更新。Component在ApplicationMaster的映射形式為Role（Server-Siderlogin），其實例化為RoleInstances。SliderAppMaster根據Role的信息進行任務的調度和服務的管理。根據具體的Component不同分為SliderAppMasterRole和ComponentRole。
（6）ServiceRegistry
客戶端需要訪問運行在YARN中的服務，但是客戶端可能運行在集群外，而且運行在YARN中的服務是隨機分配到各個主機上，不可預測而且端口也是隨機的，為了解決這些問題需要引入服務注冊（Service
Registry）。服務的注冊的方式很多，包括ZK、DNS、FloatingIPAddress、LDAP等。
當前Slider使用的方式是YARNServiceRegistry，將YARNApplication的binding信息發布到ZK中，包括IPC端口,Service-aware
URL及配置等，客戶端從ZK中獲取所需要的訪問信息。對于ServiceRegistry，除了ZK，有很多的替代方式，如ApacheCurator、HelixService
Registry,TwillRegistry等，以后會進行詳述。
2.3SLIDER基本架構
Slider將分布式應用以YARNApplication的形式運行在YARN中，其基本設計思想是將分布式應用的服務進程以Container的形式運行在YARN資源管理系統中，客戶端通過與YARN的交互來對應用進行管理。
2.3.1Slider基本組成結構
Slider（YARNApplication）的總體結構仍然是Master/Slave結構，運行在資源管理系統YARN中，SliderAppMaster為Master，SliderAgent為Slave。SliderAppMaster向RM申請資源，并要求NM啟動SlliderAgent進程，Agent根據服務的定義啟動相對應的Component。
圖2-3描述了Slider的基本組成結構，Slider主要由SliderAppMaster、SliderAgent和AppComponent（由LinuxService啟動，可以是Docker或者JVM程序等不同程序），Agent啟動在Container中，但是Component進程由Linux系統啟動，可能會不屬于Cotainer。

圖2-3Apache
Slider的基本架構
根據app的配置解析并生成Application的啟動計劃，SliderAppMaster根據計劃向YARN申請Container(對應一個Component)。在ApplicationInstance啟動后，監控其運行狀態，并當服務的Component因異常停止后，自動恢復。
SliderAppMaster申請到Container后，在Container中啟動SliderAgent進程，Agent向SliderAppMaster注冊并發送心跳信息，Agent根據心跳響應獲取SliderAppMaster發送的命令并執行，包括服務的啟動、停止及其他操作。
每個applicationinstance有一個或者多個Component的集合，每個Component有不同的程序或者命令，使用的配置和參數也會不同，例如HBaseHMaster
component會通過SliderAgent啟動HMasterJVM。當前SliderAgent也支持DockerApp的啟動。
與SliderAppMaster及YARN通過REST或者RPC通信，對外提供CLI和底層API來操作Application
2.3.2Slider通信協議
通信協議是Slider各個組件的大動脈，了解不同組件之間的通信協議有助于更深入的學習Slider框架，其中RPC協議是連接各個組件的“大動脈”，對于RPC，通信雙方有一端是Client，另一端是Server，且Client總是主動連接Server，因此YARN中的組件采用的是pull-based通信模型。另外SliderAppMaster對外提供REST通信方式，主要用于與SliderAgent的心跳與注冊過程，采用的Pull-based通信模型。如圖2-4所示，實線箭頭指向的組件是RPCServer，而箭頭尾部的組件是RCPClient，虛線箭頭指向RESTServer，虛線箭尾指向RESTClient端，由以下部分組成：

圖2-4ApacheSlider的交互協議
1）SliderClient與RM之間的協議——ApplicationClientProtocol;SliderClient通過該RPC協議提交應用程序，查詢應用程序狀態等
2）Admin與RM之間的協議——ResourceManagerAdministrationProtocol；Admin通過該RPC協議更新系統配置文件，比如節點黑白名單，用戶隊列等。
3）AM與RM之間的協議——ApplicationMasterProtocol；AM通過該RPC協議向RM注冊和撤銷自己，并為各個任務申請資源
4）AM與NM之間的協議——ContainerManagementProtocol；AM通過該RPC協議要求NM啟動或者停止Container，獲取各個Container的使用狀態等信息
5）NM與RM之間的協議——ResourceTracker；NM通過向該RPC協議向RM注冊，并定時發送心跳信息匯報當前節點的資源使用情況和Container運行情況
6）SliderClient與AM之間的協議——SliderClusterProtocol；SliderClient通過該RPC協議請求AM進行App的信息的查詢
7）SliderOpUser與AM之間REST協議——ManagementResource、PublisherResource、RegistryResource及ApplicationResource，用戶通過該REST協議進行應用信息的查詢，服務的操作等
8）SliderAgent與AM之間的REST協議——AgentResource，Agent向AM注冊，并實現Agent與AM之間的心跳信息的交互
2.4SLIDER工作流程
通過Slider將常駐服務運行在YARN中，與常規的提交YARNApp(eg,MR)大致相同，分為兩個階段運行該應用程序；第一個階段是啟動SliderAppMaster；第二個階段是由SliderAppMaster創建應用程序，為它申請資源，并監控它的整個運行過程，直到運行完成。
步驟1：用戶通過CLI啟動SliderAppMaster，SliderClient通過調用create及start向YARN提交應用請求，分配資源并啟動SliderAppMaster，啟動過程中從Apppackage中讀取所需要的配置信息，初始化服務
步驟2：SliderAppMaster啟動后，向YARN申請資源，并啟動container
步驟3：Container被激活并啟動Agent，SliderAppMaster分配Container后，啟動Container，并啟動SliderAgent
步驟4：SliderAgent的啟動后，從應用程序的描述文件(metainfo.xml)中讀取應用的啟動腳本及目錄
步驟5：SliderAgent向SliderAppMaster注冊，通過SliderAppMaster向SliderAMWebApp服務的REST(/agent/register)完成注冊
步驟6：SliderAppMaster向SliderAgent發送命令，SliderAgent根據應用程序的描述文件啟動對應的腳本，啟動對應的服務（Component）
步驟7：SliderAgent與SliderAppMaster進行心跳交互，SliderAgent向SliderAppMaster匯報服務狀態及配置等
步驟8：SliderAppMaster通過YARNRegistry向zk中注冊服務地址，客戶端獲取服務地址，并對服務進行信息的查詢和操作
2.5小結
本章介紹了Slider的設計理念和基本架構，涉及到的內容較多，包括Slider產生背景、Slider術語解釋、Slider架構和通信協議等。從YARN的角度上講，Slider與MRAppMaster等Application的執行過程相同。在后面幾章中，將深入探討Slider內部實現原理，以便進一步深層次理解Slider。

總結

以上是生活随笔為你收集整理的slide简介（大数据技术）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。