前言
我们知道，Hadoop YARN的基础架构由ResourceManager实例和NodeManager实例组成。用户提交到YARN集群的作业会抽象成ApplicationMaster和Container的形式，并由NodeManager持有和管理，如下图所示。
问题来了：如果YARN集群整体重启，是不是就意味着所有作业都被强行停止，需要用户手动恢复呢？当然不是，通过适当的配置，就可以让RM和NM的重启不影响正在运行的作业。以下简述配置方法。
配置ResourceManager重启自动恢复
-
将yarn-site.xml中的
yarn.resourcemanager.recovery.enabled配置项设为true（默认是false）。 -
配置
yarn.resourcemanager.store.class参数，该参数用来指定RM在重启之前将自己的状态保存在何种存储媒介上，目前有3种存储可选。
-
org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore
默认值，是基于文件系统的存储（本地存储或者HDFS）。可以指定yarn.resourcemanager.fs.state-store.uri作为存储路径。 -
org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
基于ZooKeeper的存储，当启用RM高可用时，只能选择这种方式。因为两个RM都有可能是活跃的（认为自己才是真正的RM），进而发生脑裂。基于ZK的存储可以通过隔离（fence）状态数据防止脑裂。可以指定hadoop.zk.address（ZK节点地址列表）和yarn.resourcemanager.zk-state-store.parent-path（状态数据的根节点路径）参数。 -
org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore
基于LevelDB的存储。它比前两种方式都更轻量级，占用的存储空间和I/O要小得多，并且支持更好的原子性操作。对性能有极致要求时采用。可以指定yarn.resourcemanager.leveldb-state-store.path作为存储路径。
- 最后配置
yarn.resourcemanager.work-preserving-recovery.scheduling-wait-ms，它表示从RM重启后从各个NM同步Container信息的等待时长，在此之后才会分配新的Container。默认值是10000（10秒），一般不需要改动。
Done.
配置NodeManager重启自动恢复
-
将yarn-site.xml中的
yarn.nodemanager.recovery.enabled配置项设为true（默认是false）。 -
配置
yarn.nodemanager.recovery.dir参数，指定NM在重启之前，将Container的状态写入此本地路径。默认值为${hadoop.tmp.dir}/yarn-nm-recovery。 -
配置
yarn.nodemanager.address参数，该参数为NM的RPC地址，默认为${yarn.nodemanager.hostname}:0，即随机使用临时端口。一定要指定为一个固定端口（如8041），否则NM重启之后会更换端口，就无法恢复Container的状态了。
Done.
The End
上面提到的脑裂是个有意思的话题，等过几天有时间了详细说说吧。
民那晚安晚安。
网友评论