【大数据技术干货】阿里云伏羲(fuxi)调度器FuxiMaster功能简介(四) NodeLabel调度
原文链接:http://click.aliyun.com/m/13952/
各位好,这是介绍阿里云伏羲(fuxi)调度器系列文章的第四篇,今天主要介绍NoedLabel的调度策略
一、FuxiMaster简介
FuxiMaster和Yarn非常相似,定位于分布式系统中资源管理与分配的角色:一个典型的资源分配流程图如下所示:
作为调度器,目前FuxiMaster支持的功能主要有:
1、多租户管理
2、调度模型及FIFO/FAIR调度策略
3、针对在线服务保持资源强稳定
4、支持NodeLabel动态划分集群(本文)
5、支持多机房调度
6、支持基于优先级的交互式抢占
7、支持AllOrNothing调度
8、支持基于硬件ID化的调度
9、单Master目前支持2w台机器的规模
10、......
一、NodeLabel的定义
NodeLabel的定义是placement constraints: which resources are consumed;在使用上,是对集群内机器进行静态划分,比如将SSD机器于SATA机器分开供不同的类型的作业使用;又或者控制在线服务和离线作业在同一个集群内混跑,但是跑在不同机器上以消除互相影响。 总之,NodeLabel功能使得将异构的机器或者异构作业部署在同一个集群变的更加容易
那对于NodeLabel用户会存在什么样的需求呢?
1、用户会提出基于若干Label组合的请求,比如:用户作业必须只能跑在操作系统是Linux、磁盘类型是SSD、内核版本是2.0的机器上,这就需要资源调度器能够筛出符合所有标签组合的机器。
2、用户对label的请求不一定是严格等于,可能是“大于”、“小于”这样的语义。例如:用户的作业可以跑在内核版本大于等于2.0的机器上,所以内核版本是2.0、2.1、2.2的机器都是可以分配给用户作业的,即:资源调度器能够支持用户作业中的标签请求具有比较运算符的语义,如大于、小于、不等于等等。
3、用户会对label请求描述“态度”:有的用户作业必须跑在具有某些标签的机器上,如果资源调度器发现在这些机器上没有可用的资源,那么用户作业宁可排队等待,我们称这种“态度”为强制的。有的用户作业要求尽量跑在具有某些label的机器上,这些机器没有资源时,用户作业也希望资源调度器能够分配其他不符合标签请求的机器上,我们称这种“态度”是非强制性的。
4、自适应物理拓扑,满足在RACK\SWITCH\ENGINEROOM\CLUSTER拓扑下面挑选满足条件的label机器
5、支持机器支持label排他的语义: 当机器处于label排他状态时,本机器只能让label请求满足条件的作业跑上来; 反之,当机器处于非label排他状态时,本机器可以让label请求不满足的作业也能跑上来,这个主要是针对提高资源的利用率,尤其是在线离线混步的场景
二、NodeLabel调度的实现
1、Label的定义
机器标签用“主键、键值”的组合来描述。假设一台机器的标签为:内核(Kernal)版本是1.9、操作系统(OS)是linux、磁盘(Disk)类型是SATA,那么内核(Kernal)版本、操作系统(OS)、磁盘(Disk)类型就是主键、而1.9、linux、SATA就是每一个主键对应的键值。每一个主键可以对应多个键值,如:内核(Kernal)版本有1.9、2.0、2.1三个值,操作系统(OS)有linux、windows两个值。对于一台机器,每一个主键只能用对应一个键值,即机器的操作系统(OS)不可能即是linux又是windows,, 上述如下图所示:
2、对label的申请描述
申请标签资源时,会以“主键、运算符、键值”的组合方式向FuxiMaster申请资源,例如,申请“内核(Kernal)版本大于等于1.9、操作系统(OS)等于windows、磁盘(Disk)类型不等于SSD”的机器资源。这里内核(Kernal)版本、操作系统(OS)、磁盘(Disk)是“主键”,大于等于、等于、不等于是“运算符”,1.9、windows、SSD是键值。我们定义运算符可以有6种取值,分别是:等于、大于、大于等于、小于、小于等于、不等于, 如下图所示:
3、label的管理
为了下文叙述方便,我们将每一个键值用字母代替,如下图所示:
FuxiMaster在接收到机器的label后,会将每一个“主键”的“键值”提取出来,并串联起来作为这个机器的识别码,例如机器1的标签组合是“内核版本为A、操作系统类型是D、磁盘类型是F”,那么这台机器的标签识别码就是ADF。
获取了每台机器的识别码后,我们要建立两个表。第一个表是标签识别码-机器映射表:由于许多台机器可能拥有相同的标签识别码,所以我们需要知道对应每一种标签识别码,究竟对应的是哪些机器,如图所示:
另外一个表是键值-标签识别码映射表:我们需要知道对应每一个单独的键值,究竟有那些标签识别码是包含这个键值的,这在为作业管理器分配资源的时候会发挥作用,如图所示:
4、分配逻辑
通过分析请求中每个主键对应的标签,我们可以得到一组候选的label集合列表,如下图所示:
我们需要找出哪些label组合出现的次数等于请求中主键的个数,这个可以通过堆来实现,如下图所示:
5、物理拓扑
在不同的物理拓扑下,我们会分别建立上述的各种索引表:
6、Label的态度
Label的Attitude是来描述对于label的态度:
1、OPER_HARD_AFFINITY:必须要满足标签的机器,如果资源不满足就进入队列排队;
2、SOFT_HARD_AFFINITY: 尽量要满足标签的机器,如果这些机器未能满足,则也可在其他机器上分配
3、OPER_HARD_UNTI_AFFINITY: 必须不要满足条件的这些机器,如果资源不满足就进入队列排队
4、OPER_SOFT_UNTI_AFFINITY: 尽量不要满足条件的这些机器,其他机器未满足也可以在这些机器上分配
转载于:https://blog.51cto.com/11778640/1906679