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状态的切换。这是一般引起的切换的流程。
本文来自博客园,作者:业余砖家,转载请注明原文链接:https://www.cnblogs.com/yeyuzhuanjia/p/17138486.html