天天看點

猛犸系統

前言

猛犸系統特點

猛犸抽象分層

猛犸原型

猛犸如何和已知應用互動

猛犸如何提供高可用存儲支援元件

猛犸打通應用叢集和大資料叢集 

統一的,高效的分布式系統誕生的條件已經成熟:

資源管理/排程系統。資源模型取代傳統的伺服器模型。

容器技術。

單機上混跑任務互不幹擾

應用與伺服器互不依賴

分布式協調元件,例如zookeeper,消息隊列等的成熟

猛犸則是基于這些元件之上建構的分布式,大資料/傳統應用部署運維平台。

猛犸提供了一個一緻統一的大資料以及相關應用的部署,運維平台。

1.猛犸是可程式設計的。意味着你可以開發一套元件增強系統的功能,然後進行安裝而不需要修改系統的核心。

2.猛犸簡化大資料平台部署,加快産品落地,真正撸起袖子即可快速建構平台進行資料處理

3.猛犸統一了應用群組件的概念,使用者隻需要了解兩類應用:

系統元件(framework),用來增強系統的功能。典型如動态擴容等功能。

應用程式(app),實際業務系統

4.支援app store. 所有應用都是app,部署過程就是app的安裝過程,和現在的單機系統保持了高度一緻。即使沒接觸過猛犸的人也能輕而易舉的部署一個可以服務成千上萬人的業務系統。

5.基于資源模型的部署元件允許你上傳一個.image檔案(docker鏡像),指定資源占用量以及執行個體數即可完成所有部署

6.猛犸解決容器跨機器通訊問題

7.猛犸提供的應用自我修複機制可以使得應用總是運作在使用者期望的狀态,譬如維持恒定的使用者規定的執行個體數,資源要求等。

8.猛犸自身是極度易于部署,不依賴單機作業系統或者本地庫

9.猛犸的互動應該是區分人機互動和系統之間互動。人機互動應當提供一個友好的web界面,而系統之間互動應該提供一個良好的溝通api.

10.猛犸也支援通過分布式shell引擎支援傳統的伺服器模式。并且資源模型和傳統的伺服器模式同時并存,解決各自擅長的問題

猛犸系統

2.png

猛犸由5層構成,類似傳統的單機作業系統:

1.互動層

外部服務調用,類似單機的ip/port定位,分布式作業系統通過封裝 nginx/haproxy 實作。

人機互動界面,類似單機的shell終端,通過web化界面實作。

2.應用層

支援.tar.gz, .image, .git 三種檔案的安裝。在分布式系統中,使用者看到的一切,要麼是app,要麼是framework,他們都可以以規範的方式安裝進分布式系統。app就是屬于應用層。而framework則屬于系統級元件,對應用層提供各種隐形功能支援。

以docker為程序模型進行運作。基于伺服器的傳統部署元件(framework) 允許采用其他程序模型,譬如裸機上直接運作一個java程式。

程序支援異步或者同步同步通訊,通過系統封裝的zookeeper api 來實作協調。

3.系統服務層

部署:基于伺服器的傳統部署元件(基于核心分布式shell引擎開發的framework);基于資源的部署元件(基于核心yarn開發的framework)

應用穩定性支援,基于資源的部署可保證服務執行個體的數量,保持對所需資源的占用。

存儲穩定性支援。實作實作mysql,redis這種單master的高可用性,保證存儲的穩定。而類似hbase,cassandra這些服務本身已經實作了高可用性,不需要分布式系統的系統服務來支撐。

對應用提供依賴性api.譬如安裝hadoop時,需要以來zookeeper,安裝程式可直接調用系統查詢是否有可以使用zookeeper.

4.檔案系統

hdfs分布式檔案系統

mysql高可用支援事務的存儲引擎

redis高可用緩存元件

hbase高可用kv存儲元件

5.核心層(borg)

內建分布式shell引擎

內建yarn資源管理引擎

現在,單機和分布式作業系統結構得到了完美統一,下面是單機作業系統:

猛犸系統

1.png

猛犸系統

mammuthus.png

從架構圖中可以看到,這是一個典型的master-salve結構。

master 程序包含三個大的子產品:

resourcemanager.資源模型的管理和排程中心。基于yarn封裝的一套元件。

commandengine,指令系統,伺服器模型的中樞子產品。該子產品通過akka可以向slave的shellengine釋出任何shell腳本指令。

appengine,app部署支援,app資訊存儲查詢等。提供了一系列功能友善管理slave以及和web進行互動。譬如安裝部署解析引擎可根據配置為特定應生成安裝頁面,手機安裝資訊。

slave程序:

nodemanager. 對特定伺服器進行資源管理的核心子產品。該子產品 基于yarn封裝。

shellengine. 在slave上執行各種shell腳本。支援阻塞,異步模式。

confengine. 如果系統發現使用者安裝了zookeeper,則會請求确認開啟,進而支援配置檔案管理。配合web端,可以對各個系統的檔案進行可視化管理,比如/etc/hosts檔案等。

web console:

猛犸的預設互動端。通過該console可以進行應用安裝,管理等。

通訊協定:

調用者

服務者

協定

web console

master

http

commandengine

shellengine

akka

resourcemanager

nodemanager

hadoop 

猛犸系統透過appengine支援兩種應用/資源管理模式:

1.<b>伺服器模型</b>。  也就是傳統的‘指定伺服器’部署模式。appengine預設透過commandengine做這種支援。基本步驟為:

上傳安裝包

選擇伺服器

收集參數

生成配置檔案

分發安裝包

安裝

進入管理界面

對于不是很複雜的系統,比如flume之類的,則隻需要在根目錄裡按格式要求放一個兩三行的腳本,分布式系統便能夠完成安裝,啟動,關閉,監控程序存活等功能。

而如果像hadoop這麼複雜的應用,目前猛犸直接預設提供支援,從官方下載下傳tar.gz包上傳即可安裝。hadoop/zookeeper的安裝已經簡化到隻需要選擇機器即可完成一個任意規模的叢集。後續可以通過配置管理系統重新編輯相應的配置檔案進而優化叢集性能。如果使用者開發的應用非常複雜,而猛犸預設的安裝規則不足以滿足要求的話,則可在安裝包的根目錄放一個json描述檔案,系統會根據該json描述檔案自動調整頁面中的安裝流程。不會對原有程式有侵入。安裝完之後會自動通知loadbalance 以及注冊中心(zookeeper)。

這種方式适合帶有存儲類的應用。譬如搜尋,mysql,hdfs等。應用的安裝資訊并不會存儲在master上,而是存儲在每台slave上。由slave通過心跳上報到master端。靜态模型中,master是完全無狀态的。

安裝成功後,透過web console可對應用進行生命周期管理,譬如關閉,開啟等。同時對每個應用,使用者可以在web console中浏覽整個目錄。

對于更新操作,使用者可以在界面先停一部分服務,然後對這些服務重新走安裝程式。接着按同樣的方式對第二批服務進行操作,直到所有服務都是最新版本的。

2.<b>資源模型。</b>

該模式下,所有資源由yarn核心進行動态配置設定管理。我們提供了一個dynamicdeploy的系統元件(猛犸單獨開發的一個元件,使用者通過web console上傳後自動便會開啟該功能)。

如果使用者在部署過程中選擇動态部署,那麼使用者有兩種選擇:

純java程式(.tar.gz字尾檔案)

容器(.image字尾檔案)

猛犸在該種模式下,對容器沒有任何要求,隻要能run起來就行。而如果是java程式,則該程式啟動過程中,必須使用分布式系統給予的端口,而不能自定義端口。

當用部署時,appengine會将安裝包送出給dynamicdeploy,dynamicdeploy會按下面的流程進行處理:

dynamicdeploy向resourcemanager子產品送出資源資源申請,resourcemanager啟動applicationmaster

applicationmaster啟動dynamicdeploy的driver(master)

applicationmaster向resource manager申請資源,resource manager根據叢集資源情況為其配置設定yarn container,

這些container會連接配接driver。driver釋出啟動指令給各個container.container會執行download image,load image,run image 三部分指令

run指令會自動添加cpu,記憶體,磁盤配額。并且給docker的容器配置一個随機端口

container會将docker容器的ip,端口上報給driver,driver會将這些發送給appengine.

appengine會把通知發送給loadbalance 以及注冊中心(zookeeper)

完成部署

部署完成後,dynamicdeploy會保證:

如果有服務執行個體當掉,dynamicdeploy會檢測到,并且在找到合适的伺服器重新啟動該執行個體。也就是dynamicdeploy會保證執行個體的個數穩定不變。

dynamicdeploy 對自身提供 failover機制

如果是driver挂掉,并不會影響正在運作的服務。直到分布式系統進行多次嘗試仍然無法啟動dynamicdeploy driver,才會出現服務fail的情況。

如果是伴生程序挂掉,則猛犸有兩套機制保證使用者的程序不會成為‘沒人管’的程序。首先伴生程序如果不是jvm crash掉了,會自動将使用者程序殺掉。driver然後會在其他伺服器重新排程,保證執行個體數不變。如果是jvm crash掉來不及做清理工作,driver會監聽心跳,一定時間内會将該資訊釋出給猛犸,猛犸會通過分布式shell引擎來完成最後的清理工作。

更新操作中,灰階更新變得很簡單,在web console中重新部署一套服務,該服務會根據loadbalance政策,或者和原來的服務同時對外提供,或者保證隻有舊的服務被關停後新的服務才能對外提供服務。

猛犸原型目前已經實作了分布式系統特性中的絕大部分。在agent核心中同時支援分布式shell引擎以及yarn核心使得他們可以進行互補。

在軟體行業,相容現存的應用顯得尤為重要,是決定一個平台系統能夠存活的關鍵名額。容器技術使得所有應用可以被作業系統運作起來。并且可以吻合yarn核心對資源控制的要求。但是我們可能需要對被容器包括起來應用更細緻的控制。

我們先來看兩個概念。

1.啞應用

所謂啞應用指的是無法和分布式系統直接進行互動,分布式系統也僅僅透過容器能進行生命周期的控制,比如關閉或者開啟的應用。典型的比如mysql,nginx等這些基礎應用。他們一般有自己特有的互動方式,譬如指令行或者socket協定或者http協定。

2.伴生元件

因為有了啞應用的存在,作業系統為了能夠和這些應用互動,是以有了伴生元件的存在。這些伴生元件和啞應用具有相同的生命周期。伴生元件其實是啞應用的proxy,進而使得啞應用可以和分布式系統進行交流。典型的比如,某個服務被關停後,該事件會被作業系統獲知,作業系統會将該事件發送給nginx的伴生元件,伴生元件轉化為nginx能夠識别的指令,将停止的服務從nginx的proxybackend清單中剔除。

如果我們隻需要對應用進行生命周期控制,而你的應用是基于容器的,那麼我們隻要分布式系統預設提供的伴生元件即可完成大部分功能需求。

基于資源的部署方式,需要你将應用容器化,或者如果你的應用是一個java程式,則能夠接受分布式系統提供的端口作為自己對外服務的端口,也可以被排程,然而,存在的另外一個風險是,對cpu的控制會比較困難。

基于傳統伺服器模式的部署方式,則并不強制要求容器化,我們提供封裝了一套完善的shell腳本引擎,你隻要填寫兩到三行指令就可以完成完成分布式系統對對應應用的生命周期管理。對應用沒有任何改動。然而,你需要自己解決應用本身對裸伺服器的環境以來,譬如某些本地庫。

猛犸中的dynamicdeploy是一個基于yarn排程容器的framework,也就是說屬于系統元件。而dynamicdeploy的slave同時也屬于docker的伴生元件,可以對docker容器進行互動。指令發給dynamicdeploy的master,master将其轉發給slave,slave轉化成docker能夠識别的内容進行操作。

同時對于loaderbalance,猛犸預設提供了mammuthusnginx伴生對象。這些元件都是以标準的方式進行安裝即可。

在分布式作業系統中,可提供分布式檔案系統(hdfs),也可以提供‘硬體級别’的磁盤,還有高層次支援事務的mysql叢集,高速緩存redis叢集,優秀的keyvalue存儲 hbase等。對于這些的支援,我們正在開發相應的元件進行支援。

在分布式系統中可以保證:

這些存儲以元件的形态供使用者安裝

這些元件安裝完成後,自動會獲得高可用支援

這裡,以mysql為例,在分布式作業系統中是如何實作高可用的呢?

分布式作業系統中,mysql 以容器狀态運作,檔案通過volumn挂載在實際磁盤中,實作單master多slave結構,我們稱之為一個cluster,系統允許多個cluster存在。值得注意的是,mysql這些資訊都會在系統的系統資料庫中找到。

我們開發了一套伴生元件,該元件是專門監控這種單master節點類型的系統,一旦安裝了mysql,系統會自動啟用該元件,定時監控master的可用性,一旦發現master不可以用,則找到資料最新的slave,提升為master,并且變更系統資料庫資訊(如ip,端口等),所有使用該mysql的服務元件都會得到通知,進而實作動态變更。

這裡有一個可能的問題是,如果某些應用并不接受這種變更通知。最透明的方式将會是使用ip漂移技術。如果并不希望使用類似ip漂移技術,則一個比較直覺的方式,通過某種途徑,修改使用了該mysql的應用的配置檔案(這個是難點,如何修改?),并且将該重新開機該應用(cluster,可以rolling restart),到現階段位置,目前這套機制并沒實作。同理,redis cluster也是通過相同的方式實作高可用。

在猛犸(也就是您正在看的系統)裡,所有資源包括大資料叢集和應用伺服器叢集都是被統一管理的(你也可以安裝兩套猛犸單獨管理),是以其實大資料叢集資源和應用叢集資源是可以互相出讓的。比如晚上應用使用的少,但是大資料叢集非常繁忙,猛犸可以把部分計算資源讓出來,給資料叢集。反之白天則相反。目前大部分公司部署上都是獨立的,大資料是大資料的機器,應用是應用的機器,而如果統一使用猛犸,可以打破這種界限。