当前位置: 首页>>Hadoop技术内幕(YARN)>> 阅读正文

Hadoop技术内幕(YARN)第6章问题讨论

Category: Hadoop技术内幕(YARN) View: 2,467 Author: Dong
, ,

  • 评论 (7)
  • 引用通告 (0)
发表评论 发起引用

  • 1楼君影草 回复

    Post: 2014-03-28 18:31

    老师好,第一个问题,如果队列中没有应用程序运行(提交)或者队列中的应用程序资源使用量达不到最最小量限制,是在队列释放container, 进行了3个动作 第一个取消预约状态,第二个应用程序做处理,第三个node做处理释放container;是不是每次都要在队列释放container做判断 是否小于最小量限制?如果是那么小于就该标记这个container是什么状态呢,3个动作是不是第三步不执行?,然后是不是要把这个contaner状态保存到Map中,如果这个队列有新资源请求就从这个Map中拿?

    [回复]

  • 2楼Dong 回复

    Post: 2014-03-29 02:00

    资源不会实现划分给每个队列,而是看成一个大池子,用的话就拿,但是不能超过上限,如果用完了,则放回大池子,同样的作业,下次再取,可能取到一个完全不一样的资源,这取决于哪个节点有空闲资源。你所说的上限或者下限,就是数量上的限制,不会具体到某个资源。

    [回复]

    君影草 回复:

    谢谢老师的回复,老师说的对这是一个大池子是所有队列都能够拿的池子,我想的太局限了,我有点明白了,看了容量调度器的节点更新事件触发的源代码,在把Container分配给叶子队列前做检查,该叶子队列已经使用资源量加上待分配Container资源量,如果二者和大于绝对最大资源量就返回false(这是最大量限制是“hard limit”);我是不是在这个函数中在加上一个判断:当前集群净剩余量headRoom 是否小于 当前集群所配置的所有子队列最小量限制(转化为绝对最小资源量),即保证集群净剩余量一直大于集群所配置的所有子队列最小量限制,就可以实现最小量限制“hard limit”,老师这样想对吗?

    [回复]

  • 3楼君影草 回复

    Post: 2014-03-29 09:23

    补充下:感觉自己上面说的还是不对有资源浪费,老师您看下面的想法对不对:
    在这个函数中在加上一个判断:当前集群净剩余量headRoom 是否小于 Math.min(si);
    对当前集群所配置的每个子队列lqi 计算
    si = lqi配置的最小量 与 lqi已经使用的资源之差

    [回复]

  • 4楼君影草 回复

    Post: 2014-03-29 09:24

    Math.max(si)

    [回复]

  • 5楼君影草 回复

    Post: 2014-04-13 08:47

    您好,第二题不知道按下面思路可不可以实现,先分析失败原因,ApplicationManster运行失败发生在下面三种情况:第一种情况RMAppAttempt处于状态Allocated,当AMLauncher在处理LAUNCH类型事件失败时触发RMAppAttemptLaunchFailedEvent;第二种情况是RMAppAttempt处于状态Allocated,就接收到Container_FINISHED类型事件,RMAppAttemp转为失败状态;第三种是RMAppAttempt处于状态Running, 接收到Container_FINISHED类型事件做判断时发现完成的Container是masterContainer而不是正常的Container,RMAppAttempt转为失败状态。
    针对上面ApplicationMaster失败的三种情况,有一个共同点均会调用BaseFinalTransition触发RMAppFailed事件,当RMApp处理这个事件时,会判断是否再次启动RMAppAttempt(默认最多尝试2次,并转为RMAppState.submitted)。
    不知能否通过下面步骤实现第二题的目的,RMAppAttempt在SUBMITTED状态由于调度器发出的APP_ACCEPTED事件转向SCHEDULED状态时,ScheduleTransition中需要调用调度器的allocate方法请求一个优先级为0(AM_CONTAINER_PRIORITY)资源(Container数量为1),在hadoop2.2源代码中allocate有两个参数一个黑名单,一个移除黑名单;通过变量applicationAttemptId可以得到ApplicationId,再通过rmContext可以得到applicationAttemptId对应的RMApp,从而得到Mapattempts,通过获取的attempts的个数size,可以判断,如果size等于1则以前没有失败attempt,allocate不做任何改变;当size等于2说明有一次失败,则通过RMApp中attempts可以得到前一次失败的attempt,从而得到上次失败的masterContainer,从而获得失败attempt applicationmaster运行的节点nodeId(host,port),此时allocate中的黑名单加入除这个节点外其他节点,即保证在原节点启动ApplicationMaster;如果attempts size等于3 则说明已经在同一个节点失败两次,改变allocate的list参数,则把该节点加入黑名单,把其他节点移除黑名单,这样就能保证第三次applicationmaster是在其他节点请求container运行。
    当RMAttempt有Schedule状态处理CONTAINTER_ALLOCATED事件变为Allocated_saving状态时同样会调用调度器的allocate方法此时是一个空请求但会返回作为ApplciationMaster的1个container,这时修改同样的list参数还原上一步骤处理的黑名单节点。
    不知道上面的思路可不可行,还请博主赐教(发现一个问题,容量调度器有黑名单白名单功能但是公平调度器2.2的源码没有这一步骤处理)。
    利用黑名单和白名单感觉修改小,还有一种想法觉得比较通用,是在调度器中当处理NODE_UPDATE事件时以公平调度器为例如FairSchduler的AppSchedulable中assignContainer方法调用前也是通过AppSchedulable同样可以获得rmContext,以及appAttemptId变量按上面方法同样的逻辑判定此次是否允许该node分配优先级为0(AM_CONTAINER_PRIORITY)的1个container。
    写的有点乱,不知道这思路可行不可行,还望博主有空的时候能够解答。

    [回复]

  • 6楼NigelLee 回复

    Post: 2014-12-04 08:37

    问题1中的最大量限制的实现是在LeafQueue#assignContainers
    if (!assignToQueue(clusterResource, required)) {
    return NULL_ASSIGNMENT;
    }
    不知道最小限制的实现的代码在哪?

    [回复]

  • 7楼Sakura 回复

    Post: 2015-05-27 08:41

    董老师你好,最近在阅读resourcemanager的源码,我想问下,公平调度策略中基于任务数实现的负载均衡那部分源码在哪?谢谢。

    [回复]

目前还没有任何Trackbacks和Pingbacks.
发表评论 点击取消评论