YARN 的高可用设计有哪些？

前言

本文隶属于专栏《大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见大数据技术体系

---

正文

YARN 提供了恢复机制，这使得 YARN 在服务出现故障或人工重启时，不会对正在运行的应用程序产生任何影响。

本文将从 ResourceManager HA、 ResourceManager Recovery 和 NodeManager Recovery 三个方面讨论 YARN 高可用方面的设计。

---

ResourceManager HA

ResourceManager 负责集群中资源的调度和应用程序的管理，是 YARN 最核心的组件。

由于 YARN 采用了 master/slave 架构，这使得 ResourceManager 成为单点故障。

为了避免 ResourceManager 故障导致整个集群不可用，YARN 引人了 Active/Standby ResourceManager， 通过冗余方式解决 ResourceManager 单点故障。

当 Active ResourceManager 出现故障时， Standby ResourceManager 可通过 ZooKeeper 选举成为 Active ResourceManager，并通过 ResourceManager Recovery 机制恢复状态。

---

ResourceManager Recovery

ResourceManager 内置了重启恢复功能，当 ResourceManager 就地重启，或发生 Active Standby 切换时，不会影响正在运行的应用程序运行。

ResourceManager Recovery 主要流程如下：

1. 保存元信息：Active ResourceManager 运行过程中，会将应用程序的元信息，状态信息以及安全凭证等数据持久化到状态存储系统（state–store）中，YARN支持三种可选的state-store，分别是：

• 基于 ZooKeeper 的 state-store：ZooKeeper 是 ResourceManager HA 必选的 state-store，尽管 Resource Restart 可选择其他 state-store，但只有 ZooKeeper 能防止脑裂（split- brain）现象，即同时存在多个 Active ResourceManager 状态信息的情况。
• 基于 FileSystem 的 state-store：支持 HDFS 和本地文件系统两种方式，但不能防止脑裂。
• 基于 LevelDB 的 state-store：基于 LevelDB 的 state-store 比前两种方案更加轻量级。LevelDB 能更好地支持原子操作，每次更新占用更少的 IO 资源，生成的文件数目更少。

---

2. 加载元信息：一旦 Active ResourceManager 重启或出现故障，新启动的 Resource Manager 将从存储系统中重新加载应用程序的相关数据，在此过程中，所有运行在各个 NodeManager 的 Container 仍正常运行。

---

3. 重构状态信息：新的 ResourceManager 重启完成后，各个 NodeManager 会向它重新注册，并将所管理的 Container 汇报给 ResourceManager，这样 ResourceManager 可动态重构资源分配信息、各个应用程序以及其对应 Container 等关键数据；同时， ApplicationMaster 会向 ResourceManager 重新发送资源请求，以便 ResourceManager 重新为其分配资源。

---

NodeManager Recovery

NodeManager 内置了重启恢复功能，当 NodeManager 就地重启时，之前正在运行的 Container 不会被杀掉，而是由新的 NodeManager 接管，并继续正常运行。

---

以上几种高可用机制的实现，使得 YARN 成为一个通用的资源管理系统，这使得在个集群中混合部署短作业和长服务变得可能。