Mesos - 數據中心的操作系統

Mesos的核心理念，或者說愿景，就是成為數據中心的“內核”，類似像單機OS一樣，屏蔽硬件，提供多節點資源的統一視圖。

Mesos提供兩階段調度，簡化來說，Mesos用來管理集群資源，并且向其提供高層級的能接受這些資源來啟動任務的“框架”。

Master由zk協調選舉產生，master本身不做負載計算。它以資源offer的形式將slave上的資源提供給調度框架，并根據已接受的offer在slave上啟動任務，同時，負責任務與調度框架之間的通信。

slave管理單個節點上的資源，可以設定資源策略來適應不同業務優先級。slave管理資源包括CPU/RAM/PORT等，負責執行框架提交的任務。

框架其實包括調度程序和執行程序，調度程序負責決定接受/拒絕offer，執行程序是資源的消費者，運行在slave上，負責運行任務任務。

Mesos支持運行hadoop、spark、storm、samza、Hama（圖像處理）、MPI（高性能計算）、存儲（HDFS/Tachyon/Cassandra）、Jenkins、Gitlib等，及各種元調度框架，如Marathon、Aurora，使大部分已有程序可以直接運行。

Mesos已原生支持Docker，也支持其他容器格式。

http://mesos.apache.org/documentation/latest/frameworks/

Mesos要求內核版本3.10以上。支持物理機、虛擬機、AWS EC2上運行。

安裝比較麻煩，需要自己編譯。Mesos母公司提供了一些操作系統的二進制分發包，但是到本文寫作日期，還沒有公司常用的suse分發，需要自己編譯。

編譯主要依賴c++11，所以需要GCC4.8.1以上版本，同時需要python2.6開發庫，jdk1.6以上，詳細可以參考官網getstart中CentOS6.6的安裝。

編譯時建議新建一個build目錄，在這里編譯，編譯好的軟件可以分發復制。

mesos軟件包，自帶一個configure腳本，可以檢查編譯環境，缺失依賴包，都會報錯。configure –help查看幫助。

mesos-local.sh可以啟動本地mesos集群，配合官方的測試框架/mesos/build/src/examples/java/test-framework master:5050，可以查看安裝是否成功，下面是其他的一些命令:

和其他常見的產品一樣，Mesos也提供Web UI監控，通過

:

啟動。

可以監控slave、聚合信息、框架等。

Twitter。Twitter使用mesos較早，整合了storm運行在mesos上，并開發了Aurora調度框架來管理其他的普通服務

Airbnb。Airbnb在mesos上運行Hadoop、Spark、Kafka、Cassandra、Redis等服務來完成數據分析。并開發了Chroanos調度框架。

Hubspot。Hubspot在AWS EC2上運行Mesos，開發了Singularity框架，構建PAAS。

安裝編譯復雜。官方原生支持的操作系統二進制包太少。

語言太多。作為開發人員和運維人員，我想要知道集群里運行的是什么，在發現代碼基問題時，我要能夠修復問題。要運行Mesos堆棧，涉及到很多組件：Mesos（C++），Marathon（Scala），Mesos-DNS（Golang）等等。不太容易找到對這么多語言都熟悉的開發人員。

所有調度器都沒有很好地針對微服務進行抽象，就像Pod，Service，Namespace的抽象那樣。這些很容易實現，但是還沒有實現。

https://github.com/mesos/hadoop

Mesos調度器 – JobTracker

Mesos執行器 – TaskTracker

調度器和執行器的配置在conf/mapred-site.xml中，參考README.md

conf/core-site.xml里面可以配置mesos的資源策略，包括物理資源如CPU/RAM/DISK，和邏輯上的，如指定時間內MAP/REDUCE slot的最小數量。

Mesos支持從Hadoop導出metrics到外部監控系統，如CSV文件、Graphite、Cassandra。

Mesos上的hadoop支持role認證、user認證。

http://spark.apache.org/docs/latest/running-on-mesos.html#mesos-run-modes

spark和mesos都出自Berkeley數據分析棧，所以天然就有比較好的結合度。

spark on mesos的資源管理有很多配置項，可以限制spark可以獲得最大的CPU核數、粗粒度下每個任務能申請額外CPU核數、內存總量等，參考http://spark.apache.org/docs/latest/running-on-mesos.html#configuration

spark基于mesos的資源管理有兩種模式，粗粒度和細粒度。粒度控制通過 SparkConf: conf.set("spark.mesos.coarse", "true")，true為粗粒度。

細粒度：Spark默認將每個人物作為獨立的mesos任務運行，也就是說，會和其他框架共享集群資源。這個模式下，Mesos可以彈性的在所有應用間共享集群資源。代價是啟動任務時產生更高的額外代價，時間要求嚴格的業務可能有沖擊。

粗粒度：適合長期運行的作業。Mesos節點會預留長期運行的Spark任務所需的資源，并按需把資源分給spark作業。好處就是作業無需額外的消耗來完成Mesos節點上任務的啟動。

https://github.com/mesos/storm

配置沿用Storm的YAML格式，必須的配置有：

mesos.executor.uri： 執行器uri

mesos.master.url： Mesos master地址

storm.zookeeper.servers：storm關聯的zk

一些可選參數用于限制資源等，如制定每個worker節點的CPU和內存的參數topology.mesos.worker.cpu和topology.mesos.worker.mem.mb，執行器的CPU和內存topology.mesos.executor.cpu、topology.mesos.executor.mem.mb。

目前storm也支持Marathon and Docker的方式運行在mesos上。

mesos支持多種存儲：HDFS、Tachyon（以內存為中心的存儲系統）、Riak、Canssandra、ElasticSearch等。

元框架是基于mesos的資源管理，承載應用程序運行的中介，負責運行服務、處理故障、重啟服務、按需擴容等。

https://github.com/mesosphere/marathon

運行長期服務的框架。支持高可用（服務失敗其他機器啟動）和彈性擴展，Marathon之上不僅僅可以運行自定義服務，還可以運行Hadoop之類的框架，也可以運行自身。

除了mesos，Marathon還要依賴zk，運行時需指定mesos master和zk

Marathon提供標準命令行、多種語言的客戶端，及REST接口，REST接口參考：http://mesosphere.github.io/marathon/docs/generated/api.html

大概分應用、組、部署、訂閱、信息和日志幾類。

組，是為了使應用便于管理。組可以包含應用或組，組分層，且組可以嵌套，所以可以用相對路徑和絕對路徑表示。依賴也可以定義在組級別。

http://mesosphere.github.io/marathon/docs/application-groups.html

約束，控制在哪里、如何產生任務，限制特定應用運行的位置，可以用于容錯等。

http://mesosphere.github.io/marathon/docs/constraints.html

啟動應用時約束條件就會被強制執行，一個約束包括字段、操作符和可選參數。字段是分布在mesos slave或其主機名上的任意屬性。操作符有三種：

UNIQUE：指定某字段唯一性，如每個主機上只運行一個任務

CLUSTER：運行在有特定屬性的slave上，如果對特殊硬件有區別要求，這就很有用

GROUP BY：在指定rack或datacenter上平均分配

LIKE：基于正則表達式過濾主機

UNLIKE：與LIKE相反，過濾出不符合正則的主機

事件總線，捕捉所有事件，如API請求、擴展，可以集成LB、監控等。

http://mesosphere.github.io/marathon/docs/event-bus.html

可以設置訂閱，默認是HTTP回調訂閱，發送POST JSON格式事件。事件包括：

API請求：應用CRUD請求

每次任務狀態改變的狀態更新

框架消息事件：包含字段slaveId、executorId、timestamp

健康檢查：健康檢查的CURD

部署事件：多種部署成功或失敗

產品倉庫Artifact Store，分布式應用需要的資源存儲位置。類似一個集中倉庫，Marathon只會下載一次，支持多種存儲框架，如本地文件或HDFS等。

http://mesosphere.github.io/marathon/docs/artifact-store.html

健康檢查，Marathon監控應用狀態，只要是TASK_RUNNING，就判斷他是健康的。

http://mesosphere.github.io/marathon/docs/health-checks.html

應用健康有生命周期判定，下圖假設i是請求數、r是運行任務數、h是健康實例數。

Marathon是長期運行服務的支持，Chronos就是定時觸發任務的支持。

Chronos基于 ISO8601，可以理解為mesos上的cron功能，同樣依賴zk容錯，依托mesos執行。

https://github.com/mesos/chronos

Chronos可以與hadoop集成，也可以與docker集成

安裝運行可以參考

https://mesos.github.io/chronos/docs/

Chronos同樣提供了一套REST API，可以管理和監控job

https://mesos.github.io/chronos/docs/api.html

描述job采用json格式，上面的連接有個樣例描述

其中name指定jbo名稱、command指定需要運行的命令、schedule指定符合ISO8601標準的執行計劃、async指定是否后臺運行、epsilon指定啟動job的時間間隔，以防Chronos錯過調度時間。

Aurora由Twitter開發，也是個很火的元框架。mesos官方文檔中，也算在長期服務支撐類中，但其實也支持cron類任務。

http://aurora.apache.org/

Aurora一個job包含多個task副本，一個job是在同一個機器上運行的一個或多個進程。因為mesos只做任務抽象，所以Aurora提供了一個Thermos組件管理單個task中的進程，因為每個task都是運行在沙箱中，thermos今晨可以在這些沙箱間共享狀態。Thermos主要分兩部分，一個是執行器，負責啟動和管理任務，一個是觀察期，負責監控后臺程序。

http://aurora.apache.org/documentation/latest/user-guide/

Aurora架構包含一個client，一個狀態機、一個事件總線及訂閱者、存儲。

client從狀態機獲得所有信息，不同組件都通過訂閱消息總線來通信。狀態機后臺是存儲支持，持久化不同數據，如任務配置、作業配置、更新進程等，以實現故障轉移。

存儲采用不可變模式，修改其實都是新建版本。

滾動式更新，Aurora更新任務配置會一批一批的執行，舊配置任務killed，然后拉起新配置的任務。迭代這個過程直到所有更新完畢。過程中會不斷進行健康檢查，如果一定比例的更新后的任務運行狀態變為failed，客戶端會觸發回滾，所有新配置任務都會銷毀，然后恢復舊配置。

Job生命周期，新任務是pending，找到滿足條件的機器，狀態變為assigned。slave從調度器接收任務的配置，生成執行器，調度器收到確認消息，狀態變為starting。任務完成初始化，變為running，Thermos開始運行進程。長時間處于pending和assigned狀態，調度器會標記lost，然后重新生成pending任務。正常結束，finished或failed狀態，強制終止為killing或restarting。需要釋放資源時，非生產作業可能被強制終止，變為PREEMPTING，然后killed。

Aurora的配置，其實就是一個python文件，使用pystachio庫指定配置。配置文件必須由.aurora后綴。配置文件里包含三類對象：Process、Task、Job，官方給了一個hello world任務配置的樣例http://aurora.apache.org/documentation/latest/tutorial/

Aurora支持cron任務，通過配置job對象的cron_schedule屬性識別，cron_collision_policy字段指定當前運行的作業到達下一個作業啟動時間時還么有完成時的行為，可以殺死舊作業，或不啟動新作業，殺死舊作業是默認行為。還支持失敗重試任務。

Mesos-DNS提供基于DNS的服務發現機制，接受DNS請求，回復DNS記錄。工作對框架完全透明，只需要使用標準的DNS查詢就可以通過名稱解析出地址。

https://github.com/mesosphere/mesos-dns

目前支持ANY、A、SRV DNS記錄。其他類型的記錄都會返回NXDOMIN

Mesos-DNS有兩個主要組件。

DNS記錄生成器，負責為所有運行的應用程序生成DNS A和SRV記錄。周期性的查詢master，scan所有運行應用的任務信息，記錄任務狀態，并用DNS格式保存最新的服務狀態。

DNS解析器，解析DNS請求，并響應。模擬普通的DNS服務器的行為。

為了保證無狀態化，mesos-dns沒有提供健康檢查、應用生命周期管理等功能。

安裝運行指導參考http://mesosphere.github.io/mesos-dns/docs/

最小化接口，兩階段調度，專注于資源管理，是mesos設計背后體現的理念。這樣使mesos核心簡潔，且和調度框架解耦，可以獨立發展。Mesos架構很簡單，主要分為master、slave、框架、通信這幾部分。

Master負責給框架提供資源分配，管理任務的生命周期。Mesos通過資源offer的形式完成細粒度的資源分配。Mesos作為資源的中介，利用各種可插拔的策略為框架提供資源。資源offer就是一個資源分配的單元，由一個節點上可用資源組成的向量，代表著每個slave鎖提供給某個框架的資源

Slave執行框架下發的任務。并對任務進行隔離，保證資源不多不少的分配。

Slave上的資源通過slave資源和slave屬性描述。資源是顧名思義，屬性是用來描述slave的特殊信息，比如特殊的硬件、操作系統、網絡環境等。屬性是鍵值對，并隨著資源offer傳遞給框架。mesos自身不去理解這些屬性，只是每次向框架提供offer時傳遞，各個框架來實現對這些屬性的解析和利用。參考http://mesos.apache.org/documentation/latest/attributes-resources/

資源、屬性支持幾種類型描述：

scalar : floatValue

floatValue : ( intValue ( "." intValue )? ) | ...

intValue : [0-9]+

range : "[" rangeValue ( "," rangeValue )* "]"

rangeValue : scalar "-" scalar

set : "{" text ( "," text )* "}"

text : [a-zA-Z0-9_/.-]

master會處理名稱為cpus、mem、disk、ports關鍵字的資源，沒有cpus和mem資源的slave節點將不會為框架提供服務。

Mesos暫時還不支持GPU資源的調度，但是可以自定義資源類型作為offer一部分提供。

框架管理和運行任務，任務是資源的最終消費者。框架包括框架調度器和執行器。調度器負責協調任務，執行器控制任務執行。執行器可以選擇運行單任務，或執行器內啟動多進程處理多任務。任務管理，包括生命周期，框架API還提供了和調度器和執行器通信的功能。

Mesos用libprocess實現了一個類HTTP協議支撐組件間的通信。通過通信原語和actor通信模式進行異步通信，且消息不可變。消息采用POST方法，頭User-Agent標記為libprocess/…，消息數據存在body，用PB序列化。

Mesos內部有幾個主要的API通信：

調度器API：框架調度器和Mesos master進行通信。

執行器API：執行器和mesos slave間通信

內部API：mesos的master和slave間通信

運維API：這是mesos內部唯一一組同步通信。被WEB UI或運維工具消費。

已經一再講過，mesos是兩級調度，資源分配和任務調度是隔離的。Mesos master負責決定分配給每個框架多少資源，任務調度器負責決定如何使用這些資源，這個如何使用，是框架調度器自己按需實現的，也可以選擇接受或拒絕offer。也可以理解為，mesos給各個框架提供粗粒度的資源分配，每個框架根據自身特點進行細粒度任務調度。

http://mesos.berkeley.edu/mesos_tech_report.pdf

這種雙層調度設計使mesos本身保持簡單、易擴展、穩定。資源分配的過程也不需要了解真正的調度何時運行。但是也不是沒有缺點：調度器并不了解全局的資源利用率，所以資源分配可能不是全局最優。框架在執行任務對資源有特殊要求，如數據局部性、特殊硬件或安全限制，這些信息mesos并不會知道，只能被動的不斷發送offer，等待拒絕或接受，整個流程可能會稍顯低效。

一個典型的框架事件通信流程：

1. 框架調度器在Mesos master中進行注冊

2. Mesos master從slave獲取資源offer，調用分配模塊函數去決定將這些資源分配給哪些框架

3. 框架調度器從mesos master處得到資源offer

4. 框架調度器判斷當前資源offer是否合適，選擇接受并向mesos master返回一個需要在slave上利用這些資源運行的執行器列表，或拒絕offer，等待下一個offer。

5. slave分配所請求的資源并運行任務執行器，任務執行器在slave節點上運行框架下發的任務

6. 框架調度器接收任務運行成功或失敗的通知。同時框架調度器繼續重復#3和#6

7. 框架從Mesos master注銷，這時開始不再接收資源offer。這個步驟是可選的，長期運行的元框架一般沒有注銷的動作。

Mesos默認算法是DRF（主導資源公平算法 Dominant Resource Fairness）。

DFR算法論文：https://www.cs.berkeley.edu/~alig/papers/drf.pdf

說明白DFR之前要有兩個鋪墊：

單資源公平算法：很容易定義，如內存平均分配給每個框架

最大-最小資源公平算法：單一資源，但多用戶請求量不同，盡可能滿足用戶所能獲得最少資源的最大化，參考http://www.ece.rutgers.edu/~marsic/Teaching/CCN/minmax-fairsh.html

Compute the max-min fair allocation for a set of four sources with demands 2, 2.6, 4, 5 when the resource has a capacity of 10.

Solution: We compute the fair share in several rounds of computation. In the first round, we tentatively divide the resource into four portions of size 2.5. Since this is larger than source 1's demand, this leaves 0.5 left over for the remaining three sources, which we divide evenly among the rest, giving them 2.66... each. This is larger than what source 2 wants, so we have an excess of 0.066..., which we divide evenly among the remaining two sources, giving them 2.5 + 0.66... + 0.033... = 2.7 each. Thus, the fair allocation is: source 1 gets 2, source 2 gets 2.6, sources 3 and 4 get 2.7 each.

這兩種算法都不能解決不同質、多個資源的分配，如CPU/RAM/DISK等混合資源。

DFR，將最大-最小公平資源算法在多資源的情況下進行泛化，所占資源在總資源比例最多的資源類型被稱為該請求的主導資源。如：總資源 <8 CPU, 5 GB>, 請求 <2 CPU, 1 GB>, 主導資源是max(2/8,1/5)，即CPU。分配過程按最大最小公平算法分配，如，F1主導資源是CPU 20%，F2主導資源是RAM30%，隨便挑一個為起始分配（不影響結果），先分配給F2，目前主導資源F1=0%，F2=30%，下次分F1，則F1=20%,F2=30%，按算法，F1目前占用較小，所以還分配給F1。詳細可以參考：http://cloudarchitectmusings.com/2015/04/08/playing-traffic-cop-resource-allocation-in-apache-mesos/

DRF有幾個好處：

策略可驗證：用戶無法通過夸大自己的需求獲得更多的優勢

鼓勵資源共享：保證每個用戶所能獲得的最小資源

單一資源公平：同質單一次元，DRF和最大-最小公平資源算法是等價的

無嫉妒Envy-free：每個用戶獲得的資源都不比別人的差

瓶頸公平性：某個資源是瓶頸，對于所有主導資源為這個資源的請求，DRF與最大-最小公平資源算法等價

單調性：增加資源或減少用戶只會增加剩余用戶所獲得的資源

帕累托最優：http://baike.baidu.com/view/98065.htm 不可能在不損害其他請求的情況下，單獨優化某個請求的資源

Mesos支持加權DRF，通過role和weight把資源做傾斜分配。

長期運行的有狀態服務，可能需要資源預留。

資源預留需要使用mesos鑒權機制。在master配置。

資源預留有兩種方式

靜態預留，為某個特定角色預留，如果沒有指定角色，默認華為*角色

動態預留，框架對資源進行預留，這部分資源后續只能分配給同一個框架

資源隔離mesos同樣采用插件式方式，slave利用容器來為執行器和任務提供隔離的運行環境。容器API目的是支持不同的容器實現，slave進程啟動后，可以指定容器和隔離策略。

mesos自帶一個容器實現，也默認支持docker，目前基本都在用docker，就不再展開。

http://mesos.apache.org/documentation/latest/containerizer/

Mesos通過zookeeper實現分布式協調，利用zk的超時機制判斷節點是否可用。slave如果不可用，master會通知框架。master不可用，會重新選主。配合mesos健康檢查的機制，失聯的任務會標記為LOST。

mesos master有Registry機制，使master變的有少量“狀態”。Registry保存一個已注冊的slave列表，master控制slave的注冊、重新注冊、刪除都寫入Registry。這樣避免數據不一致，如slave在master故障的時候異常，任務丟失會發送給框架，但是master不知道。

Registry后端實現有幾種，內存（測試用）、LevelDB、Replicated Log（MultiPaxos算法）

Mesos監控與管理

Mesos可以以插件模式與Nagios、collectd等工具集成。

監控可以通過HTTP Endpoint獲取數據，參考

http://mesos.apache.org/documentation/latest/monitoring/

master信息通過http://

:5050/metrics/snapshot

分Resources、Master、System、Slaves、Frameworks、Tasks、Messages、Event queue、Registrar幾類

slave節點信息通過http://

:5051/metrics/snapshot

分Resources、Slave、System、Executors、Tasks、Messages幾類。

http://mesos.apache.org/documentation/latest/network-monitoring/

默認并不開啟，需要配置開啟。需要依賴內核3.6以上版本，依賴內核的network namespace、libnl3、iproute包。

開啟后，每個容器得到主機端口的一個子集，進行端口映射，還需要指定給容器分配多少隨機端口，最好是2的冪。

通過/monitor/statistics提供信息。根據信息也可以配置特定容器的網絡限速。

http://mesos.apache.org/documentation/latest/authorization/

鑒權，通過SASL庫實現，包括幾種鑒權方式：

框架以授權的角色形式進行注冊

框架以授權用戶的身份啟動任務

授權過的管理員通過shutdown/接入點和HTTP API來關閉框架

授權，通過ACL來實現，每個通過master的請求，mesos master都會檢查當前的請求是否經過ACL授權。每個ACL包含目標、動作、對象三部分組成，即“目標”在“對象”上可以執行的“動作”。

對象，支持roles（register_frameworks）和users（run_task）及framework_principals（HTTP接入點）

目標，支持principals，是register_frameworks、run_task中的框架管理員，或shutdown_frameworks的用戶名

動作，register_frameworks、run_task，或shutdown_frameworks

ACL規則是按順序進行匹配，所以多條以第一條為準，如果沒有ACL規則與當前請求匹配，則ACLs.permissive將決定當前請求是否授權。

http://mesos.apache.org/documentation/latest/framework-rate-limiting/

mesos上運行多框架時，為防止某個框架過度請求資源，可以限定特定框架的qps限制。

框架超出限制后，會收到FrameworkErrorMessage ，會導致調取器異常退出，調用error（）回調函數，但這一步不會殺死任何任務和調度器本身。如果框架認為master沒有處理完全部請求，框架可以選擇重啟或其他故障恢復機制。

master啟動時以--rate_limits參數控制配置文件，文件是JSON格式，包含：

principal：指定哪些框架需要限制

qps：每秒請求個數

capacity：控制mesos master內存隊列中指定的principal等待消息個數，如果沒指定，默認無窮大。這個值配置需要權衡，太小無法有效利用資源，太大會過多消耗master內存。

aggregate_default_qps and aggregate_default_capacity配置限制其他未特殊指定的框架。

master通過HTTP接入點對外提供每個框架接受和處理的消息個數，frameworks/foo/messages_received and frameworks/foo/messages_processed，要觀察是否兩個值差異過大，就可能發生異常。

http://mesos.apache.org/documentation/latest/configuration/

分共用配置及master/slave單獨的配置，及構建時的配置。

slave節點硬件升級等場景，允許平滑過渡。slave將要維護狀態的信息會通知給框架，框架將不再slave啟動新任務。mesos等待slavve上的任務結束并通知框架下一批將要進入維護狀態的slave。通過撤銷指定，框架會根據調度器的實現將任務重新調度到其他節點。slave維護期結束，再次向master發送資源offer，重新成為集群的一份子。

Mesos擴展

Mesos設計了模塊化的系統，提供插件化的機制，無需重新編譯即可添加mesos內部擴展

http://mesos.apache.org/documentation/latest/modules/

mesos目前支持鑒權模塊、隔離器模塊、匿名模塊（不接受任何回調，只和父進程共同存在）、分配器模塊（決定框架資源分配），不提供模塊擴展的功能，還可以通過hook的鉤子回調方式擴展。

通過--modules=filepath的方式指定模塊加載。加載模塊過程：

1. 從模塊實例中加載包含模塊的動態庫，這個實例可能是在命令行選項中指定的

2. 確定模塊版本的兼容性

3. 以單例模式初始化每個模塊

4. 將模塊中的引用和實際所使用的函數進行綁定

模塊名要唯一，官方推薦java包命名規范來給模塊命名。http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

模塊兼容性信息維護在src/module/manager.cpp，加載時要保證kind version <= Library version <= Mesos version

http://mesos.apache.org/documentation/latest/app-framework-development-guide/

框架語言可以選擇 C, C++, Java/Scala, or Python。

一個mesos框架由scheduler, executor, launcher組成。其中executor非必須。可選label的處理和服務發現功能。

javadoc在http://mesos.apache.org/api/latest/java/

繼承Scheduler接口，有幾個API單獨拿出來說一下：

error：這個方法是在一個可恢復的錯誤產生或調度器和驅動停止工作時調用

resourceOffers：最重要的一個接口，master向框架提供資源offer時調用。調度器可以接受offer并利用offerIds啟動任務，也可以拒絕任務。分配器策略有時可以把同一個offer發送給多個框架，這時，第一個使用資源offer啟動任務的框架將實際使用這份offer，其他會收到offerRescinded發出的消息

啟動器實際就是一個main函數，通過MesosSchedulerDriver來實例化SchedulerDriver，管理調度器的生命周期。

SchedulerDriver接口，有幾個API說一下：

join()，等待驅動退出stopped or aborted，可能一直組側下去。通過返回狀態可以知道驅動是正常退出還是異常退出。

launchTasks多個方法，支持單個或批量啟動任務。

sendFrameworkMessage：框架向執行器發送消息。

requestResources：向mesos請求資源，資源將提供給調度器

繼承Executor接口，其中error和frameworkMessage和調度器語義基本相同。

核心API是launchTask(ExecutorDriver driver, TaskInfo task)。這個函數在調用時會阻塞，在回調完成前，執行器無法執行其他回調函數。如果需要長時間運行任務，最好單獨一個線程去運行。

其中，ExecutorDriver 是執行器與mesos的接口，管理執行器生命周期，及與mesos通信。

sendStatusUpdate(TaskStatus status)會向調度器發送狀態更新，且會在收到確認消息前不斷重試。執行器異常退出，TASK_LOST狀態更新會發送給調度器。主要區別sendFrameworkMessage的不會重試。

Mesos內部消息格式都是pb，定義在https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto

基本上可以顧名思義

http://mesos.apache.org/documentation/latest/reconciliation/

Mesos使用actor模型進行通信。所以絕大部分消息語義都是最多一次的。有個例外是任務狀態更新，這個消息是至少一次的。

master和調度器驅動在連接斷開或重新注冊時執行故障檢測。這里面涉及兩個一致性的協調

offer一致性協調。offer狀態不會持久化，所以斷開連接后offer會失效，重新注冊時會重新生成。

任務一致性協調，這里面又分兩種，顯式的，調度器將正在執行的task發送給master；隱式的，調度器發送空的任務列表，master將所有他已知的任務狀態返回，無法找到的任務狀態被更新為TASK_LOST。當出現錯誤時，必須采用顯式的協調方式。不一致時，在每次重新注冊時采用一致性調節算法，框架需要保證在指定時間內只能有一個一致性調解在執行，官方給了一個算法：

let start = now()

let remaining = { T in tasks | T is non-terminal }

Perform reconciliation: reconcile(remaining)

Wait for status updates to arrive (use truncated exponential backoff). For each update, note the time of arrival.

let remaining = { T in remaining | T.last_update_arrival() < start }

If remaining is non-empty, go to 3.

資源協調者。框架只為其他框架協調資源。通常就是元框架。

基于負載。根據框架的負載來調節資源的使用。Jenkins on mesos等框架就會根據等待隊列的長度來刁杰資源的使用。Marathon和Aurora也可以根據約定自動擴容或縮容。

基于預留。運行時靜態預留資源。執行前就獲得所有資源，并在框架的整個生命周期都持有。

https://github.com/mesosphere/RENDLER

mesosphere創建的一個mesos網頁爬蟲框架，可以借鑒來學習框架開發，有多種語言實現。

轉載請注明出處：華為云博客 https://portal.hwclouds.com/blogs

邊緣數據中心管理 EDCM

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。