码迷,mamicode.com
首页 > 移动开发 > 详细

Yarn系列(二)——ApplicationMater启动过程分析

时间:2020-10-29 10:47:18      阅读:34      评论:0      收藏:0      [点我收藏+]

标签:生成   nta   tst   failed   pad   并且   erro   token   导致   

1. 前言

为了更好分析ApplicationMater启动过程,本篇博客在前言部分将简要介绍一下yarn中重要的两个基础库:服务库和事件库,然后在此基础上,着重分析ApplicationMater的启动过程。
本文基于Yarn 3.2版本,文章较长,谨慎阅读,若是文中有误欢迎留言指出。

1.1. 服务库

对于生命周期较长的对象,Yarn采用了基于服务的对象管理模型,该模型主要有以下特点:

  • 每个被服务化的对象分为4个状态;

notinited(被创建)、inited(已初始化)、started(已启动)、stoped(已停止)

  • 任何服务的变化都可以触发另一些动作;
  • 可以通过组合的方式对任意服务进行组合,以便统一管理;
    所有的服务对象均实现了Service接口(org.apache.hadoop.service),其定义了最基本的服务初始化、启动、停止等操作。

1.2. 事件库

Yarn采用了基于事件驱动的并发模型,为了构建该模型,Yarn将各种处理逻辑抽象成事件和对应事件调度器,并将每类事件的处理过程分割成多个步骤,用有限状态机表示。
整体过程大致:处理请求进入系统,由中央异步调度器(AsyncDispatcher)负责传递给相应的事件处理器(Event handler),该事件处理器可能将该事件转发给另一个事件处理器,也可能将其交给一个带有有限状态的事件处理器,其处理结果也可以以事件的形式传递给中央异步调度器,,而新的事件再次被中央异步调度器转发给下一个事件调度器,直至处理完成。
事件均实现了接口Event(org.apache.hadoop.yarn.event),该接口给出了获取事件类型的接口。

在Yarn中,所有核心服务实际上都是一个中央异步调度器,包括:ResourceManager、NodeManager、ApplicationMater等,它们维护了事先注册事件与事件处理器,并根据接收事件类型驱动服务运行。

1. 用户提交应用过程

用户提交应用程序,会调用客户端的ApplicationClientProtoc#submitApplication,进而会调用服务端RMAppManager#submitApplication,此后服务端直到ApplicationMater启动,会涉及ClientRMService、RMAppManager、RMAppImpl、RMAppAttempImpl、RMNode、ResourceScheduler。
为了简化整个分析过程,这里仅分析首次提交任务的过程中任务提交到ApplicationMater启动过程,不考虑失败重启的过程。整个过程将围绕着状态机展开。

2. ApplicationMater启动源码分析

2.1 RMAppImpl状态机

2.1.1 创建RMApp

ClientRMService收到客户端的请求后,会调用RMAppManager#submitApplication方法,在该方法中创建了一个RMApp对象来维护这个应用程序的整个生命周期。
该对象的实现类是RMAppImpl类,该类维护了一个Application状态机,记录一个Application可能存在的状态(RMAppState)以及导致状态间转换的事件(RMAppEvent),核心代码如下:

//创建RMApp对象
RMAppImpl application = createAndPopulateNewRMApp(
     submissionContext, submitTime, user, false, -1);
 ....
 //这里考虑加密方式Simple的情况
 this.rmContext.getDispatcher().getEventHandler()
         .handle(new RMAppEvent(applicationId, RMAppEventType.START));  

在这里会将RMAppEvent事件放入中央调度器(BlockingQueue)中等待对应的事件处理器(RMAppImpl)处理。

2.1.2 状态从NEW转变为NEW_SAVING

当RMAppImpl处理器处理时,会调用RMAppImpl#handle()方法,该方法主要是调用状态机的doTransition()方法,跟进去会发现,该方法主要是调用状态机的hook对象的transition()方法。
对于初次提交的任务,从状态机的初始化过程(如下),可以发现,是调用RMAppImpl内部类的RMAppNewlySavingTransition的transition()方法。

......
.addTransition(RMAppState.NEW, RMAppState.NEW_SAVING,
     RMAppEventType.START, new RMAppNewlySavingTransition())

RMAppImpl#RMAppNewlySavingTransition#transition()方法会调用RMStateStore#storeNewApplication()。RMStateStore是插拔式组件,在不启用RM恢复机制,默认是NullRMStateStore,它不会进行任何保存工作(其他实现有MemoryRMStateStore等)。自此,RMAppState就从NEW变为了NEW_SAVING。

2.1.3 状态变化过程STORE_APP->...-> SUBMITTE

RMStateStore#storeNewApplication()会new一个RMStateStoreEventType.STORE_APP放入到调度器中。RMAppState实现类会调用StoreAppTransition(),该方法主要是保存状态,并进一步向RMAppImpl发送一个RMAppEventType.APP_NEW_SAVED事件。
RMAppImpl接收到RMAppEventType.APP_NEW_SAVED事件后,RMAppImpl的状态就从RMAppState.SUBMITTED.NEW_SAVING变为RMAppState.SUBMITTED,与此同时,会生成一个AppAddedSchedulerEvent事件放入调度器的对列中等待资源调度器处理。

2.2 RM资源调度器

资源调度器是ResourceManager的一个插拔式服务组件,负责整个集群资源的管理和分配。Yarn的资源调度有三种:FIFO(First In First Out)、Capacity Scheduler、Fair Scheduler,本文以YaHoo的Capacity Scheduler为例进行分析,该资源调度器也是目前社区推荐的使用方式。

CapacityScheduler在处理SchedulerEvent事件时,是调用其handle()方法,此时涉及的分支如下。


 case APP_ADDED:
  {
    AppAddedSchedulerEvent appAddedEvent = (AppAddedSchedulerEvent) event;
    String queueName = resolveReservationQueueName(appAddedEvent.getQueue(),
        appAddedEvent.getApplicationId(), appAddedEvent.getReservationID(),
        appAddedEvent.getIsAppRecovering());
    if (queueName != null) {
      if (!appAddedEvent.getIsAppRecovering()) {
          //初次运行
        addApplication(appAddedEvent.getApplicationId(), queueName,
            appAddedEvent.getUser(), appAddedEvent.getApplicatonPriority(),
            appAddedEvent.getPlacementContext());
      } else {
        addApplicationOnRecovery(appAddedEvent.getApplicationId(), queueName,
            appAddedEvent.getUser(), appAddedEvent.getApplicatonPriority(),
            appAddedEvent.getPlacementContext());
      }
    }
  }
  break;

当任务是初次运行是,主要是调用CapacityScheduler#addApplication()方法。在该方法中我们过滤掉非正常情况,其核心代码如下:

  // Submit to the queue
    try {
      //numApplications加1,
      queue.submitApplication(applicationId, user, queueName);
    } catch (AccessControlException ace) {
      LOG.info("Failed to submit application " + applicationId + " to queue "
          + queueName + " from user " + user, ace);
      this.rmContext.getDispatcher().getEventHandler().handle(
          new RMAppEvent(applicationId, RMAppEventType.APP_REJECTED,
              ace.toString()));
      return;
    }
    // update the metrics
    queue.getMetrics().submitApp(user);
    SchedulerApplication<FiCaSchedulerApp> application =
        new SchedulerApplication<FiCaSchedulerApp>(queue, user, priority);
    applications.put(applicationId, application);
    LOG.info("Accepted application " + applicationId + " from user: " + user
        + ", in queue: " + queueName);
        //新的事件放入调度器中
    rmContext.getDispatcher().getEventHandler().handle(
        new RMAppEvent(applicationId, RMAppEventType.APP_ACCEPTED));

2.3. RMAppImpl到RMAppAttemptImpl

当RMAppImpl事件处理器处理RMAppEventType.APP_ACCEPTED事件时,RMAppImpl的状态会从RMAppState.SUBMITTED变为RMAppState.ACCEPTED,并且调用RMAppImpl#StartAppAttemptTransition#transition()方法,该方法主要是调用RMAppImpl的私有方法createAndStartNewAttempt()。

private void
    createAndStartNewAttempt(boolean transferStateFromPreviousAttempt) {
      //创建一个RMAppAttemptImpl实例,尝试次数为1
  createNewAttempt();
  //RMAppStartAttemptEvent事件放入调度器
  handler.handle(new RMAppStartAttemptEvent(currentAttempt.getAppAttemptId(),
    transferStateFromPreviousAttempt));
}

2.4. RMAppAttemptImpl调度器

2.4.1 RMAppAttemptImpl状态从NEW到SUBMITTED

RMAppAttemptEvent事件的Event handler的实现类是RMAppAttemptImpl,当其接收到RMAppAttemptEventType.START事件时,它的状态就会从RMAppAttemptState.NEW变为RMAppAttemptState.SUBMITTED,并调用RMAppAttemptImpl#AttemptStartedTransition#transition()方法。

public void transition(RMAppAttemptImpl appAttempt,
      RMAppAttemptEvent event) {

      boolean transferStateFromPreviousAttempt = false;
    if (event instanceof RMAppStartAttemptEvent) {
      transferStateFromPreviousAttempt =
          ((RMAppStartAttemptEvent) event)
            .getTransferStateFromPreviousAttempt();
    }
    appAttempt.startTime = System.currentTimeMillis();

    // Register with the ApplicationMasterService
    //向ApplicationMasterService注册
    appAttempt.masterService
        .registerAppAttempt(appAttempt.applicationAttemptId);

    if (UserGroupInformation.isSecurityEnabled()) {
      appAttempt.clientTokenMasterKey =
          appAttempt.rmContext.getClientToAMTokenSecretManager()
            .createMasterKey(appAttempt.applicationAttemptId);
    }

    // Add the applicationAttempt to the scheduler and inform the scheduler
    // whether to transfer the state from previous attempt. 
    //向资源调度器中添加SchedulerEventType.APP_ATTEMPT_ADDED事件
    appAttempt.eventHandler.handle(new AppAttemptAddedSchedulerEvent(
      appAttempt.applicationAttemptId, transferStateFromPreviousAttempt));
  }

2.4.2 CapacityScheduler调度器调度

与上面分析过程相同,其涉及的分支如下。

 case APP_ATTEMPT_ADDED:
  {
    AppAttemptAddedSchedulerEvent appAttemptAddedEvent =
        (AppAttemptAddedSchedulerEvent) event;
    addApplicationAttempt(appAttemptAddedEvent.getApplicationAttemptId(),
      appAttemptAddedEvent.getTransferStateFromPreviousAttempt(),
      appAttemptAddedEvent.getIsAttemptRecovering());
  }
  break;

在CapacityScheduler#addApplicationAttempt()方法中,其向调度器添加了RMAppAttemptEventType.ATTEMPT_ADDED事件。

2.4.3 RMAppAttemptImpl调度器ATTEMPT_ADDED到SUBMITTED

RMAppAttemptImpl调度器处理器处理RMAppAttemptEventType.ATTEMPT_ADDED事件时,会将其状态从RMAppAttemptState.SUBMITTED变为RMAppAttemptState.SCHEDULED(特殊情况下,ApplicationMater由用户而非ResourceManager启动,则状态为RMAppAttemptState.LAUNCHED_UNMANAGED_SAVING)。同时会触发对RMAppAttemptImpl#ScheduleTransition#transition()的调用。

public RMAppAttemptState transition(RMAppAttemptImpl appAttempt,
      RMAppAttemptEvent event) {
    ApplicationSubmissionContext subCtx = appAttempt.submissionContext;  
    //ApplicationMater由ResourceManager启动
    if (!subCtx.getUnmanagedAM()) {
      //处理AM的黑名单、资源对列信息等
      .......

      // AM resource has been checked when submission
      //为ApplicationMater分配资源
      Allocation amContainerAllocation =
          appAttempt.scheduler.allocate(
              appAttempt.applicationAttemptId,
              appAttempt.amReqs, null, EMPTY_CONTAINER_RELEASE_LIST,
              amBlacklist.getBlacklistAdditions(),
              amBlacklist.getBlacklistRemovals(),
              new ContainerUpdates());
      if (amContainerAllocation != null
          && amContainerAllocation.getContainers() != null) {
        assert (amContainerAllocation.getContainers().size() == 0);
      }
      //最终状态为多个时,此处指定返回状态为SCHEDULED
      return RMAppAttemptState.SCHEDULED;
    } else {
      // save state and then go to LAUNCHED state
      appAttempt.storeAttempt();
      return RMAppAttemptState.LAUNCHED_UNMANAGED_SAVING;
    }
  }

2.4.4 CapacityScheduler调度器获取分配给AM的资源

allocate()方法有多个实现,这里查看CapacityScheduler中的实现。

 public Allocation allocate(ApplicationAttemptId applicationAttemptId,
    List<ResourceRequest> ask, List<SchedulingRequest> schedulingRequests,
    List<ContainerId> release, List<String> blacklistAdditions,
    List<String> blacklistRemovals, ContainerUpdates updateRequests) {
  FiCaSchedulerApp application = getApplicationAttempt(applicationAttemptId);
  if (application == null) {
    LOG.error("Calling allocate on removed or non existent application " +
        applicationAttemptId.getApplicationId());
    return EMPTY_ALLOCATION;
  }

  ......
  // Handle all container updates
  handleContainerUpdates(application, updateRequests);

  // Release containers
  releaseContainers(release, application);

  LeafQueue updateDemandForQueue = null;

  // Sanity check for new allocation requests
  normalizeResourceRequests(ask);

  // Normalize scheduling requests
  normalizeSchedulingRequests(schedulingRequests);

  Allocation allocation;

  // make sure we aren‘t stopping/removing the application
  // when the allocate comes in
  try {
    application.getWriteLock().lock();
    if (application.isStopped()) {
      return EMPTY_ALLOCATION;
    }

   ......

    application.updateBlacklist(blacklistAdditions, blacklistRemovals);
    //指定资源,getAllocation()中有AM资源的指定方式
    allocation = application.getAllocation(getResourceCalculator(),
        getClusterResource(), getMinimumResourceCapability());
  } finally {
    application.getWriteLock().unlock();
  }
  ......
  return allocation;
}

getAllocation()方法是FiCaSchedulerApp类中的方法,在该方法中给出获取资源的信息,值得注意的时候,在该过程中会更新container的信息。

2.5. RMContainerImpl状态机

ResourceManager为应用程序的ApplicationMater分配资源后,创建一个RMContainerImpl并向它发送Start事件。

2.5.1 状态从NEW -> ALLOCATED

...
.addTransition(RMContainerState.NEW, RMContainerState.ALLOCATED,
  RMContainerEventType.START, new ContainerStartedTransition())

在RMContainerImpl接收START后,会调用内部类ContainerStartedTransition的方法transition().

private static final class ContainerStartedTransition extends
    BaseTransition {

  @Override
  public void transition(RMContainerImpl container, RMContainerEvent event) {
    // Notify AllocationTagsManager
    container.rmContext.getAllocationTagsManager().addContainer(
        container.getNodeId(), container.getContainerId(),
        container.getAllocationTags());

    container.eventHandler.handle(
        new RMAppAttemptEvent(container.appAttemptId,
            RMAppAttemptEventType.CONTAINER_ALLOCATED));

    publishNonAMContainerEventstoATS(container);

  }
}

2.5.2 RMAppAttemptImpl状态

在获取容器后,RMContainerImpl会将RMAppAttemptEventType.CONTAINER_ALLOCATED事件放入到调度器中,RMContainerImpl收到CONTAINER_ALLOCATED事件后,会触发状态机的变化如下:

// Transitions from SCHEDULED State
.addTransition(RMAppAttemptState.SCHEDULED,
    EnumSet.of(RMAppAttemptState.ALLOCATED_SAVING,
      RMAppAttemptState.SCHEDULED),
    RMAppAttemptEventType.CONTAINER_ALLOCATED,
    new AMContainerAllocatedTransition())

在AMContainerAllocatedTransition#transition方法中,会设置AMContainer,并将其标记为已使用。在返回之前会调用appAttempt.storeAttempt(),该过程会向RMStateStore发送RMStateStoreEventType.STORE_APP_ATTEMPT(放入资源调度器中)请求记录日志。至此,RMContainerImpl的状态从SCHEDULED变为了RMAppAttemptState.ALLOCATED_SAVING。

2.5.3 RMStateStore

RMStateStore接收到RMStateStoreEventType.STORE_APP_ATTEMPT事件后,会触发其状态机的变化。其主要是记录日志并向RMAppAttemptImpl发送请求,ATTEMPT_NEW_SAVED其核心代码如下:

store.storeApplicationAttemptStateInternal(attemptState.getAttemptId(),
          attemptState);
  store.notifyApplicationAttempt(new RMAppAttemptEvent
         (attemptState.getAttemptId(),
         RMAppAttemptEventType.ATTEMPT_NEW_SAVED));

2.6 launcher过程

2.6.1 launchAttempt()方法

RMAppAttemptImpl在接收到事件后,其状态机变化如下:

 // Transitions from ALLOCATED_SAVING State
    .addTransition(RMAppAttemptState.ALLOCATED_SAVING, 
        RMAppAttemptState.ALLOCATED,
        RMAppAttemptEventType.ATTEMPT_NEW_SAVED, new AttemptStoredTransition())

其会调用如下代码:

 private static final class AttemptStoredTransition extends BaseTransition {
  @Override
  public void transition(RMAppAttemptImpl appAttempt,
                                                  RMAppAttemptEvent event) {

    appAttempt.registerClientToken();
    //登录AMMaster请求,具体细节如下
    appAttempt.launchAttempt();
  }
}
........
  private void launchAttempt(){
  launchAMStartTime = System.currentTimeMillis();
  // Send event to launch the AM Container
  //将AMLauncherEventType.LAUNCH事件放入事件对列中
  eventHandler.handle(new AMLauncherEvent(AMLauncherEventType.LAUNCH, this));
}

2.6.2 ApplicationMasterLauncher调用登录

AMLauncherEventType.LAUNCH事件放入事件对列中后,等待ApplicationMasterLauncher的线程池中线程调用。其处理方法为:

@Override
public synchronized void  handle(AMLauncherEvent appEvent) {
  AMLauncherEventType event = appEvent.getType();
  RMAppAttempt application = appEvent.getAppAttempt();
  switch (event) {
  case LAUNCH:
  //登录
    launch(application);
    break;
  case CLEANUP:
    cleanup(application);
    break;
  default:
    break;
  }
}

....
private void launch(RMAppAttempt application) {
  Runnable launcher = createRunnableLauncher(application, 
      AMLauncherEventType.LAUNCH);
  //添加到
  masterEvents.add(launcher);
}

其中,launcher线程主要的显示逻辑:

public void run() {
  switch (eventType) {
  case LAUNCH:
    try {
      LOG.info("Launching master" + application.getAppAttemptId());
      //与对应的NodeManager进行沟通启动containers
      launch();
      //向RMAppAttempImp发送RMAppAttemptEventType.LAUNCHED事件
      handler.handle(new RMAppAttemptEvent(application.getAppAttemptId(),
          RMAppAttemptEventType.LAUNCHED, System.currentTimeMillis()));
    } catch(Exception ie) {
      onAMLaunchFailed(masterContainer.getId(), ie);
    }
    break;
  case CLEANUP:
    try {
      LOG.info("Cleaning master " + application.getAppAttemptId());
      cleanup();
    } catch(IOException ie) {
      LOG.info("Error cleaning master ", ie);
    } catch (YarnException e) {
      StringBuilder sb = new StringBuilder("Container ");
      sb.append(masterContainer.getId().toString());
      sb.append(" is not handled by this NodeManager");
      if (!e.getMessage().contains(sb.toString())) {
        // Ignoring if container is already killed by Node Manager.
        LOG.info("Error cleaning master ", e);
      }
    }
    break;
  default:
    LOG.warn("Received unknown event-type " + eventType + ". Ignoring.");
    break;
  }
}

RMAppAttempImp收到RMAppAttemptEventType.LAUNCHED事件后,会触发向RMAppImpl发送RMAppEventType.ATTEMPT_LAUNCHED事件,此时,RMAppAttempImp的状态从RMAppAttemptState.ALLOCATED变为RMAppAttemptState.LAUNCHED。

private static class AMLaunchedTransition extends BaseTransition {
  @Override
  public void transition(RMAppAttemptImpl appAttempt,
                          RMAppAttemptEvent event) {
    if (event.getType() == RMAppAttemptEventType.LAUNCHED
        || event.getType() == RMAppAttemptEventType.REGISTERED) {
      appAttempt.launchAMEndTime = System.currentTimeMillis();
      long delay = appAttempt.launchAMEndTime -
          appAttempt.launchAMStartTime;
      ClusterMetrics.getMetrics().addAMLaunchDelay(delay);
    }
    //RMAppIml会记录日志并保存launcher事件
    appAttempt.eventHandler.handle(
        new RMAppEvent(appAttempt.getAppAttemptId().getApplicationId(),
          RMAppEventType.ATTEMPT_LAUNCHED, event.getTimestamp()));
    appAttempt
        .updateAMLaunchDiagnostics(AMState.LAUNCHED.getDiagnosticMessage());
    // Register with AMLivelinessMonitor
    //注册以便监控状态
    appAttempt.attemptLaunched();

  }
}

2.6.3 ApplicationMater启动成功后

NodeManager通过心跳机制上报ApplicationMater所在container成功启动,启动的ApplicationMater会通过ApplicationMasterServiceProcessor#registerApplicationMaster()方法向ResourceManager注册,核心代码如下:

getRmContext().getDispatcher().getEventHandler()
      .handle(
          new RMAppAttemptRegistrationEvent(applicationAttemptId, request
              .getHost(), request.getRpcPort(), request.getTrackingUrl()));

上述过程向RMAppAttemptImp发送事件RMAppAttemptEventType.REGISTERED,RMAppAttemptImp接收到事件后,状态从RMAppAttemptState.LAUNCHED转为RMAppAttemptState.RUNNING。此时会向RMAppImpl发送RMAppEventType.ATTEMPT_REGISTERED事件,使其状态从RMAppState.ACCEPTED变为RMAppState.RUNNING

3. Ref

《Hadoop内幕:深入理解yarn架构设计与原理实现》

Yarn系列(二)——ApplicationMater启动过程分析

标签:生成   nta   tst   failed   pad   并且   erro   token   导致   

原文地址:https://www.cnblogs.com/love-yh/p/13894421.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!