免费开通大数据服务：https://www.aliyun.com/product/odps

转载自xingbao

各位好，这是介绍阿里云伏羲(fuxi)调度器系列文章的第三篇，今天主要介绍针对在线服务的资源强稳定

一、FuxiMaster简介

FuxiMaster和Yarn非常相似，定位于分布式系统中资源管理与分配的角色：一个典型的资源分配流程图如下所示： 




作为调度器，目前FuxiMaster支持的功能主要有：

1、多租户管理

2、支持FIFO/FAIR调度策略

3、针对在线服务保持资源强稳定（本文）

4、支持NodeLabel动态划分集群

5、支持多机房调度

6、支持基于优先级的交互式抢占

7、支持AllOrNothing调度

8、支持基于硬件ID化的调度

9、单Master目前支持2w台机器的规模

10、......

一、Fuxi的资源协议交互流程

正常场景分配资源

1、FuxiMaster分配资源后，会同时给作业(AM，下同)和机器节点(Tubo，下同)分配一个凭证： 给AM发送的叫做Hint, 告诉AM你可以在哪些机器上起分别起几份资源； 给Tubo发送的叫做Cap，告诉哪些AM在你这可以分别起几份资源；

2、AM收到FM的Hint后，会分别为每个slot准备启动的plan，然后发送给对应的tubo；

3、(Tubo收到FM的cap后，会等待AM发送plan，在收到plan之前不会有动作) or  (Tubo 收到AM的plan后，会等待FM发送cap， 在收到cap之前不会有动作)

4、当Tubo同时收到来自AM的Hint以及来自FM的Cap后，会在本地拉起worker

异常场景定义：

系统中存在FuxiMaster\Tubo\AM三个角色，根据timeout和failover的排列组合，总共有下述17种异常场景：

资源调度器：FuxiMaster， 作业管理器：AM， 机器节点：tubo

对于离线作业和在线服务，他们对于异常情况的容忍度是不一样的： 对于以SQL、MR为代表的离线作业，他们对于资源revoke并不明显，只要换一台机器重新跑就好了，影响只是运行时间会增加； 对于在线服务，可能重启一个worker都会造成故障，尤其是这种FuxiMaster未经AM同意、不给AM做准备的资源Revoke，对于在线服务是不能接受的。


我举两个例子来说明在线服务和离线作业在异常场景下的行为：

异常场景之一：FuxiMaster发生failover

由于FuxiMaster对调度结果不会做checkpoint，所以每次failover时，fuximaster的内存是空的，需要借助AM和tubo进行恢复：

1、FuxiMaster重启后，会在60s的时间内等待tubo和am向自己polling消息

2、tubo会将自己全量的cap发送给FuxiMaster， AM会将自己全量的Request和Hint发送给FuxiMaster

3、60s结束，FuxiMaster会根据AM的Request和tubo的cap做一个Recover动作，尝试恢复之前的调度结果；

    针对离线作业：如果有的tubo没有连上来，那么所有AM在这台机器上的资源FuxiMaster都会认为不可用， AM会收到资源回收的消息； 如果有的AM没有连上来，那么这个AM所有的资源FuxiMaster都会认为不存在（因为没有request），到下次AM连上来时，会收到所有资源被回收的消息
 
    针对在线服务：无论是tubo还是AM没有连上来，都不能主动回收我的资源；

这里需要特别指出的是，当FuxiMaster failover时，FM会同时收到tubo的cap和AM的hint，在正常逻辑下，是不看AM的hint的，因为AM是用户自己的逻辑，可能会误发、错发；而tubo只是转发FuxiMaster曾经发送给他的cap， 可信度是相对较高的

异常场景之二：Tubo发生Timeout

1、tubo和FuxiMaster之间存在心跳，表示两者都在正常工作；当FuxiMaster感知到tubo timeout时：

     针对离线作业： FuxiMaster会revoke AM在这台机器上的所有资源，并尝试分配新的资源

     针对在线服务： 不许回收我的资源，你可以将这台机器异常的情况告诉我，我自己来做判断是否还资源；


下面会针对17种异常场景来一一分析如何通过 Hint\Cap\Request来保证全异常场景下在线服务如何保持stable

二、异常场景下的在线服务资源稳定

1、FuxiMaster failover

FuxiMastr failover时，根据tubo的cap和AM的request来恢复资源


2、AM failover



AM failover时，会向FM汇报全量request， FM会向AM发送一个全量的hint来帮助AM完成failover


3、AM timeout



当AM timeout时，在超时时间内FuxiMaster不做动作；在超时时间外FuxiMaster会为AM找一台新的机器重新调度新的AM，并完成failover


4、tubo failover



当tubo failover时，他会向FuxiMaster请求一个全量的cap来完成自己的failover


5、tubo timeout



当tubo timeout时，FuxiMaster不会revoke在线服务的那部分cap，当tubo再次连回FuxiMaster时，FuxiMaster会将这部分stable的cap再次发送给tubo


6、AM failover && tubo failover


AM failover和tubo failover互不冲突，可以各自处理


7、AM failover && tubo timeout


AM failover和tubo timeout互不冲突，可以各自处理


8、AM timeout && tubo failover


AM timeout和tubo failover互不冲突，可以各自处理


9、AM timeout && tubo timeout



AM timeout和tubo timeout互不冲突，可以各自处理


10、FuxiMaster failover && AM failover

 

当FuxiMaster和AM failover时，FuxiMaster会等待重启的AM发送全量的request以及tubo发送全量的cap来恢复资源



11、FuxiMaster failover && AM timeout



当FuxiMaster failover期间AM没有连上来时，FuxiMaster这个时候只能收到tubo的cap，而没有AM的request； 此时，FuxiMaster会根据Tubo的cap来mock出对应的LT_CLUSTER Level的Request去recover这部分cap；当新的reschedule的AM连回来时，会将这部分mock的request转化成真正的request； 假设在AM连回来前tubo发生timeout，当作普通的tubo timeout来保证stable



12、FuxiMaster failover && tubo restart


当tubo重启时，tubo内存的中cap就丢失了；为了解决这个场景，tubo在每次收到FM的cap时都会本地做checkpoint


13、FuxiMaster failover && tubo timeout



在FuxiMaster failover期间tubo没有连上来，之前我们说过AM会向FuxiMaster发送全量的request和hint，但是FuxiMaster在tubo连上来的场景下只相信tubo的cap，而不相信hint；在这里AM发送的hint发挥了作用，我们通过AM的hint来恢复在没有连上来的tubo上面的cap，当tubo连回来时，就可以取走这部分cap


14、FuxiMaster failover && AM failover && tubo failover



在fuximaster failover期间，AM failover和tubo failover互不冲突，可以分别处理


15、FuxiMaster failover && AM failover && tubo timeout



由于AM failover会向FuxiMaster发送全量的request和全量的hint（全量的hint由在线服务自己做checkpoint），所以这个场景等价于FuxiMaster failover && tubo timeout


16、FuxiMaster failover && AM timeout && tubo failover


这个场景等价于FuxiMaster failover && AM timeout


17、FuxiMaster failover && AM timeout && tubotimeout


这个场景最为复杂，当AM先于tubo连回来时，可以参照AM的hint来恢复timeout tubo上面的cap； 当tubo先于AM连回来时，可以根据tubo的cap来mock request；

阅读原文请点击

【大数据技术干货】阿里云伏羲(fuxi)调度器FuxiMaster功能简介(三) 针对在线服务的资源强稳定