基于本文回答

播面 播面

文图音视，全方位拆解八股文
0
评论
请从左侧选择一个分类

当 Active ResourceManager 宕机重启后，YARN 如何恢复之前正在运行的作业状态？

知识点图片

在 Hadoop YARN 中，当 Active ResourceManager (RM) 宕机并重启（或发生主备切换）时，恢复之前正在运行的作业状态的核心机制被称为 Work-Preserving RM Restart（保持工作的 RM 重启）。这项特性自 Hadoop 2.4 引入，确保了 RM 的重启对正在运行的应用程序（如 MapReduce、Spark、Flink 作业）是透明的，不会导致正在执行的任务失败。

YARN 恢复作业状态的过程是一个多方协作的过程，主要依赖于 状态存储（State Store）、NodeManager (NM) 的心跳汇报 以及 ApplicationMaster (AM) 的重新同步。

以下是详细的恢复流程和原理解析：

1. 核心基础：状态的持久化 (RMStateStore)

ResourceManager 在正常运行时，不会把所有细粒度的状态（比如每一个 Container 的状态）都存下来，因为那样开销太大。它只会把最核心的元数据持久化到外部存储（通常是 ZooKeeper，也可以是 HDFS 或 LevelDB）中。

持久化的信息包括：

  • Application 的元数据：App ID、提交者信息、队列信息、应用的当前状态（如 SUBMITTED, ACCEPTED, RUNNING）。
  • ApplicationMaster (AM) 的信息：AM 所在的 NodeManager、AM 的 Container ID、安全令牌（Tokens）等。

2. YARN 恢复作业状态的详细步骤

当 Active RM 宕机，新的 RM 启动（或 Standby RM 切换为 Active）时，恢复过程分为以下几个关键阶段：

第一阶段：RM 从状态存储中恢复核心元数据

  1. 新的 Active RM 启动后，首先连接到 ZooKeeper（或 HDFS）。
  2. 读取 RMStateStore 中的数据，将所有 Application 的状态恢复到宕机前的状态。
  3. 对于状态为 RUNNING 的应用，RM 知道了它们在宕机前还在运行，并记录下它们对应的 ApplicationMaster (AM) 的信息。此时，RM 还不清楚具体的 Container 运行情况，它的内存调度器是空的。

第二阶段：NodeManager (NM) 重新同步（恢复 Container 状态）

  1. NM 发现旧的 RM 失去连接后，会不断尝试连接 RM。当新的 Active RM 选举出来后，NM 会向新 RM 发送心跳。
  2. 新 RM 收到 NM 的心跳后，发现这是一个之前注册过的 NM，会要求 NM 进行重新同步（Resync）。
  3. NM 在收到同步指令后，会把自己节点上当前正在运行的所有 Container 的完整列表和状态发送给 RM。
  4. RM 接收到集群中所有 NM 的汇报后，就能在内存中重建整个集群的资源视图，知道哪些 Container 属于哪个 Application，从而恢复调度器的内部状态。
    (注：正因为 NM 保留了 Container，所以在 RM 宕机期间，已经在运行的计算任务完全不受影响，继续执行。)

第三阶段：ApplicationMaster (AM) 重新同步（恢复资源请求状态）

  1. 正在运行的 AM 发现旧 RM 失去响应后，也会不断尝试重连。一旦连接到新的 Active RM，AM 会发送一个注册/同步请求。
  2. 新 RM 会验证这个 AM（通过第一阶段从 ZK 恢复出来的凭证），并允许其重新连接。
  3. 关键点：RM 并没有持久化 AM 之前发送的、尚未被满足的资源请求（Pending Requests）。 因此，在 AM 重新连接后，AM 会把它当前尚未满足的资源请求重新发送给 RM。
  4. RM 将这些请求加入调度器，继续为该应用分配资源。

第四阶段：处理宕机期间的异常（AM 死亡情况）

如果在 RM 宕机期间，某个应用的 AM 也恰好崩溃了怎么办？

  • RM 在恢复后，会等待 AM 的心跳。如果在超时时间内没有收到 AM 的重连请求，RM 会认为该 AM 已经死亡。
  • RM 会按照常规的 AM 容错机制，在集群中寻找新的资源，重新启动一个新的 AM Container（前提是 AM 的最大重试次数未用完）。新的 AM 启动后，会接管之前正在运行的 Task。

3. 总结与架构设计的精妙之处

你可以把 YARN 的恢复机制理解为“骨架 + 血肉”的模式：

  • RMStateStore（ZooKeeper）提供“骨架”：只存轻量级的、核心的应用级别的状态。保证 RM 知道“有哪些应用在跑”。
  • NM 和 AM 的动态汇报提供“血肉”：RM 重启后，利用 NM 和 AM 的心跳汇报，动态重建海量的、变化极快的 Container 状态和资源请求状态。

这种设计极其巧妙，它避免了 RM 在高并发下需要向 ZooKeeper 写入大量 Container 状态带来的性能瓶颈，同时又完美实现了高可用性（HA）。

4. 相关的关键配置（yarn-site.xml）

要使上述机制生效，通常需要确保以下配置已开启（在 Hadoop 2.4+ 及 Hadoop 3.x 中通常是默认配置）：

xml 
<!-- 开启 RM 恢复机制 -->
<property>
  <name>yarn.resourcemanager.recovery.enabled</name>
  <value>true</value>
</property>

<!-- 配置状态存储媒介（通常在 HA 模式下使用 ZooKeeper） -->
<property>
  <name>yarn.resourcemanager.store.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
</property>

<!-- 开启 Work-Preserving RM Restart（核心：重启不杀 Container） -->
<property>
  <name>yarn.resourcemanager.work-preserving-recovery.enabled</name>
  <value>true</value>
</property>
00:00
00:00