Mesos高可用集群解決方案

　作者：王勇橋，80后的IT攻城獅，供職于IBM多年，Mesos和Swarm社區(qū)的貢獻(xiàn)者。
　　責(zé)編：魏偉，歡迎投稿和咨詢報(bào)道，詳情聯(lián)系weiwei@csdn.net
　　本文節(jié)選自 《程序員》，謝絕轉(zhuǎn)載，更多精彩，請(qǐng) 訂閱《程序員》
　　CSDN Docker專(zhuān)家群已經(jīng)建立，還等什么，加入我們吧：微信搜索“ k15751091376”
　　本文系作者根據(jù)自己對(duì)Mesos的高可用（High-Availability）設(shè)計(jì)方案的了解以及在Mesos社區(qū)貢獻(xiàn)的經(jīng)驗(yàn)，深度剖析了Mesos集群高可用的解決方案，以及對(duì)未來(lái)的展望。
　　Mesos高可用架構(gòu)概述
　　首先，我們來(lái)參考Mesos官方的設(shè)計(jì)架構(gòu)，如圖1所示。
　　
　　圖1 Mesos設(shè)計(jì)架構(gòu)（官方）
　　Mesos采用的也是現(xiàn)在分布式集群中比較流行的Master／Slave主從集群管理架構(gòu)，Mesos master節(jié)點(diǎn)是整個(gè)集群的中樞，它責(zé)管理和分配整個(gè)Mesos集群的計(jì)算資源，調(diào)度上層Framework提交的任務(wù)，管理和分發(fā)所有任務(wù)的狀態(tài)。這種主從架構(gòu)設(shè)計(jì)簡(jiǎn)單，能夠滿足大多數(shù)正常情況下的集群運(yùn)作需求，目前仍然存在于很多分布式的系統(tǒng)中，比如Hadoop、MySQL集群等。但是這種簡(jiǎn)單的設(shè)計(jì)存在一個(gè)致命缺陷，就是Mesos master必須做為一個(gè)服務(wù)程序持續(xù)存在于集群中，它雖然孤立，但是地位舉足輕重，不容有失。
　　在單個(gè)Mesos master節(jié)點(diǎn)的集群中，如果Mesos master節(jié)點(diǎn)故障，或者服務(wù)不可用，雖然在每一個(gè)Slave節(jié)點(diǎn)上的任務(wù)可以繼續(xù)運(yùn)行，但是集群中新的資源將無(wú)法再分配給上層Framework，上層Framework將無(wú)法再利用已經(jīng)收到的offer提交新任務(wù)，并且無(wú)法收到正在運(yùn)行任務(wù)的狀態(tài)更新。為了解決這個(gè)問(wèn)題，提高M(jìn)esos集群的高可用性，減少M(fèi)esos master節(jié)點(diǎn)故障所帶來(lái)的影響，Mesos集群采用了傳統(tǒng)的主備冗余模式（Active－Standby）來(lái)支持一個(gè)Mesos集群中部署多個(gè)Mesos master節(jié)點(diǎn)，借助于ZooKeeper進(jìn)行Leader的選舉。選舉出的Leader負(fù)責(zé)將集群的資源以契約（offer）的形式發(fā)送給上層的每一個(gè)Framework，并處理集群管理員與上層Framework的請(qǐng)求，另外幾個(gè)Mesos master節(jié)點(diǎn)將作為Follower一直處于備用狀態(tài)，并監(jiān)控當(dāng)前的狀態(tài)，當(dāng)Mesos master節(jié)點(diǎn)宕機(jī)，或服務(wù)中斷之后，新Leader將會(huì)很快從Follower中選出來(lái)接管所有的服務(wù)，減少了Mesos集群服務(wù)的宕機(jī)時(shí)間，大大提高集群可用性。
　　Mesos高可用集群部署
　　在Mesos高可用設(shè)計(jì)中，引入了ZooKeeper集群來(lái)輔助Leader的選舉，這在當(dāng)前的分布式集群中比較流行，比如Docker Swarm高可用集群同時(shí)支持利用consul、etcd、ZooKeeper進(jìn)行Leader的選舉，Kubernetes也采用了etcd等實(shí)現(xiàn)了自身的高可用。這種設(shè)計(jì)可以理解為大集群＋小集群，小集群也就是ZooKeeper/etcd/consul集群，它們?yōu)榇蠹悍?wù)，比如提供Leader的選舉，為大集群提供配置數(shù)據(jù)的存儲(chǔ)和服務(wù)發(fā)現(xiàn)等功能。在一個(gè)復(fù)雜的系統(tǒng)中，這個(gè)小集群可以為系統(tǒng)的多個(gè)服務(wù)組件同時(shí)提供服務(wù)。因此在部署高可用Mesos集群時(shí)，必須首先部署好一個(gè)ZooKeeper集群。
　　本文主要介紹Mesos的高可用，不會(huì)詳細(xì)介紹ZooKeeper的相關(guān)知識(shí)你可以參考官方文檔（https://ZooKeeper.apache.org/）來(lái)部署。為了使讀者可以快速搭建它們自己的Mesos高可用集群，我們將使用Docker的方式在zhost1.wyq.com（9.111.255.10），zhost2.wyq.com（9.111.254.41）和zhost3.wyq.com（9.111.255.50）機(jī)器上快速的搭建起一個(gè)具有三個(gè)節(jié)點(diǎn)的演示ZooKeeper集群，它們的服務(wù)端口都是默認(rèn)的2181。
　　登錄zhost1.wyq.com機(jī)器，執(zhí)行如下命令啟動(dòng)第一個(gè)server：
　　# docker run -d \
　　-e MYID=1 \
　　-e SERVERS=9.111.255.10，9.111.254.41，9.111.255.50 \
　　--name=zookeeper \
　　--net=host \
　　--restart=always \
　　mesoscloud/zookeeper
　　登錄zhost2.wyq.com機(jī)器，執(zhí)行如下命令啟動(dòng)第二個(gè)server：
　　# docker run -d \
　　-e MYID=2 \
　　-e SERVERS=9.111.255.10，9.111.254.41，9.111.255.50 \
　　--name=zookeeper \
　　--net=host \
　　--restart=always \
　　mesoscloud/zookeeper
　　登錄zhost3.wyq.com機(jī)器，執(zhí)行如下命令啟動(dòng)第三個(gè)server：
　　# docker run -d \
　　-e MYID=3 \
　　-e SERVERS=9.111.255.10，9.111.254.41，9.111.255.50 \
　　--name=zookeeper \
　　--net=host \
　　--restart=always \
　　mesoscloud/zookeeper
　　ZooKeeper集群搭建好之后，執(zhí)行以下命令，通過(guò)指定一個(gè)不存在的znode的路徑/mesos來(lái)啟動(dòng)所有的Mesos master，Mesos slave和Framework。
　　登陸每一個(gè)Mesos master機(jī)器，執(zhí)行以下命令，在Docker中啟動(dòng)所有的Mesos master：
　　# docker run -d \
　　--name mesos-master \
　　--net host mesosphere/mesos-master \
　　--quorum=2 \
　　--work_dir=/var/log/mesos \
　　--zk= zk://zhost1.wyq.com:2181，zhost2.wyq.com:2181，zhost3.wyq.com:2181/mesos
　　登陸每一個(gè)Mesos Agent機(jī)器，執(zhí)行以下命令，在Docker中啟動(dòng)所有的Mesos agent：
　　# docker run -d \
　　--privileged \
　　-v /var/run/docker.sock:/var/run/docker.sock \
　　--name mesos-agent \
　　--net host gradywang/mesos-agent \
　　--work_dir=/var/log/mesos \
　　--containerizers=mesos，docker \
　　--master= zk://zhost1.wyq.com:2181，zhost2.wyq.com:2181，zhost3.wyq.com:2181/mesos
　　注意：Mesosphere官方所提供的Mesos Agent鏡像mesosphere/mesos-agent不支持Docker的容器化，所以作者在官方鏡像的基礎(chǔ)至上創(chuàng)建了一個(gè)新的鏡像gradywang/mesos-agent來(lái)同時(shí)支持Mesos和Docker的虛擬化技術(shù)。
　　使用相同的znode路徑來(lái)啟動(dòng)framework，例如我們利用Docker的方式來(lái)啟動(dòng)Docker Swarm，讓它運(yùn)行在Mesos之上：
　　$ docker run -d \
　　--net=host gradywang/swarm-mesos \
　　--debug manage \
　　-c mesos-experimental \
　　--cluster-opt mesos.address=9.111.255.10 \
　　--cluster-opt mesos.tasktimeout=10m \
　　--cluster-opt mesos.user=root \
　　--cluster-opt mesos.offertimeout=1m \
　　--cluster-opt mesos.port=3375 \
　　--host=0.0.0.0:4375 zk://zhost1.wyq.com:2181，zhost2.wyq.com:2181，zhost3.wyq.com:2181/mesos
　　注：mesos.address和mesos.port是Mesos scheduler的監(jiān)聽(tīng)的服務(wù)地址和端口，也就是你啟動(dòng)Swarm的機(jī)器的IP地址和一個(gè)可用的端口。個(gè)人感覺(jué)這個(gè)變量的命名不是很好，不能見(jiàn)名知意。
　　用上邊的啟動(dòng)配置方式，所有的Mesos master節(jié)點(diǎn)會(huì)通過(guò)ZooKeeper進(jìn)行Leader的選舉，所有的Mesos slave節(jié)點(diǎn)和Framework都會(huì)和ZooKeeper進(jìn)行通信，獲取當(dāng)前的Mesos master Leader，并且會(huì)一直檢測(cè)Master節(jié)點(diǎn)的變化。當(dāng)Leader故障時(shí)，ZooKeeper會(huì)第一時(shí)間選出新Leader，然后所有的Slave節(jié)點(diǎn)和Framework都會(huì)獲取到新Leader進(jìn)行重新注冊(cè)。
　　ZooKeeper Leader的選舉機(jī)制
　　根據(jù)ZooKeeper官方推薦的Leader選舉機(jī)制：首先指定一個(gè)Znode，如上例中的/mesos（強(qiáng)烈建議指定一個(gè)不存在的Znode路徑），然后使用SEQUENCE和EPHEMERAL標(biāo)志為每一個(gè)要競(jìng)選的client創(chuàng)建一個(gè)Znode，例如/mesos/guid_n來(lái)代表這個(gè)client。
　　當(dāng)為某個(gè)Znode節(jié)點(diǎn)設(shè)置SEQUENCE標(biāo)志時(shí)，ZooKeeper會(huì)在其名稱后追加一個(gè)自增序號(hào)，這個(gè)序列號(hào)要比最近一次在同一個(gè)目錄下加入的znode的序列號(hào)大。具體做法首先需要在ZooKeeper中創(chuàng)建一個(gè)父Znode，比如上節(jié)中指定的/mesos，然后指定SEQUENCE｜EPHEMERAL標(biāo)志為每一個(gè)Mesos master節(jié)點(diǎn)創(chuàng)建一個(gè)子的Znode，比如/mesos/znode-index，并在名稱之后追加自增的序列號(hào)。
　　當(dāng)為某個(gè)Znode節(jié)點(diǎn)設(shè)置EPHEMERAL標(biāo)志時(shí)，當(dāng)這個(gè)節(jié)點(diǎn)所屬的客戶端和ZooKeeper之間的seesion斷開(kāi)之后，這個(gè)節(jié)點(diǎn)將會(huì)被ZooKeeper自動(dòng)刪除。
　　ZooKeeper的選舉機(jī)制就是在父Znode（比如/mesos）下的子Znode中選出序列號(hào)最小的作為L(zhǎng)eader。同時(shí)，ZooKeeper提供了監(jiān)視（watch）的機(jī)制，其他的非master節(jié)點(diǎn)會(huì)不斷監(jiān)視當(dāng)前的Leader所對(duì)應(yīng)的Znode，如果它被刪除，則觸發(fā)新一輪的選舉。有兩種做法：
　　所有的非Leader client監(jiān)視當(dāng)前Leader對(duì)應(yīng)的Znode（也就是序列號(hào)最小的Znode），當(dāng)它被ZooKeeper刪除的時(shí)候，所有監(jiān)視它的客戶端會(huì)立即收到通知，然后調(diào)用API查詢所有在父目錄（/mesos）下的子節(jié)點(diǎn)，如果它對(duì)應(yīng)的序列號(hào)是最小的，則這個(gè)client會(huì)成為新的Leader對(duì)外提供服務(wù)，然后其他客戶端繼續(xù)監(jiān)視這個(gè)新Leader對(duì)應(yīng)的Znode。這種方式會(huì)觸發(fā)“羊群效應(yīng)”，特別是在選舉集群比較大的時(shí)候，在新一輪選舉開(kāi)始時(shí)，所有的客戶端都會(huì)調(diào)用ZooKeeper的API查詢所有的子Znode來(lái)決定誰(shuí)是下一個(gè)Leader，這個(gè)時(shí)候情況就更為明顯。
　　為了避免“羊群效應(yīng)”，ZooKeeper建議每一個(gè)非Leader的client監(jiān)視集群中對(duì)應(yīng)的比自己節(jié)點(diǎn)序小一號(hào)的節(jié)點(diǎn)（也就是所有序號(hào)比自己小的節(jié)點(diǎn)中的序號(hào)最大的節(jié)點(diǎn)）。只有當(dāng)某個(gè)client所設(shè)置的watch被觸發(fā)時(shí)，它才進(jìn)行Leader選舉操作：查詢所有的子節(jié)點(diǎn)，看自己是不是序號(hào)最小的，如果是，那么它將成為新的Leader。如果不是，繼續(xù)監(jiān)視。此 Leader選舉操作的速度是很快的。因?yàn)槊恳淮芜x舉幾乎只涉及單個(gè)client的操作。
　　Mesos高可用實(shí)現(xiàn)細(xì)節(jié)
　　Mesos主要通過(guò)contender和detector兩個(gè)模塊來(lái)實(shí)現(xiàn)高可用，架構(gòu)如圖2所示。
　　
　　圖2 Mesos的contender和detector模塊架構(gòu)圖
　　Contender模塊用來(lái)進(jìn)行Leader選舉，它負(fù)責(zé)把每個(gè)Master節(jié)點(diǎn)加入到選舉的Group中（作為/mesos目錄下的一個(gè)子節(jié)點(diǎn)），組中每個(gè)節(jié)點(diǎn)都會(huì)有一個(gè)序列號(hào)，根據(jù)上文對(duì)ZooKeeper選舉機(jī)制的介紹，組中序列號(hào)最小的節(jié)點(diǎn)將被選舉為L(zhǎng)eader。
　　以上文例子為例（假設(shè)作者部署了三個(gè)節(jié)點(diǎn)的Mesos master），可以查看ZooKeeper的存儲(chǔ)來(lái)加以驗(yàn)證。
　　登錄到ZooKeeper集群中的某一個(gè)節(jié)點(diǎn)，執(zhí)行如下命令鏈接到集群中的某個(gè)節(jié)點(diǎn)，查看這個(gè)Group：
　　# docker ps
　　CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
　　a6fab50e2689 mesoscloud/zookeeper “/entrypoint.sh zkSer” 50 minutes ago Up 49 minutes zookeeper
　　# docker exec -it a6fab50e2689 /bin/bash
　　# cd /opt/zookeeper/bin/
　　# 。/zkCli.sh -server 9.111.255.10:2181
　?。踷k： 9.111.255.10:2181（CONNECTED） 0］ ls /mesos
　?。踛son.info_0000000003， json.info_0000000004， json.info_0000000002， log_replicas］
　　我們可以看到在/mesos目錄下有三個(gè)帶有后綴序號(hào)的子節(jié)點(diǎn)，序號(hào)值最小的節(jié)點(diǎn)將作為master節(jié)點(diǎn)，查看序號(hào)最小的節(jié)點(diǎn)json.info_0000000002的內(nèi)容如下：
　?。踷k： 9.111.255.10:2181（CONNECTED） 1］ get /mesos/json.info_0000000002
　　{“address”：{“hostname”：“gradyhost1.eng.platformlab.ibm.com”，“ip”：“9.111.255.10”，“port”：5050}，“hostname”：“gradyhost1.eng.platformlab.ibm.com”，“id”：“93519a55-4089-436c-bc07-f7154ec87c79”，“ip”：184512265，“pid”：“master@9.111.255.10:5050”，“port”：5050，“version”：“0.28.0”}
　　cZxid = 0x100000018
　　ctime = Sun May 22 08:42:10 UTC 2016
　　mZxid = 0x100000018
　　mtime = Sun May 22 08:42:10 UTC 2016
　　pZxid = 0x100000018
　　cversion = 0
　　dataVersion = 0
　　aclVersion = 0
　　ephemeralOwner = 0x254d789b5c20003
　　dataLength = 264
　　numChildren = 0
　　根據(jù)查詢結(jié)果，當(dāng)前的Mesos master節(jié)點(diǎn)是
　　gradyhost1.eng.platformlab.ibm.com。
　　Detector模塊用來(lái)感知當(dāng)前的master是誰(shuí)，它主要利用ZooKeeper中的watcher的機(jī)制來(lái)監(jiān)控選舉的Group（/mesos目錄下的子節(jié)點(diǎn)）的變化。ZooKeeper提供了getChildren（）應(yīng)用程序接口，此接口可以用來(lái)監(jiān)控一個(gè)目錄下子節(jié)點(diǎn)的變化，如果一個(gè)新子節(jié)點(diǎn)加入或者原來(lái)的節(jié)點(diǎn)被刪除，那么這個(gè)函數(shù)調(diào)用會(huì)立即返回當(dāng)前目錄下的所有節(jié)點(diǎn)，然后Detector模塊可以挑選序號(hào)最小的作為master節(jié)點(diǎn)。
　　每一個(gè)Mesos master會(huì)同時(shí)使用Contender和Detector模塊，用Contender進(jìn)行master競(jìng)選。在master節(jié)點(diǎn)上使用Detector模塊的原因是在Mesos的高可用集群中，你可以使用任意一個(gè)master節(jié)點(diǎn)的地址和端口來(lái)訪問(wèn)Mesos的WebUI，當(dāng)訪問(wèn)一個(gè)Replica節(jié)點(diǎn)時(shí)，Mesos會(huì)把這個(gè)瀏覽器的鏈接請(qǐng)求自動(dòng)轉(zhuǎn)發(fā)到通過(guò)Detector模塊探測(cè)到的master節(jié)點(diǎn)上。
　　其他的Mesos組件，例如Mesos Agent，F(xiàn)ramework scheduler driver會(huì)使用Detector模塊來(lái)獲取當(dāng)前的Mesos master，然后向它注冊(cè)，當(dāng)master發(fā)送變化時(shí)，Detecor模塊會(huì)第一時(shí)間通知，它們會(huì)重新注冊(cè)（re-register）。
　　由于IBM在Mesos社區(qū)的推動(dòng)，在MESOS-4610項(xiàng)目中，Mesos Contender和Detector已經(jīng)可以支持以插件的方式進(jìn)行加載。現(xiàn)在Mesos社區(qū)官方僅支持用Zookeeper集群進(jìn)行Leader選舉，在支持了插件的方式加載后，用戶可以實(shí)現(xiàn)自己的插件，用另外的方式比如選擇用etcd（MESOS-1806）、consule（MESOS-3797）等集群進(jìn)行Leader選舉。
　　注意：現(xiàn)在Mesos僅用ZooKeeper進(jìn)行Leader的選舉，并沒(méi)有用它進(jìn)行數(shù)據(jù)的共享。在Mesos中有一個(gè)Replicated Log模塊，負(fù)責(zé)進(jìn)行多個(gè)master之間的數(shù)據(jù)共享、同步等?？梢詤⒖糓esos官方文檔獲取詳細(xì)設(shè)計(jì)（http://mesos.apache.org/documentation/latest/replicated-log-internals/）。同時(shí)為了使Mesos的高可用不依賴與一個(gè)第三方的集群，現(xiàn)在社區(qū)正在考慮用Replicated log替代第三方集群進(jìn)行Leader選舉，具體進(jìn)度可以參考MESOS-3574項(xiàng)目。
　　Mesos master recovery
　　在Mesos設(shè)計(jì)中，master除了要在Replicated log中持久化一些集群配置信息（例如Weights、Quota等），0集群maintenance的狀態(tài)和已經(jīng)注冊(cè)的Agent的信息外，基本上被設(shè)計(jì)為無(wú)狀態(tài)的。master發(fā)生failover，新的master選舉出來(lái)之后：
　　它會(huì)首先從Replicated log中恢復(fù)之前的狀態(tài)，目前Mesos master會(huì)從Replicated log中recover以下信息。
　　Mesos集群的配置信息，例如weights，quota等。這些配置信息是Mesos集群的管理員通過(guò)HTTP endpoints來(lái)配置的。
　　集群的Maintenance信息。
　　之前注冊(cè)的所有的Agent信息（SlaveInfo）。
　　同時(shí)master會(huì)為Agents 的重新注冊(cè)（re-register）設(shè)置一個(gè)超時(shí)時(shí)間（這個(gè)參數(shù)通過(guò)master的slave_reregister_timeout flag進(jìn)行配置，默認(rèn)值為10分鐘），如果某些Agents在這個(gè)時(shí)間內(nèi)沒(méi)有向新master重新注冊(cè)，將會(huì)從Replicated log中刪除，這些Agents將不能以原來(lái)的身份（相同的SlaveId）重新注冊(cè)到新的Mesos master，其之前運(yùn)行的任務(wù)將全部丟失。如果這個(gè)Agent想再次注冊(cè)，必須以新的身份。同時(shí)為了對(duì)生產(chǎn)環(huán)境提供安全保證，避免在failover之后，大量的Agents從Replicated log中刪除進(jìn)而導(dǎo)致丟失重要的運(yùn)行任務(wù)，Mesos master提供了另外一個(gè)重要的flag配置recovery_slave_removal_limit，用來(lái)設(shè)置一個(gè)百分比的限制，默認(rèn)值為100%，避免過(guò)多的Agents在failover之后被刪除，如果將要?jiǎng)h除的Agents超過(guò)了這個(gè)百分比，那么這個(gè)Mesos master將會(huì)自殺（一般的，在一個(gè)生產(chǎn)環(huán)境中，Mesos的進(jìn)程將會(huì)被Systemd或者其他進(jìn)程管理程序進(jìn)行監(jiān)管，如果Mesos服務(wù)進(jìn)程退出，那么這個(gè)監(jiān)管程序會(huì)自動(dòng)再次啟動(dòng)Mesos服務(wù)）。而不是把那些Agents從Replicated log中刪除，這會(huì)觸發(fā)下一次的failover，多次failover不成功，就需要人為干預(yù)。
　　另外，新的Mesos master選舉出來(lái)之后，所有之前注冊(cè)的Mesos agents會(huì)通過(guò)detector模塊獲取新的master信息，進(jìn)而重新注冊(cè)，同時(shí)上報(bào)它們的checkpointed資源，運(yùn)行的executors和tasks信息，以及所有tasks完成的Framework信息，幫助新master恢復(fù)之前的運(yùn)行時(shí)內(nèi)存狀態(tài)。同樣的原理，之前注冊(cè)的Framework也會(huì)通過(guò)detector模塊獲取到新的Master信息，向新master重新注冊(cè)，成功之后，會(huì)獲取之前運(yùn)行任務(wù)的狀態(tài)更新以及新的offers。
　　注意：如果在failover之后，之前注冊(cè)并且運(yùn)行了任務(wù)的Frameworks沒(méi)有重新注冊(cè)，那么它之前運(yùn)行的任務(wù)將會(huì)變成孤兒任務(wù)，特別對(duì)于哪些永久運(yùn)行的任務(wù)，將會(huì)一直運(yùn)行下去，Mesos目前沒(méi)有提供一種自動(dòng)化的機(jī)制來(lái)處理這些孤兒任務(wù)，比如在等待一段時(shí)間之后，如果Framework沒(méi)有重新注冊(cè)，則把這些孤兒任務(wù)殺掉?，F(xiàn)在社區(qū)向通過(guò)類(lèi)似Mesos Agents的邏輯，來(lái)持久化Framework info，同時(shí)設(shè)置一個(gè)超時(shí)的配置，來(lái)清除這些孤兒任務(wù)。具體可以參見(jiàn)MESOS-1719。
　　Mesos Agent健康檢查
　　Mesos master現(xiàn)在通過(guò)兩種機(jī)制來(lái)監(jiān)控已經(jīng)注冊(cè)的Mesos Agents健康狀況和可用性：
　　Mesos master會(huì)持久化和每個(gè)Agent之間的TCP的鏈接，如果某個(gè)Agent服務(wù)宕機(jī)，那么master會(huì)第一時(shí)間感知到，然后：
　　1-1. 把這個(gè)Agent設(shè)為休眠狀態(tài)，Agent上的資源將不會(huì)再offer給上層Framework。
　　1-2. 觸發(fā)rescind offer，把這個(gè)Agent已經(jīng)offer給上層Framework的offer撤銷(xiāo)。
　　1-3. 觸發(fā)rescind inverse offer，把inverse offer撤銷(xiāo)。
　　同時(shí)，Mesos master會(huì)不斷的向每一個(gè)Mesos Agent發(fā)送ping消息，如果在設(shè)定時(shí)間內(nèi)（由flag.slave_ping_timeout配置，默認(rèn)值為15s）沒(méi)有收到對(duì)應(yīng)Agent的回復(fù)，并且達(dá)到了一定的次數(shù)（由flag. max_slave_ping_timeouts 配置，默認(rèn)值為5），那么Mesos master會(huì)：
　　2-1. 把這個(gè)Agent從master中刪除，這時(shí)資源將不會(huì)再offer給上層的Framework。
　　2-2. 遍歷這個(gè)Agent上運(yùn)行的所有的任務(wù)，向?qū)?yīng)的Framework發(fā)送TASK_LOST狀態(tài)更新，同時(shí)把這些任務(wù)從master刪除。
　　2-3. 遍歷Agent上的所有executor，把這些executor刪除。
　　2-4. 觸發(fā)rescind offer，把這個(gè)Agent上已經(jīng)offer給上層Framework的offer撤銷(xiāo)。
　　2-5. 觸發(fā)rescind inverse offer，把inverse offer撤銷(xiāo)。
　　2-6. 把這個(gè)Agent從master的Replicated log中刪除。
　　Mesos Framework健康檢查
　　同樣的原理，Mesos master仍然會(huì)持久化和每一個(gè)Mesos Framework scheculer之間的TCP的連接，如果某一個(gè)Mesos Framework服務(wù)宕機(jī)，那么master會(huì)第一時(shí)間感知，然后：
　　把這個(gè)Framework設(shè)置為休眠狀態(tài)，這時(shí)Mesos master將不會(huì)在把資源offer給這個(gè)Framework 。
　　觸發(fā)rescind offer，把這個(gè)Framework上已經(jīng)收到的offer撤銷(xiāo)。
　　觸發(fā)rescind inverse offer，把這個(gè)Framework上已經(jīng)收到的inverse offer撤銷(xiāo)。
　　獲取這個(gè)Framework注冊(cè)的時(shí)候設(shè)置自己的failover時(shí)間（通過(guò)Framework info中的failover_timeout參數(shù)設(shè)置），創(chuàng)建一個(gè)定時(shí)器。如果在這個(gè)超時(shí)時(shí)間之內(nèi)，F(xiàn)ramework沒(méi)有重新注冊(cè)，則Mesos master會(huì)把Framework刪除：
　　4-1. 向所有注冊(cè)的Slave發(fā)送刪除此Framework的消息。
　　4-2. 清除Framework上還沒(méi)有執(zhí)行的task請(qǐng)求。
　　4-3. 遍歷Framework提交的并且正在運(yùn)行的任務(wù)，發(fā)送TASK_KILLED消息，并且把task從Mesos master和對(duì)應(yīng)的Agent上刪除。
　　4-4. 觸發(fā)rescind offer，把這個(gè)Framework上已經(jīng)收到的offer撤銷(xiāo)。
　　4-5. 觸發(fā)rescind inverse offer，把Framework上已經(jīng)收到的inverse offer撤銷(xiāo)。
　　4-6. 清除Framework對(duì)應(yīng)的role。
　　4-7. 把Framework從Mesos master中刪除。
　　未來(lái)展望
　　從我個(gè)人的角度看，Mesos高可用這個(gè)功能應(yīng)該做如下增強(qiáng)。
　　現(xiàn)在的設(shè)計(jì)中，Mesos的高可用必須依賴一個(gè)外部的ZooKeeper集群，增加了部署和維護(hù)的復(fù)雜度，并且目前這個(gè)集群只是用來(lái)做Leader選舉，并沒(méi)有幫助Mesos master節(jié)點(diǎn)之間存儲(chǔ)和共享配置信息，例如Weights、Quota等。社區(qū)現(xiàn)在已經(jīng)發(fā)起了一個(gè)新項(xiàng)目MESOS-3574，將研究和實(shí)現(xiàn)用Replicated log來(lái)替代ZooKeeper，幫助Mesos master選舉和發(fā)現(xiàn)Leader。個(gè)人認(rèn)為價(jià)值比較大，它實(shí)現(xiàn)之后，可以大大簡(jiǎn)化Mesos高可用架構(gòu)的復(fù)雜度。
　　現(xiàn)在ZooKeeper作為搭建Mesos高可用集群的唯一選擇，可能在比較大的集成系統(tǒng)中不合時(shí)宜，在IBM工程師的推動(dòng)下，社區(qū)已經(jīng)將和Mesos高可用的兩個(gè)模塊Contender和Detector插件化，用戶可以實(shí)現(xiàn)自己的插件來(lái)進(jìn)行Mesos master的選舉和發(fā)現(xiàn)，已經(jīng)實(shí)現(xiàn)了對(duì)etcd的支持。感興趣的同學(xué)可以參考MESOS-1806項(xiàng)目。
　　另外，Mesos現(xiàn)在這個(gè)高可用的設(shè)計(jì)采用了最簡(jiǎn)單的Active-standby模式，也就是說(shuō)只有當(dāng)前的Mesos master在工作，其他的candidate將不會(huì)做任何事情，這會(huì)導(dǎo)致資源的浪費(fèi)。另外在特別大的Mesos集群中，master candidates并不能提供負(fù)載均衡。未來(lái)是不是可以考慮將Mesos高可用修改為Active-Active模式，比如讓master candidates可以幫助處理一些查詢的請(qǐng)求，同時(shí)可以幫助轉(zhuǎn)發(fā)一些寫(xiě)請(qǐng)求到當(dāng)前的master上，來(lái)提高整個(gè)集群的性能和資源利用率。
?