HDFS中ZKFailoverController的原理探究

自动化failover的引入

HDFS中自动化的failover故障转移需要增加两个新的组件：一个是Zookeeper quorum（仲裁），另一个是ZKFailoverController进程（简称ZKFC）。

Apache Zookeeper是一个高可用的服务，对于小规模数据协调，通知客户端数据变化，监控客户端失败。自动failover的实现是基于ZK以下的作用：

• Failure detection
  集群中的每个NameNode机器在ZK上保持持久化会话。如果机器崩溃，ZK会话过期，通知其它NameNode有一个failover将被触发。

• Active NameNode election
  ZK提供一个简单机制，选举出唯一的一个节点作为active。如果当前的active NameNode崩溃，另一个节点可能在ZK持有特定的互斥型锁，表名它将成为下一个active。

---

ZKFC是一个ZK客户端，也监控和管理NameNode的状态。NameNode运行的所在的每个机器也要运行一个ZKFC。

ZKFC负责：

• 健康监测
  ZKFC定期使用健康检查命令调用其本地NameNode。只要NameNode以健康的状态及时响应，ZKFC就会认为节点是健康的。
  如果节点已崩溃、冻结或以其他方式进入不健康状态，则健康监视器将将其标记为不健康。

• ZooKeeper会话管理
  当本地NameNode健康时，ZKFC在ZooKeeper中举行一个开放的会话。
  如果本地NameNode是活动的，它也持有一个特殊的“锁”。此锁使用ZooKeeptor对“临时”节点的支持；如果会话过期，则将自动删除锁节点。

• 基于ZooKeeper的选举
  如果本地NameNode是健康的，而ZKFC认为目前没有其他节点持有锁，
  它本身就会尝试获取锁。如果它成功了，那么它已经“赢得了选举”，并负责运行故障转移以使其本地NameNode活动。故障转移过程类似于上面描述的手动故障转移：首先，如果需要，对前一个活动进行隔离，然后本地NameNode转换到活动状态。

---

问题：

• 一般导致NameNode切换的原因
• ZKFC的作用是什么？如何判断一个NN是否健康
• NameNode HA是如何实现的？
• NameNode因为断电导致不能切换的原理，怎样进行恢复

一般导致NameNode切换的原因

随着集群规模的变大和任务量变多，NameNode的压力会越来越大，一些默认参数已经不能满足集群的日常需求，除此之外，异常的Job在短时间内创建和删除大量文件，引起NN节点频繁更新内存的数据结构从而导致RPC的处理时间变长，CallQueue里面的RpcCall堆积，甚至严重的情况下打满CallQueue，导致NameNode响应变慢，甚至无响应，ZKFC的HealthMonitor监控自己的NN异常时，则会断开与ZooKeeper的链接，从而释放锁，另外一个NN