Zookeeper-ZKFC的原理和功能

一、前言

HADOOP2 HA架构引入了ZKFC、Journalnode组件，本篇文章主要介绍ZKFC的功能和原理。HA架构支持两种切换方式：

• 手动切换:  通过命令实现主备之间的切换，可以用HDFS升级等场合；
• 自动切换:  ZKFC（ Zookeeper FailOver Controller ）

自动化failover的引入：

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

二、Zookeeper介绍

ZooKeeper是一个分布式的高可用的，开放源码的分布式应用程序协调服务，是Hadoop和Hbase等应用的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

Zookeeper的基本特性：
(1) 可靠存储小量数据且提供强一致性；
(2) ephemeral node（创建的锁节点）, 在创建它的客户端关闭后，可以自动删除；
(3) 对于node状态的变化，可以提供异步的通知(watcher)。

zk在zkfc中可以提供的功能：
(1) Failure detector（通过watcher监听机制实现）: 及时发现出故障的NN，并通知zkfc
(2) Active node locator: 帮助客户端定位哪个是Active的NN
(3) Mutual exclusion of active state（通过加锁）: 保证某一时刻只有一个Active的NN。

三、ZKFC介绍

（1）架构图

ZKFC是要和NN（NameNode）一一对应的，两个NN就要部署两个ZKFC。它负责监控NN的状态，并及时的把状态信息写入ZK。它通过一个独立线程周期性的调用NN上的一个特定接口来获取NN的健康状态。ZKFC也有选择谁作为Active NN的权利，因为最多只有两个节点，目前选择策略还比较简单（先到先得，轮换）。

原理简单来说，就是监控NameNode健康状态并向Zookeeper注册NameNode，NameNode挂掉后，ZKFC为NameNode竞争锁，获得ZKFC锁的NameNode变为active。

（1）zkfc是什么？

ZKFailOverController是Hadoop中通过ZK实现FC（故障转移）功能的一个实用工具。

（2）主要作用？

作为一个ZK集群的客户端，用来监控NN的状态信息，实现NameNode的自动切换。

（3）谁会用它？

每个运行NN（NameNode）的节点必须要运行一个zkfc。

（4）formatZK干了啥？

因为ZKFC需要把NN的状态写给ZK，所以命令这个就是为了创建一个父目录，后续ZKFC会把NN的状态写到这下面给ZK看的。

四、ZKFC的作用

（1）健康监测

ZKFC定期对本地的NN发起健康检查（health-check）的命令，如果NN正确返回（以健康的状态及时响应），那么这个NN被认为是健康的。否则被认为是失效节点。

（2）ZooKeeper会话管理

当本地NN是健康的时候，zkfc将会在zk中持有一个session。如果本地NN又正好是active的，那么zkfc还有持有一个"ephemeral"的节点作为锁，一旦本地NN失效了，那么这个节点将会被自动删除。

（3）基于ZooKeeper的选举

如果本地NN是健康的，并且zkfc发现没有其他的NN持有那个独占锁。那么他将试图去获取该锁，一旦成功，那么它就需要执行Failover，然后成为active的NN节点。Failover的过程是：第一步，对之前的NN执行fence，如果需要的话。第二步，将本地NN转换到active状态。

五、模块

(1) ZKFailoverController(DFSZKFailoverController): 驱动整个ZKFC的运转，通过向HealthMonitor和ActiveStandbyElector注册回调函数的方式，subscribe HealthMonitor和ActiveStandbyElector的事件，并做相应的处理。
(2) HealthMonitor: 定期check NN的健康状况，在NN健康状况发生变化时，通过回调函数把变化通知给ZKFailoverController。
(3) ActiveStandbyElector: 管理NN在zookeeper上的状态，zookeeper上对应node的结点发生变化时，通过回调函数把变化通知给ZKFailoverController。
(4) FailoverController: 提供做graceful failover的相关功能(dfs admin可以通过命令行工具手工发起failover)。

六、线程模型

ZKFC的线程模型总体上来讲比较简单的，它主要包括三类线程，一是主线程；一是HealthMonitor线程; 一是zookeeper客户端的线程。它们的主要工作方式是：
(1) 主线程在启动所有的服务后就开始循环等待；
(2) HealthMonitor是一个单独的线程，它定期向NN发包，检查NN的健康状况；
(3) 当NN的状态发生变化时，HealthMonitor线程会回调ZKFailoverController注册进来的回调函数，通知ZKFailoverController NN的状态发生了变化；
(4) ZKFailoverController收到通知后，会调用ActiveStandbyElector的API，来管理在zookeeper上的结点的状态；
(5) ActiveStandbyElector会调用zookeeper客户端API监控zookeeper上结点的状态，发生变化时，回调ZKFailoverController的回调函数，通知ZKFailoverController，做出相应的变化。

七、一般导致NameNode切换的原因

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