NodeManager 宕机或失联对 YARN 集群有什么影响？

知识点图片

在 Hadoop YARN 架构中，NodeManager（NM）是运行在每个计算节点上的代理，负责管理该节点上的资源（CPU、内存）以及启动和监控 Container。

如果某个 NodeManager 宕机或与 ResourceManager（RM）失联，YARN 具有完善的容错机制。总体来说，单个或少量 NodeManager 的宕机不会导致整个 YARN 集群崩溃，但会对正在该节点上运行的任务和集群的总资源产生局部影响。

具体影响可以从以下几个维度进行详细分析：

状态标记变更：ResourceManager 会通过心跳机制（Heartbeat）监控各个 NodeManager 的状态。如果 NM 失联超过一定时间（默认通常是 10 分钟，由参数 yarn.nm.liveness-monitor.expiry-interval-ms 控制），RM 会将其状态标记为 LOST（丢失）。
集群可用资源减少：该节点之前汇报给 RM 的可用资源（vCores 和内存）会从集群总资源池中扣除。集群的整体计算能力下降。
停止新任务分配：RM 不会再将任何新的 Container 调度到该节点上。

任务中断：该节点上所有正在运行的 Container（例如 MapReduce 的 Map/Reduce 任务，或 Spark 的 Executor）将随着 NM 的宕机而立刻中断或丢失。
触发任务重试机制：
- 管理这些任务的 ApplicationMaster (AM) 会发现这些 Container 失败，或者由 RM 通知 AM 这些 Container 所在的节点已丢失。
- AM 会向 RM 重新申请资源，并在集群中其他健康的节点上重新启动这些失败的任务。
- 影响：这会导致相关作业的执行时间变长，因为失败的任务需要从头开始重新计算。

ApplicationMaster 本身也是运行在一个特殊的 Container 中的。如果宕机的 NodeManager 上正好运行着某个作业的 ApplicationMaster，影响会比普通任务大得多：

作业级别失败：该 ApplicationMaster 会随之停止，导致它所管理的整个 Application 暂时失去控制。
RM 触发 AM 重启：ResourceManager 会检测到该 AM 失败。根据配置（yarn.resourcemanager.am.max-attempts，默认通常为 2 次），RM 会在其他健康的节点上重新启动一个新的 ApplicationMaster。
作业恢复情况：
- 不支持 AM 状态恢复的作业：新的 AM 启动后，可能会把整个作业从头开始重新运行（之前已经完成的任务作废）。
- 支持 AM 状态恢复的作业（开启了 AM Keep-Alive 或 Recovery 机制）：新的 AM 可以从 HDFS/ZK 中读取之前的状态，仅重新执行未完成的任务（例如较新版本的 MapReduce 或开启了 Checkpoint 的 Spark/Flink 作业）。

通常 NodeManager 与 HDFS 的 DataNode 是同节点部署的。如果整个物理机宕机，DataNode 也随之失联。
当 YARN 在其他节点上重新拉起失败的任务时，原本可以享受“节点本地化（Node Local）”读取数据的任务，可能被迫降级为“机架本地化（Rack Local）”甚至“跨机架读取（Any）”，这会增加网络 I/O 开销，稍微降低作业的执行效率。

Spark：运行在该节点上的 Executor 会被标记为 Lost。Executor 上缓存的数据（Cache/Persist）会丢失。Spark Driver 会感知到丢失，并把需要用到丢失数据的 Task 重新调度到其他 Executor 上计算。
Flink：运行在该节点上的 TaskManager 会掉线。Flink 的 JobManager 会感知到异常，整个 Flink Job 会触发重启（Restart Strategy），从最近的一次 Checkpoint（检查点）恢复状态并在其他节点上继续运行。
MapReduce：AM 会将该节点上失败的 Map 或 Reduce 任务调度到其他节点重跑。

NodeManager 宕机/失联是一个局部故障。YARN 的设计理念就是为了应对这种分布式环境下的常态故障。

直接结果：该节点上的任务失败、集群总算力减小。
最终结果：YARN 和上层计算框架的容错机制会自动介入，在其他健康节点上重试失败的任务，作业最终依然能够成功执行完毕（前提是集群剩余资源足够重试使用），用户除了感觉到任务执行变慢之外，通常不会受到致命影响。

播面