ZKFC(Zookeeper Failover Controller)原理【详细版】

标签: zkfc
8人阅读 评论(0) 收藏 举报
分类:

ZKFC设计文档(ZK Failover Controller Design)

  1. 设计

    1. 组件化设计,ZK-based的automatic Failover主要由三个组件组成:

      1. HealthMonitor:用于监控NN是否unavailable或者处于unhealth状态
      2. ActiveStandbyElector:用于监控NN在zk中的状态
      3. ZKFailoverController:从HealthMonitor和ActiveStandbyElector中订阅事件并管理NN的状态,另外ZKFC还需要负责fencing。
      4. 现阶段,上述三个组件都在跑在一个JVM中,这个JVM与NN的JVM在同一个机器上。但是是两个独立的进程。一个典型的HA集群,有两个NN组成,每个NN都有自己的ZKFC进程。
        img
        部署示意图
    2. HealthMonitor设计

      • HealthMonitor由HADOOP-7788完成提交,它由一个loop循环的调用一个monitorHealth rpc来检视本地的NN的健康性。如果NN返回的状态信息发生变化,那么它将经由callback的方式向ZKFC发送message。HealthMonitor具有一下状态:

        1. INITIALIZING:HealthMonitor已经初始化好,但是仍未与NN进行联通
        2. SERVICE NOT RESPONDING:rpc调用要么timeout,要么返回值未定义。
        3. SERVICE HEALTHY:RPC调用返回成功
        4. SERVICE UNHEALTHY:RPC放好事先已经定义好的失败类型
        5. HEALTH MONITOR FAILED:HealthMonitor由于未捕获的异常导致失败。
    3. ActiveStandbyElector设计

      1. ActiveStandbyElector (committed in HADOOP-7992 and improved in HADOOP-8163, HADOOP-8212)主要负责凭借ZK进行协调,和ZKFC主要进行以下两个方面的交互:
        1. joinElection()–通知ASE,本地的NN可以被选为活动NN
        2. quitElection()–通知ASE,本地的NN不能被选为活动NN
      2. 一旦ZKFC调用了joinElection,那么ASE将试图获取ZK中的lock(an ephemeral znode,automatically deleted when ZKFC crash or lost connection),如果ASE成功的创建了该lock,那么它向ZKFC调用becomeActive()。否则调用becameStandby()并且开始监控这个lock(其他NN创建的)
      3. 如果当前lock-holder失败了,另一个监控在这个lock上的ZKFC将被触发,然后试图获取这个lock。如果成功,ASE将同样的调用becomeActive方法来通知ZKFC
      4. 如果ZK的session过期,那么ASE将在本地NN上调用enterNeutralMode而不是调用becomeStandby。因为他没法知道是否有另一个NN已经准备好接管了。这种情况下,将本地NN转移到Standby状态是由fencing机制来完成(详见下文)。
    4. ZKFC设计

      • ZKFC本身非常简单,它运行以下进程:

        1. 启动时,通知HealthMonitor去监控本地NN。然后使用配置好的ZK去初始化ASE。但是绝不能立即参加Election。
        2. 当HealthMonitor的状态改变时,ZKFC相应的做出如下反应:
        3. SERVICE_HEALTHY—通知elector去join Election,如果还没有的话。
        4. HEALTH MONITOR FAILED—中断所有的ZKFC进程,因为ZKFC也没法工作了。
        5. INITIALIZING—这个情况一般是NN刚刚重启还没准备好进行服务。ZKFC会退出Election,并且通知fencing是没必要进行的。因为NN总是以Standby来开始。
        6. Other states—退出Election,如果当前是在Election状态。
        7. 当ActiveStandbyElector发布一个改变的时候,ZKFC做出如下反应:
        8. becomeActive() - ZKFC将在本地NN上调用transitionToActive()。如果失败了,将退出Election然后sleep一段时间,重新进入Election。Sleep是为了让其他准备好了的NN也有机会成为ActiveNN。这种情况下退出Election并不会删除breadcrumb node {这是为了确保了无论谁成为了ActiveNN之后可以fencing这个NN,尽管这个情况的失败可能导致这个NN可能会进入partially-active状态。}
        9. becomeStandby() - 在本地NN上调用transitionToStandby() ,如果失败,另一个NN将毫不犹疑的将这个NN进行fencing。(详见fencing)
        10. enterNeutralMode() - 当前没有反应,因为目前的设计中,不会进入此状态。
        11. fenceOldActive(…) - 详见fencing
        12. notifyFatalError(…) - 中断ZKFC,因为已经没法正常工作了。
        13. 所有的调用都是在ZKFC上进行同步,这样确保了串行化所有事件的顺序确保其逻辑的正确性。
    5. Fencing设计

      • HADOOP-8163对ASE进行了增强,主要是通过增加了fencing的回调机制,详细如下:

        1. 在获取了ActiveLock之后,通知本地NN成为了Active之前,检查breadcrumb znode的存在性
        2. 面包屑Znode存在的话,调用fenceOldActive(data)从那个NN上传入data数据,如果成功了,删除面包屑Znode
        3. 如果fencing失败,log一个error,扔掉lock,sleep一会,重新进行Election。这样也给其他NN有机会成为ActiveNN
        4. 使用本地NN的标识数据,创建一个新的breadcrumb node。
        5. 当退出Election的时候,quiting的NN能够自己判定是否需要fencing。如果需要,将删除breadcrumb node,然后关闭ZK session。
    6. ZKFC的状态机图

      • img
    7. 尽管有了Automatic-Failover,但是能够进行手工的Failover对管理员来说也是个很好的选择,特别是在有计划的升级软硬件的时候和想要指定NN为Active的时候。

      1. 开始的时候,只能通过Failover只能通过fail来触发。所以要达到想要的结果只能手工模拟fail的情况,比如kill掉一个NN以便让另一个NN成为ActiveNN。这有如下缺点:

        1. 没有对standby机器的预先检查机制,如果standby不是ready的话,这将导致service不可用。
        2. 如果standby在成为Active的时候失败,将不能很快切回去,因为另一个NN已经killed
        3. 考虑到之前的ActiveNN被un-gracefully失效,这将导致fencing的执行,有可能导致STONITH等其它fencing,这对于管理员只想做个小改动来说too heavy。
      2. 因此通过以下的改变,带来了手动的failover:

        • 为每个namespace加入一个dfs.ha.auto-failover.enabled配置项。如果为true,将导致以下行为:

          1. haadmin -failover命令不再直接对NN进行Rpc调用,而是采用以下描述的方式来代替
          2. NN进入到一个只能接受mutative HAServiceProtocol RPCs从ZKFCs
          3. start-dfs.sh也可以自动在所有的NN机器上启动ZKFC
      3. 手动Failover的操作

        • 当管理员执行Failover时候,首先执行haadmin -failover -to ,我们会自动将其转化为no-automatic的设置语法 haadmin -failover -from -to 。以下操作将被执行
          1. 检查被选NN的健康状况,如果不是healthy,将抛出异常
          2. 检查是否已经成为Active,如果是,返回成功。
          3. 发送一个concedeLock() RPC给当前的活动ZKFC,这个ZKFC将会执行:
          4. 发送一个transitionToStandby() RPC给本地NN
          5. 如果成功,那么删除其留下的breadcrumb node,否则不动。
          6. 退出Election,设置一个定时器,在下一个5-10秒内将不会再次参加Election。
          7. 当这个RPC返回时,希望lock已经被其他NN给drop了,等待5-10秒在验证这个NN是否已经成功获取了该lock。等到本地NN要么成功成为了ActiveNN,要么失效,然后返回给client这个结果。
        • 目前仅仅假定只有两个NN在参加Election,将来我们将支持多个standbyNN,这需要添加新的znode来标识需要成为Active的NN,然后更改Election的过程,在这个NN想获取lock之前先检查这个NN。
  2. 示例场景

    1. ActiveNN产生JVM crash
      • 一旦这种情况发生,HealthMonitor在调用monitorHealth()将失效。然后HM将向ZKFC调用enterState(SERVICE_NOT_RESPONDING),本地ZKFC将退出Election,另外一个ZKFC获取active lock,执行fencing,变成active。
    2. ActiveNN JVM freeze(e.g sigstop)
      • 如果JVM freeze了但是没有crash掉,这与上面情况一直,monitorHealth会由于timeout而引发上述过程。FUTURE-WORK:使用JVMTI来判断NN是否在进行gc,如此可以使用另一个timeout来为gc进行failover。
    3. ActiveNN machine crash
      • 当整个机器crash了,ASE在zk的session将会过期,另一个ZKFC将会获取这个事件,引发failover。
    4. Active ZKFC crash
      • 尽管ZKFC设计简单,但是仍然有可能会crash掉,在这个情况下,failover将会被错误的触发。另一个NN的ZKFC将会对ActiveNN调用transitionToStandby让它放弃active lock,然后进行aggressive fencing。尽管会成功,但是会导致进行了一次没有必要的failover。
    5. Zookeeper crash
      1. 当zk集群crash了,那么所有的ZKFC将收到DISCONNECTED事件。然后ZKFC在本地NN调用enterNeutralMode,除此之外不做任何改变。系统除了不能执行failover之外,与其他情况无异。
      2. 当zk恢复了,clients立马能够重连。而zk能够将之前的session信息重新被各个client进行获取(在启动的一个timeou时间内)。所以所有的nodes将会重新获取session,不需要进行无必要的failover。
      3. FutureWork:breadcrumb znode在这个情况下可以优先的给予到ActiveNN,在ZK挂掉之前。
  3. 待发掘的细节

    1. 和手动failover的集成
      1. 如前所述,尽管有了强大的automatic failover,但是手动的failover在某些场合下仍是不二选择。
      2. 加入一个简单的quiesceActiveState() RPC接口到ZKFC,这个rpc通知NN退出Election,并等待StandbyNN发起failover,如果等待超时仍未有failover发起,那么这个NN重新获取Active lock。并向client汇报错误。
  4. Future work

    1. 优先节点
      • 某些情况,可能希望为将指定的NN成为ActiveNN。现阶段是通过公平竞争来获取Active lock从而变成ActiveNN。可以通过两个方式来达成这个目的:一个是延迟非优选节点加入Election。另一个是提供failback将非优选节点从ActiveNN变成StandbyNN。
    2. 自我fencing
      • 当HM通知本地NN变成unhealthy时候,在退出Election之前,ZKFC能够执行自我fencing。例如,它能进行fuse -k -9 来强制击杀本地NN。这个方法能够避免很多复杂的fencing机制
    3. 管理Process
      • 当前的设计认为ZKFC process和本地NN独立的运行。NN挂掉了,ZKFC也不会视图去重启它,只是继续监控IPC端口直到NN被另外方式重启了。
      • 当然如果ZKFC来负责NN的进程管理,这样使得部署要简单些,但是同时也增加了ZKFC本身的复杂度。因为java中的进程管理就是一坨屎。尽管如此当前的模块化设计足以使得以后如要进行这个工作很直接

转载自:http://blog.csdn.net/chenpingbupt/article/details/7922042

查看评论

zookeeper

ZooKeeper是现在企业项目开发之中使用最多的协调一致性组件,其不仅仅在大数据领域内有着重要的作用,在分布式开发领域内依然重要,本课程将为读者讲解ZooKeeper的作用,以及相关的代码开发操作。
  • 2017年01月20日 07:38

ZKFailoverController( zkfc)介绍

1.基本原理 zk的基本特性: (1) 可靠存储小量数据且提供强一致性 (2) ephemeral node, 在创建它的客户端关闭后,可以自动删除 (3) 对于node状态的变化,可以提...
  • tzwjava
  • tzwjava
  • 2014-11-03 16:31:43
  • 5873

Hadoop-2.7.0中HDFS NameNode HA实现之DFSZKFailoverController、ZKFailoverController(一)

一、简介      DFSZKFailoverController是Hadoop-2.7.0中HDFS NameNode HA实现的中心组件,它负责整体的故障转移控制等。它是一个守护进程,通过main...
  • lipeng_bigdata
  • lipeng_bigdata
  • 2016-12-14 14:40:29
  • 4846

zookeeper报错:Unable to start failover controller. Parent znode does not exist. Run with -formatZK fla

报错原因:我在做phoenix upsert 操作时,误操作,删除了来源表hbase的底层hdfs的数据,导致正在执行的phoenix任务挂掉,整个集群挂掉(由于hdfs的挂掉,导致的集群挂掉),如图...
  • u012551524
  • u012551524
  • 2017-08-22 18:12:12
  • 479

zookeeper hadoop-ha znode丢失导致hadoop不能failover的解决办法

今天系统维护,hdfs haadmin -failover nn1 nn2 失败。 用jps查看java进程,发现没有DFSZKFailoverController进程。 打开zkfc的日志,发现...
  • houzhizhen
  • houzhizhen
  • 2015-03-06 15:07:47
  • 5860

ZooKeeper与NanmeNode的HA的一些理解,包括hdfs zkfc -formatZK的作用等。但与DN无关

原文地址1     原文地址2 本文只说理论,不设计如何配置和部署这些实例 0、引子 zkfc是什么? ZKFailOverController 主要作用:作为一个ZK集群的客户端,用来监控...
  • darkdragonking
  • darkdragonking
  • 2017-05-29 00:55:33
  • 1666

zookeeper-3.4.6格式化问题 hdfs zkfc -formatZk报错

感谢朋友的提醒:错误在配置hdfs-site.xml文件
  • qq_23280769
  • qq_23280769
  • 2015-08-20 16:57:23
  • 5357

NameNode HA自动Failover设计文档(HDFS-3042/HDFS-2185:Automatic failover support for NN HA)

ZKFC设计文档(ZK Failover Controller Design) chenpingbupt@gmail.com 转载请注明来自本空间:http://blog.csdn...
  • chenpingbupt
  • chenpingbupt
  • 2012-08-29 22:02:11
  • 4612

[HADOOP] 简单了解NameNode的ZKFC机制

之前在准备中级课程PPT,整理了下HA的基本内容,并且感谢松哥为我们提供了HA不会切的问题,以至于之后刚好出现的NameNode宕机,能够快速解决。 NameNode的HA可以个人认为简单分为共...
  • sinat_29581293
  • sinat_29581293
  • 2017-03-30 18:16:19
  • 285

HDFS ZKFC自动切换原理分析

前言Hadoop社区在HDFS-1623(High Availability Framework for HDFS NN)以及相关JIRA中对NameNode增加了高可用性的支持。但是它的实现需要依赖...
  • Androidlushangderen
  • Androidlushangderen
  • 2016-11-13 16:54:54
  • 6609
    个人资料
    等级:
    访问量: 393
    积分: 252
    排名: 30万+
    文章存档