关于hadoop:Namenode-高可用整体架构概述

一般版 2.x 组成及基本功能

相较于一般版本高可用架构作出以下调整

• 去掉了 secondaryNamenode，并减少了一个新的 namenode 与状态 (active 和 standby)
• 减少了 zookeeper 与主备切换控制器 failoverController( 下文均称为 zkfc) 和衰弱监控 health monitor 机制

组成详解

• 我的上一篇分布式文件系统有基本功能的图解本篇不具体讲，挑高可用重点讲
• namenode: 两台互备，一台 active 为主 namenode，对外读写任务调度，综合机架感知，网络拓扑，正本机制，告知 client 去哪个 datanode 进行读或者写
• zkfc 主备切换器: 及时检测 namenode 的衰弱状态，activenamenode 故障时主动进行主备选举和切换
• zookeeper 集群: 为主备切换控制器提供主备选举反对能够看我之前的 zookeeper 性能和选举模式，简略来说就是利用 watch 配合会话长期目录实现抢锁，实现选举
• 共享存储系统: 保留 namenode 在运行过程产生的元数据，同步到备份节点。实现 namenode 的高可用
• datanode

主备切换实现

• zkfc

启动时会创立 healthMonitor 和 activestandbyelecor 两个次要的外部组件，同时注册回调

• HealthMonitor: 检测 namenode 衰弱状态，宕机时会回调 zkfc 对应办法进行主备选举
• ActiveStandByElector: 次要负责实现主动的主备选举，并且回调 zkfc 的办法实现 namenode 主备状态切换

步骤

• 0.zkfc 初始化时创立 healthMonitor
• 1.healthMonitor 初始化实现之后会启动外部的线程定时调用对应的 namenode 中 HAServiceProtocol RPC 接口办法，进行衰弱状态检测
• 2. 检测到衰弱状态变动，会回调 zkfc 注册对应办法解决
• 3. 判断须要主备切换，应用 acitvestandbyelector 进行主动的主备选举
• 4. 选举实现告诉新的主 namenode 和备 namenode
• 5.zkfc 调用对应 namenode 的 HAServiceProtocol RPC 接口的办法将 NameNode 转换为 Active 状态或 Standby 状态。

HealthMonitor，检测的次要局部

• 次要工作

  • 1. 检测 namenode 的两类状态 healthMonitor.state 和 HAServiceStatus。state 反馈 namenode 节点健康状况，次要是磁盘存储资源是否短缺，异样状态有 not_response,unhealthy,failed。

HAServiceStatus，检测中辅助作用

• 反馈 namenode 的 HA 状态

ActiveStandbyElector 主备选举

• 利用 zookeeper 的写一致性和长期节点机制
• 1. 创立锁节点，创立胜利的 namenode 会切换到 active，失败的为备选并且由 ActiveStandbyElector 回调 zkfc 将其转为 standbyzookeeper 性能和选举模式
• 2. 注册 watcher 监听，不论是否抢锁胜利都会注册一个 watch 来监听节点状态变动事件，ActiveStandbyElector 次要关注节点的 nodeDelete

• 3. 主动触发主备选举，

  • 3.1Active NameNode 对应的 HealthMonitor 检测到 namenode 状态异样，zkfc 会被动删除在以后 zookeeper 上建设的锁节点，而 standby 状态的 namenode 的 ActiveStandbyElector 注册的监听器就会收到这个节点的 nodedel 事件，紧接着马上再次进入到创立锁的过程，创立胜利，standby 便转为 active
  • 3.2active 的 namenode 整个机器宕机因为长期节点机制，锁节点被主动删除，也会主动进行一次主备切换

• 4. 避免脑裂

  • zookeeper 客户端负载过高或正在进行 jvm full gc 导致与 zookeeper 服务端心跳不能失常收回屡次国有被断定为会话过期，假如 namenode1 对应 zkfc 假死，zookeeper 认为其挂掉切换主机为 namenode2，此时 namenode1 的 zkfc 随着负载降落恢复正常，但网络提早和 cpu 线程调度不确定导致 namenode1 可能会仍认为本人是 active。namenode1 与 namenode2 此时都能够对外提供服务对于一致性要求高的零碎来说是灾难性的
  • ActiveStandbyElector 采纳了 fencing 将旧节点隔离，不仅用了长期的锁节点 (ActiveStandbyElectorLock)，并且还生成一个长久节点 (ActiveBreadCrumb)，保留以后 acitvenamenode 地址信息，失常敞开 zookeepersession 时该长久节点是会删除的，但某次选举胜利后如果新的 activenamenode 发现旧的长久节点依然存在会回调 zkfc 办法对旧的 namenode 进行 fencing

  • 4.1 其余参考计划

    • 冗余心跳线，多条心跳线尽量减少裂脑事件
    • 智能磁盘锁，正在服务的一方，检测不到对方的心跳时启动磁盘锁
    • 仲裁机制：心跳断开时，ping 网管 ip，不通被动放弃竞争主动重启

zkfc 实现

• zkfc 在创立 healthMonitor 和 acitveStandbyElector 的同时，会向 healthMonitor 和 activeStandbyElector 注册相应的回调，解决则次要靠这些回调
• 如果 ActiveStandbyElector 选主胜利，对应的 namenode 成为主 namenode，ActiveStandbyElector 回调 zkfc 的 becomeActive，而 becomeActive 会调用对应 namenode 的 HAserviceprotocol rpc 接口的 transitiontoacive 办法将 namenode 转为 active
• 选主失败，变为备 namenode，activestandbyelector 会回调 zkfc 的 becomestandby 调用对应 namenode 的 HAServiceProtocol RPC 接口的 transitiontostandby 办法将对应 namenode 变为 standby

• 选主胜利却发现上一个 active 留下来的长久化节点，则先调用 zkfc 注册的 fenceOldActive 尝试隔离旧的 active namenode，过程为以下几局部

  • 1. 尝试调用旧 active namenode 的 HAServiceProtocol RPC 接口的 transittionToStandby 办法，

  • 2. 失败的话执行配置文件中的隔离措施

    • 2.1sshfence 通过 ssh 登录到指标机器执行 fuser 干掉对应过程
    • 2.2shellfence 执行一个用户自定义的 shell 脚本将对应的过程隔离
  • 3. 只有在胜利进行 fencing 后才会再回调 zkfc 的 becomeActive 办法将对应的 namenode 切换为 active 对外提供服务

NameNode 的共享存储实现

元数据存储，namenode 启动复原

• hdfs 原理读写局部简略阐明就是 namenode 在执行 hdfs 客户端提交的操作时会把这些操作记录在 edits 中，肯定条件下，满 64m 或一小时或重启会新建并切换到一个 edits 记录，并且 namenode 会定期对 edits 进行合并生成 fsimage，与 1.x 不同，本来由 secondarynamenode 实现此项工作，
• namenode 启动时须要将 fsimage 文件加载到内存后再加载 edits 复原到敞开前状态
• QJM 共享存储参考 QJM 数据同步

常见问题

• zookeeper 过于敏感导致无谓的 namenode 切换，session-timeout 默认值调高
• 羊群效应，大量节点监控一个节点，变动后须要告诉的节点很多导致性能降落，依据业务调整