189 8069 5689
如何进行Mesos资源调度器的实现分析，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：国际域名空间、网站空间、营销软件、网站建设、丽江网站维护、网站推广。
mesos调度器是根据DRF（dominant resource fairness）算法实现的。DRF算法背后的直观想法是在多资源类型的环境下，一个用户的资源分配应该由用户的dominant share（主导份额的资源）决定，dominant share是在所有已经分配给用户的多种资源中，占据最大份额的一种资源。
mesos使用resource offers的方式实现各个框架之间的资源分配。Resource offer是多个slave节点上的一组空闲资源。Master根据调度策略来决定提供多少资源给每一个framework，通过以Resource offer的形式发送给发送给框架，然后框架响应Resource offer，确认Resource offer中已使用的资源和返回剩余的空闲资源。
mesos的资源分配器是一个分层的加权max-min fairness的实现。通过抽象了一个role概念，将framework按照role进行分组。那么资源分配就可以分为两层：首先是在各个框架群组间通过加权的DRF算法进行排序；其次在框架群组内部，对各个framework使用加权DRF算法进行排序。然后按照最终的排序结果，从小到大对各个框架进行Resource Offer。如下图所示。
Mesos的调度器实现分为两部分，分别是Allocators和sorter，Allocator定义和实现了资源分配器的接口和逻辑。Sorter对资源使用者进行排序，使用具体的资源分配算法来进行排序。
Sorter的实现是DRFSorter，DRFSorter使用DRF算法来对资源使用者进行排序。
Allocator的实现HierarchicalAllocatorProcess，实现了一个分层的分配器，对framework进行分组，分别在各组之间和组内部使用DRFSorter进行排序。
DRFSorter通过每个用户的dominant share的值实现对client排序。DRFSorter中的几个概念如下：
1、Client：资源的使用者。定义如下
struct Client
{
std::string name; //资源使用者名称
double share; //资源使用者的分配到的资源份额
};
Client之间的排序是首先比较share值的大小，如果在share相等的前提下则需要比较name的大小。
2、Resource：表示一种资源，包含资源name、资源的值以及资源被那些framework偏好。Pb的定义如下：
message Resource {
required string name = 1; //资源名称
required Value.Type type = 2; //资源值的类型Scalar
optional Value.Scalar scalar = 3; //值类型为标量，Cpu和内存的值类型都为标量
optional Value.Ranges ranges = 4; //值类型为范围
optional Value.Set set = 5; //值类型为集合
optional string role = 6 [default = "*"]; //框架对于资源的偏好
}
Mesos的应用环境是多资源类型的集群环境，所有可以框架申请的是多种资源，通过Resource数组来表示。
3、Weight：各个client的资源分配的权重。定义的类型为double
如下图所示，为了对client的进行排序，DRFSorter需要在内部维护了一些信息，见下图：
dirty：表示DRFSorter的资源分配发生更改，需要重新计算各个client的share值。
clients：资源使用者的集合，使用红黑树，按照client的dominant share值进行排序。
Resources：此DRFSorter拥有的总资源值。
整个DRFSorter的接口有两类，第一类是增加、删除和修改client和resource，在资源发生变化时，DRFSorter会将dirty置为true。第二类是对client进行排序，在dirty为true的情况下，会对所有的client重新计算dominant share的值，然后重新插入集合中，返回排序结果。
DRFSorter的核心排序流程如下：
| 如果dirty标志位为true
| 遍历clients集合，计算各个client的share值
| 计算client的各个resource的值占DRFSorter此类型资源总值的比例，
找出最大值然后再除以client的权重，就得到了client的share值。
公式为：Share = 
，
为client分配到的资源i的值，
为资源i在DRFSorter中的总值。W为client的权重。
| 再重新插入client，进行重排序。
| 返回排序后的结果。
实现了一个分层的分配器，如下图所示，用户可以根据role对framework进行分组，在RoleInfo指定framework group的权重，专门有一个DRFSorter对各个framework分组的资源分配进行排序。然后各个framework group内部还有一个DRFSorter对group内部的各个framework的资源分配进行排序。
Allocator的一些概念如下
1、Framework：应用程序框架，向mesos获取集群资源，下发具体的计算任务，是集群的使用者。
struct Framework
{
hashset
bool checkpoint; //是否正在进行checkpoint
FrameworkInfo info; //framework的信息
};
2、Slave：运行在各个集群节点的后台任务，执行具体的计算任务，上报节点的资源和负载。
struct Slave
{
.............
Resources available; //当前可用的资源
bool whitelisted; //是否在白名单中，如果false，则不能进行resource offer
bool checkpoint; //是否正在checkpoint，如果正在进行checkpoint，是不能进行resource offer
SlaveInfo info; //slave信息
};
3、Role：用于对framework进行分组，可以为每组framework指定一个weight。Role的信息RoleInfo如下。
message RoleInfo {
required string name = 1;
optional double weight = 2 [default = 1];
}
4、Whitelist：指定了有效的slave，如果制定了白名单，那么白名单内的slave是有效的。
过滤器：用于框架对slave的资源进行过滤，可以用于拒绝特定slave上的资源。
为了实现资源分配，allocator需要在内部维护如下一些信息，见下图。
frameworks：框架的映射，从framework Id到框架信息的映射。
slaves：slave的映射，从slave Id到slave信息的映射。
roles：框架分组信息的映射。
FrameworkSorters：框架群组内部DRF排序容器的映射。
Role Sorter：框架群组之间进行DRF排序的容器。
allocator核心的调度逻辑：
| 对framework group进行从小到大排序（framework按照role进行分组）
| 遍历排序后的framework group
| 在group组内对各个framework进行排序
| 遍历排序后的framework
| 遍历slave集合，将满足要求的所有slave的可用资源发送给框架
| 提取slave中role为”*”的所有可用资源资源，”*”表示一般普适的资源。
| 提取与framework group的role相同的所有可用的slave资源
（此为提取框架偏好的slave资源）。
| 判断slave资源是否满足条件：
| 过滤资源，如果slave或者framework正在进行checkpoint或者
资源被framework中设定的过滤器过滤掉。则放弃资源
| slave不在白名单中，放弃资源。
| slave的资源小于最小资源限定，放弃资源。
| 将以上都条件都满足的资源加入到资源结果集合中，
并更新slave的可用资源（需要减去已经放入到结果集合中的资源）
| 如果资源结果集合不为空
| 更新资源，即slave中可用资源
| 执行resource offer操作，将资源下发给框架
分配器在以下情况下进行resource offer：
1、在新的slave加入到mesos集群中。
2、在新的framework加入到mesos集群中。
3、在定时地执行资源分配，时间可以通过配置文件进行配置。
allocator在资源分配时，提供了如下四个机制：
1、过滤器：框架可以设置过滤器来拒绝的特定资源。比如framework在某一个slave上多次执行失败，那么framework就可以通过对这个slave设定过滤器来拒绝这个slave上的资源。
2、slave的白名单：不在白名单内的slave不参与resource offer。
3、slave的最小资源限定：mesos的资源调度等同于一个装箱问题。装箱问题的浪费空间与物体的最大大小和箱子的大小的比率相关，箱子越大物体越小那么利用率越高。但是当一个集群被请求小量资源的任务占满时，那么一个请求大量资源的框架可能会饥饿。为了适应请求大资源任务的框架，mesos通过设定slave节点最小资源限定，来避免在slave上进行offer resource，直到slave上的空闲资源达到最小资源供给大小。
4、框架对slave资源的偏好。通过resource中的role参数来实现，可以通过设定slave的资源的role值和以及将框架按照role进行分组，来实现框架群组的专用资源和资源偏好。
个人认为Mesos分配器的一些缺陷如下：
1、Mesos的resource offer从本质上一种悲观的并发控制，从核心的调度逻辑上我们可以看到，Mesos的每一次调度会一次性地将所有可用的资源都发送给一个框架，在收到框架的响应后，才会返回剩余的资源，继续下一次调度。Mesos的调度性能依赖于框架对resource offer的快速响应。而且mesos没有对resource offer设定一个超时回收机制（个人阅读了0.14版本的mesos代码，没有发现这个机制），如果有一个框架接收了resource offer之后，长时间没有响应，那么整个mesos集群就会发生死锁。
2、Mesos实现fairness是通过对框架按照权重和已分配的dominant share资源进行排序来实现的。Mesos如果要实现dominant resource fairness的性能隔离或者sharing incentive依赖于框架的实现，如果有一个贪婪的框架在一次resource offer中占用了大量资源并长时间不释放，那么其他framework就会处于一种饥饿的状态。Mesos适用于那些使用短任务和拥有可扩展的弹性机制的框架。
3、mesos不支持框架对资源抢占，框架无法获取整个集群的状态。
关于如何进行Mesos资源调度器的实现分析问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。