YARN之Opportunistic Containers

Guaranteed Containers

目前yarn的容器调度默认是只有在节点上有未分配的资源时才可以调度containers到节点上，这种容器类型称为guaranteed containers。
它的好处在于只要容器被分配之后可以立即执行。
但是会有两个缺点：

1. Feedback delays：当一个容器运行结束后，NM会通过下一次心跳向RM报告可用的资源，RM获取信息之后会安排调度一个新的容器到该节点上，这个过程需要通过心跳回复给AM，最后AM在该节点上启用一个新的容器。相当于AM启动容器中间会经历两次心跳，中间的延迟会导致一个低的资源利用。

2. Allocated vs. utilized resources.：目前RM分配容器是基于固定的分配值的。经常会出现(容器实际分配了4G，实际只用到了2G)，这同样会造成资源浪费、资源利用率低。

Opportunistic Containers

为了解决上述问题，改善集群的资源利用和提升吞吐，社区有一个新的容器类型opportunistic containers，其特性是：即使该节点没有可用的资源，仍然可以将containers分配到该节点上，容器排队直到获取资源之后立即执行。

1. Can be preempted：该种容器类型优先级低于guaranteed containers，所以opportunistic containers可以被guaranteed containers抢占。这样既可以改善集群的资源利用，也不会影响guaranteed containers的运行。

2. Mix containers：对于一些低优先级的任务不需要严格的执行保障，可以使用opportunistic containers或者两种容器类型混合。

从上面可以看出，Opportunistic Containers目前的实现仅仅解决了Feedback delays问题，Allocated vs. utilized resources 在YARN-1011中正在进行。

容器执行方式的区别

默认AM提交资源请求时，它会指定每个容器的类型(默认是guaranteed)，容器类型决定了容器的分配和运行方式。

当容器到达NM时，会执行本地化(下载所需的资源文件)然后container会转换为Scheduler状态，排队等待执行：

1. 如果有可用的资源，容器会立即执行，此时不考虑容器类型。

2. 如果没有可用的资源：

   • 容器类型为guaranteed，将会kill一些opportunistic类型的容器来确保guaranteed容器的执行

   • 容器类型为opportunistic，在队列中排队等待资源

3. 当有可用资源时，队列中的opportunistic容器按照FIFO顺序执行。

Opportunistic containers的分配方式

Opportunistic containers默认的容器分配还是通过RM，用户可以选择启用分布式分配(opportunistic containers)，可以进一步提高短任务的分配延迟。

• Centralized Allocation：集中式分配，通过RM，这种方式可以提供更高质量的放置决策并且实现更多涉及到跨应用程序的共享策略。在集中式的分配中，有一个新的服务 OpportunisticContainerAllocatorAMService，它继承自ApplicationMasterService，此时资源请求会有两种：

  • guaranteed：仍然被转发到ApplicationMasterService，随后被容器调度器处理

  • opportunistic：直接被OpportunisticContainerAllocatorAMService处理，它自身会维护一个least loaded nodes列表，轮询分配容器到节点上。

• Distributed Allocation：避免RM-NM之间的来回交互，会提供更快的分配。当启用分布式调度时，每个AM会将其资源请求直接发送到运行在同一节点的AMRMProxyService。

  • guaranteed：此时AMRMProxyService仅仅在AM与RM之间充当一个代理，实际请求还是会转发给RM

  • opportunistic：直接被运行在节点上的拦截器DistributedScheduler处理，它会维护一个least loaded nodes列表并轮询分配。

least loaded nodes

NM会周期性通过心跳向RM报告信息：运行的guaranteed容器的数量、运行的opportunistic容器的数量、排队的opportunistic容器数量。目前RM只考虑了每个节点上排队的opportunistic容器的数量，通过计算估计一个opportunistic容器被发送到该节点需要等待的时间，从而确定least loaded nodes。

• Centralized的方式中，这个列表会立即获取到，因为本身就通过RM分配。

• Distributed的方法中，RM会通过心跳回复将信息传给NMs。

Opportunistic Containers 配置

# 启用opportunistic containers特性
yarn.resourcemanager.opportunistic-container-allocation.enabled=true

# 每个节点上队列的长度。最佳值取决于很多方面，推荐先设置为10
yarn.nodemanager.opportunistic-containers-max-queue-length=10 

# 启用分布式调度
yarn.nodemanager.distributed-scheduling.enabled true 

UI指标

• Running Containers (O): 每个节点上运行的opportunistic containers数量

• Mem Used (O): 每个节点上opportunistic containers所使用的总内存

• VCores Used (O): 每个节点上opportunistic containers所使用的vcores

• Queued Containers: 每个节点上排队的container数量