zoukankan      html  css  js  c++  java
  • HDFS HA(高可用)

    HDFS HA

    一、HA(High Availability)的使用原因

    1.1 在使用 HA之前

    • 单点故障(SPOF)。整个集群只有一个NameNode,如果这台部署NameNode的主机挂了,那么整个HDFS集群将会停止工作。虽然有SecondaryNameNode,但是SecondaryNameNode只是通过检查点机制来为NameNode合并edit和fsimage文件,只是起到冷备份,当NameNode挂掉后,SecondaryNameNode并不会立即代替NameNode继续工作,而是需要手动通过SecondaryNameNode上的fsimage文件来恢复NameNode,并且NameNode上edit中的操作将会丢失,导致数据不一致。

    • NameNode主机升级。当部署NameNode的主机因为业务需求,需要升级硬件或者底层软件时,就需要关闭NameNode,所以HDFS也不能工作。

    1.2 解决办法

    • 使用两个NameNode。一个作为正在工作的NameNode,称之为Active节点;而另外一个NameNode处于备份状态,称之为Standby节点。当Active节点挂了之后,Standby节点会立即转换为Active状态,来接管集群,使HDFS正常工作。
    • 这就是HDFS的高可用,即HA。对于用户来说,Standby节点的转换是无感知的。
    • 注意:Standby节点会执行检查点机制,因此不再需要配置SecondaryNameNode。

    二、HA的同步

    2.1 JournalNode(JN)集群

    • 原理:要使Standby能够立即代替Active工作,就要保持Standby和Active节点的状态一致(同步)。于是就有了 JN。JN是一个守护进程,为了防止单点故障,JN也被部署在多台主机上,于是称之为JN集群。Active和Standby节点都会跟JN进程进行通信;当Active节点执行命名空间的修改时就会将修改记录写入到大多数 JN中;Standby节点也会一直监视 JN,当发现 JN中的编辑日志(edit)发生更改时,就会将更改应用到自己的命名空间中。当Active的节点挂掉后,Standby节点在转换为Active之前会读取 JN中的所有编辑日志并应用到自己的命名空间;这样,Standby节点的命名空间就完全同步了,就可以接替之前的Active继续工作。

    2.2 防止脑裂的发生

    • 脑裂:由于集群中只能允许一个Active的NameNode,其他的NameNode必须为Standby状态。如果出现多个Active状态的NameNode就称之为脑裂,客户端的更新就会被两个Active的NameNode分散,从而导致数据丢失和不一致。

    • 如何解决:为了防止脑裂的发生,JN一次只能允许一个NameNode写入数据,而其他NameNode只能读取数据。

    2.3 关于 JournalNode

    • JournalNode集群正常工作的条件:1,至少3个 JN节点,所以建议运行基数个的 JN;

      ​ 2,一半以上的 JN正常运行,可以容忍一半以下的 JN发送故障。

    • 注意:为了使Standby节点能够快速工作,DataNode要配置两个NameNode的位置,并向两个NameNode发送心跳包。

    • JournalNode在HA中的位置:JN是属于Hadoop的,并不是ZooKeeper中的组件。虽然Standby节点在 JN的帮助下,已经实现了命名空间的同步;但是当Active节点发生故障时,Standby节点并不会自动转换为Active,而是需要手动操作才行。于是这个时候就需要ZooKeeper集群,来实现自动容灾。

    三、HA的自动容灾

    PS:在这里才开始使用 ZooKeeper,来实现自动故障转移。其中主要用到ZooKeeper quorum和 ZKFailoverController(ZKFC)组件。

    3.1 两个组件的作用

    • ZooKeeper quorum:quorum中文意思就是大多数投票机制,启动ZooKeeper后默认就会启动;在部署的主机中就是一个 QuorumPeerMain进程。ZooKeeper提供了专门的机制来选择一个Active的NameNode,当Active发生故障后,另一个Standby节点会在ZooKeeper中采取特殊的排他锁,以指示它应该成为下一个Active的节点。而ZooKeeper内部的机制就保障了集群的一致性。

    • ZKFC:ZKFC是ZooKeeper的客户端,运行NameNode的主机上都会运行一个ZKFC进程;ZKFC进程会定期ping其本地的NameNode,如果NameNode以健康状态响应,则ZKFC认为该NameNode是健康的;如果节点故障,则将其标记为不正常。如果本地Active节点正常,则它会持有一个锁定znode,该znode是一个临时节点,会话结束后会自动删除;

    3.2 基于ZooKeeper的选举:

    • 如果Active节点发生故障,则正常的Standby节点中的ZKFC发现目前没有其他节点持有锁定znode,那么它自己会测试获取该锁;如果成功,则它赢得了选举,并负责运行故障转移,以使其本地的NameNode由Standby转换为Active,继续工作。

    具体配置文件

    链接:https://pan.baidu.com/s/1VyFI3V4KzSafUJsMsrJsvQ
    提取码:x8iq

  • 相关阅读:
    姐姐的vue(1)
    LeetCode 64. Minimum Path Sum 20170515
    LeetCode 56. 56. Merge Intervals 20170508
    LeetCode 26. Remove Duplicates from Sorted Array
    LeetCode 24. Swap Nodes in Pairs 20170424
    LeetCode 19. Remove Nth Node From End of List 20170417
    LeetCode No.9 Palindrome Number 20170410
    LeetCode No.8. String to Integer (atoi) 2017/4/10(补上一周)
    LeetCode No.7 Reverse Integer 2017/3/27
    LeetCode No.4 Median of Two Sorted Arrays 20170319
  • 原文地址:https://www.cnblogs.com/shendeng23/p/12420886.html
Copyright © 2011-2022 走看看