Health Monitor

NameNode 高可用整体架构概述 在 Hadoop 1.0 时代，Hadoop 的两大核心组件 HDFS NameNode 和 JobTracker 都存在着单点问题，这其中以 NameNode 的单点问题尤为严重。因为 NameNode 保存了整个 HDFS 的元数据信息，一旦 NameNode 挂掉，整个 HDFS 就无法访问，同时 Hadoop 生态系统中依赖于 HDFS 的各个组件，包括 MapReduce、Hive、Pig 以及 HBase 等也都无法正常工作，并且重新启动 NameNode 和进行数据恢复的过程也会比较耗时。这些问题在给 Hadoop 的使用者带来困扰的同时，也极大地限制了 Hadoop 的使用场景，使得 Hadoop 在很长的时间内仅能用作离线存储和离线计算，无法应用到对可用性和数据一致性要求很高的在线应用场景中。 所幸的是，在 Hadoop2.0 中，HDFS NameNode 和 YARN ResourceManger(JobTracker 在 2.0 中已经被整合到 YARN ResourceManger 之中) 的单点问题都得到了解决，经过多个版本的迭代和发展，目前已经能用于生产环境。HDFS NameNode 和 YARN ResourceManger 的高可用 (High Availability，HA) 方案基本类似

转自https://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-name-node/ 前面的两篇文章都是关于分布式一致性协议Raft的， 图解分布式一致性算法 Raft协议详解 ，其中提到了选主等内容。在不同的项目中，也都有类似的主从切换等策略来保证HA。下文是Hadoop中的NameNode的高可用实现分析，可以对照着看看。 如果在公众号内格式排版不便阅读，可以查看链接。 NameNode 高可用整体架构概述 在 Hadoop 1.0 时代，Hadoop 的两大核心组件 HDFS NameNode 和 JobTracker 都存在着单点问题，这其中以 NameNode 的单点问题尤为严重。因为 NameNode 保存了整个 HDFS 的元数据信息，一旦 NameNode 挂掉，整个 HDFS 就无法访问，同时 Hadoop 生态系统中依赖于 HDFS 的各个组件，包括 MapReduce、Hive、Pig 以及 HBase 等也都无法正常工作，并且重新启动 NameNode 和进行数据恢复的过程也会比较耗时。这些问题在给 Hadoop 的使用者带来困扰的同时，也极大地限制了 Hadoop 的使用场景，使得 Hadoop 在很长的时间内仅能用作离线存储和离线计算，无法应用到对可用性和数据一致性要求很高的在线应用场景中。

一、What 一个 主从架构 的分布式框架 给分布式框架提供协调服务（service） 作用 提供简版文件系统来存储数据 维护和 监控 存储的数据 状态变化 ，通过监控数据状态变化达到基于数据的集群管理 主要用来解决分布式集群中应用系统的 一致性 问题 应用场景 1. 主备切换 2. 节点的上下线感知 3. 统一命名服务 4. 状态同步服务 5. 集群管理 6. 分布式应用配置管理 二、基本概念 ZooKeeper=简版文件系统(Znode)+原语+通知机制(Watcher) ZK文件系统 基于类似于文件系统的 目录节点树 方式的数据存储 原语 提供类linux指令进行操作 Watcher（监听器） 数据节点ZNode 数据节点本质就是目录 持久节点 临时节点 非有序节点 create create -e 有序节点 create -s create -s -e 持久节点（无序） 节点创建以后，即便连接断开，除非主动删除，不然会一直存在 持久节点（有序） 创建节点的时候加上 -s ，会默认的在目录后加上数字 防止同一目录创建同名ZNode导致失败 临时节点（无序） 节点创建以后，一旦连接断开会自动删除 创建节点的时候通过 -t 指定 持久节点（有序） 同上 会话 与zk交互时会建立TCP长连接，称为会话 建立会话后，如果超过SessionTimeout时间，两者间没有通信，会话超时

NameNode HA 架构图 核心组件 NameNode 主备切换主要由 ZKFailoverController、HealthMonitor 和 ActiveStandbyElector 这 3 个组件来协同实现： ZKFailoverController 作为 NameNode 机器上一个独立的进程启动 (在 hdfs 启动脚本之中的进程名为 zkfc)，启动的时候会创建 HealthMonitor 和 ActiveStandbyElector 这两个主要的内部组件，ZKFailoverController 在创建 HealthMonitor 和 ActiveStandbyElector 的同时，也会向 HealthMonitor 和 ActiveStandbyElector 注册相应的回调方法。 HealthMonitor 主要负责检测 NameNode 的健康状态，如果检测到 NameNode 的状态发生变化，会回调 ZKFailoverController 的相应方法进行自动的 主备选举 。（zk 的选举过程） ActiveStandbyElector 主要负责完成自动的主备选举，内部封装了 Zookeeper 的处理逻辑，一旦 Zookeeper 主备选举完成，会回调 ZKFailoverController 的相应方法来进行 NameNode 的主备状态切换。 基于

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在安装12C GI的过程中，会要求安装 GIMR 的数据库MGMTDB，当然你可能会选NO。在12.1.01版本时是可以选择GIMR不安装，但是在12.1.0.2和12.2 版本中GIMR成了强制安装，即使在这里选择了NO，这里的YES和NO的区别只是把MTMTDB是存放在OCR ASM DISKGROU还是独立的创建ASM DISKGROUP. 12C r1是GIMR的位置是有OCR的路径决定的。 MGMTDB只是1个CDB包含1个PDB的完整的数据库环境，通常不需要人维护，存储的是GIMR的信息，用于存放 cluster health monitor 生成的一些操作系统级的负载指标，存储着历史信息用于分析性能和诊断问题，是全集成在EM 12C 中。 GIMR 存放的信息更多查看 the documentation here，而对于 cluster health monitor 是可以手动停止，使用下面的命令： $ crsctl stop res ora.crf -init $ crsctl delete res ora.crf -init 我们可以在安装gi的时候增加命令行 -J-D oracle .install.mgmtDB= false 来跳过MGMTDB的安装。 来源： oschina 链接：