Hadoop 容错之1.X的单点故障 到 2.X的HA和HDFS Federation

标签: HAHDFS Federationhadoop单点故障
1476人阅读 评论(0) 收藏 举报
分类:

转载请注明出处:@http://blog.csdn.net/gamer_gyt,Thinkagmer 撰写

博主微博:http://weibo.com/234654758 (欢迎互撩)

私人博客:http://blog.cyanscikit.top (尚在开发中)
Github:https://github.com/thinkgamer

=============================================================================

写在前边的话

   动手准备写这篇博客,想的挺多,但是到了笔下,却很难说的一清二楚

   上一篇博客中我介绍了如何部署Hadoop HA(High Availability),在这篇博客中我们就来看一下Hadoop容错机制的演变之路


一:1.x和2.x的架构对比

   具体可参考之前的一篇博文:Hadoop1.X 与 Hadoop2.X比较

二:hadoop 1.X的单点故障

   1)JobTracker 是 Map-reduce 的集中处理点,存在单点故障

   2)JobTracker 完成了太多的任务,造成了过多的资源消耗,当 map-reduce job 非常多的时候,会造成很大的内存开销,潜在来说,也增加了 JobTracker 失效的风险,这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限;

   在1.x版本中给出的解决方案主要有以下几种

   1:Secondary NameNode

     需要声明的是SNN不是NameNode的备份。他的作用是定期合并fsimage和edits文件,并推送给NameNode,以缩短集群启动的时间,当NN失效的时候,SNN并无法立刻提供服务,甚至无法保证数据的完整性,如果NN数据丢失,在上一次合并后的文件系统的改动就会丢失。

     SNN的作用在2.x版本中可以被两个节点替换CheckpointNodeBackuoNode

     CheckpointNode可以理解为与SNN的作用一致,BackupNode是NN的完全备份

     配置文件对应的core-site.xml

     配置项为:         

fs.checkpoint.period
fs.checkpoint.size
fs.checkpoint.dir
fs.checkpoint.edits.dir

     SNN定期合并流程,如下所示

[root@master1 current]# cat VERSION 
#Tue Aug 30 05:46:05 CST 2016
namespaceID=1476026471
clusterID=CID-8ec4991f-2f2e-4579-be1a-cfa862c87ba1
cTime=0
storageType=JOURNAL_NODE
layoutVersion=-63
     VERSION     文件保存了HDFS的版本号

     layoutVersion  是一个负整数,保存了HDFS的持续化在硬盘上的数据

     namespaceID   是文件系统的唯一标识符,在文件系统初次格式化时生成

     cTime       此处为0

     storageType   表示此文件夹中保存的是元数据节点的数据结构

     NN进程挂掉之后,怎么进行数据恢复?

     (1):删除SNN存放那个数据目录下in_use.lock文件

     (2):执行恢复命令 hadoop-daemon.sh -importCheckpoint

     (3):启动NN hadoop-daemon.sh start namenode

     (4):进行校验检查根目录是否健康 hadoop fsck /

     (5):查看数据 hadoop fs -lsr /

     至此NN元数据恢复成功,但是仍然存在数据丢失的情况

    2:CheckpointNode

     作用和SNN是一样的,启动命令为 hadoop namenode -checkpoint

     配置文件:core-site.xml

fs.checkpoint.period
fs.checkpoint.size
fs.checkpoint.dir
fs.checkpoint.edits.dir

    3:BackupNode

     提供一个真正意义上的备用节点,在内存中维护一份从NN同步过来的fsimage,同时还把从MM接受edits文件的日志流,并把它们持久化硬盘。

     BackupNode在内存中维护与NN一样的Matadata数据,启动命令为hdfs namenode -backup

     配置文件:hdfs-site.xml

dfs.backup.address
dfs.backup.http.address  

三:Hadoop HA(高可用性)

    这里需要说明的是SNN在hadoop2.x依然存在,只不过已经有了HA,对其进行了工作的替代,所有就不必再配置了

    1:基本原理

    hadoop2.0的HA 机制有两个namenode,一个是active namenode,状态是active;另外一个是standby namenode,状态是standby。两者的状态是可以切换的,但不能同时两个都是active状态,最多只有1个是active状态。只有active namenode提供对外的服务,standby namenode是不对外服务的。active namenode和standby namenode之间通过NFS或者JN(journalnode,QJM方式)来同步数据。

  active namenode会把最近的操作记录写到本地的一个edits文件中(edits file),并传输到NFS或者JN中。standby namenode定期的检查,从NFS或者JN把最近的edit文件读过来,然后把edits文件和fsimage文件合并成一个新的fsimage,合并完成之后会通知active namenode获取这个新fsimage。active namenode获得这个新的fsimage文件之后,替换原来旧的fsimage文件。

  这样,保持了active namenode和standby namenode的数据的实时同步,standby namenode可以随时切换成active namenode(譬如 active namenode挂了)。而且还有一个原来hadoop1.0的secondarynamenode,checkpointnode,buckcupnode的功能:合并edits文件和fsimage文件,使fsimage文件一直保持更新。所以启动了hadoop2.0的HA机制之后,secondarynamenode,checkpointnode,buckcupnode这些都不需要了。

    2:NFS(Network File System)

   NFS作为active namenode和standby namenode之间数据共享的存储。active namenode会把最近的edits文件写到NFS,而standby namenode从NFS中把数据读过来。这个方式的缺点是,如果active namenode或者standby namenode有一个和NFS之间网络有问题,则会造成他们之前数据的同步出问题。                                                                                      

   3:QJM(QuorumJournal Manager)

   QJM的方式可以解决上述NFS容错机制不足的问题。active namenode和standby namenode之间是通过一组journalnode(数量是奇数,可以是3,5,7...,2n+1)来共享数据。active namenode把最近的edits文件写到2n+1个journalnode上,只要有n+1个写入成功就认为这次写入操作成功了,然后standby namenode就可以从journalnode上读取了。可以看到,QJM方式有容错的机制,可以容忍n个journalnode的失败。                  

              

   4:主备节点切换

  active namenode和standby namenode可以随时切换。当active namenode挂掉后,也可以把standby namenode切换成active状态,成为active namenode。可以人工切换和自动切换。人工切换是通过执行HA管理的命令来改变namenode的状态,从standby到active,或者从active到standby。自动切换则在active namenode挂掉的时候,standby namenode自动切换成active状态,取代原来的active namenode成为新的active namenode,HDFS继续正常工作。

  主备节点的自动切换需要配置zookeeper。active namenode和standby namenode把他们的状态实时记录到zookeeper中,zookeeper监视他们的状态变化。当zookeeper发现active namenode挂掉后,会自动把standby namenode切换成active namenode。

             

四:ResourceManager HA

    两个RM启动的时候都是standy,进程启动以后状态未被加载,转换为active以后才会加载相应的状态并启动服务,RM的转换可以通过Zookeeper来进行监控和切换

    具体的流程如下:

    (1)RM的作业信息存储在ZK的/rmstore下,Active RM向这个目录写APP 的信息

    (2)RM启动的时候会通过向ZK的/Hadoop-ha目录下写一个Lock文件,写成功则成为Active,否则为Standy,Standy RM会一直监控Lock文件是否存在,如果不存在,则会试图去创建,则争取成为Active RM

    (3)当Active RM 挂掉,另外一个StandyRM 成功转换为Active RM后,会从/rmstore读取相应的作业信息,重新构建作业的内存信息,然后启动内部服务,开始接受NM的心跳,构建集群资源信息,并接收客户端提交作业的请求等

              

      RM的HA 配置为:

<configuration>
  <property>
    <name>yarn.resourcemanager.ha.enabled</name>
    <value>true</value>    <!-- 开启RM高可用 -->
  </property>  
  <property>
    <name>yarn.resourcemanager.ha.automatic-failover.enabled</name>
    <value>true</value>    <!--启动自动故障转移,默认为false-->
  </property>
  <property>
    <name>yarn.resourcemanager.ha.automatic-failover.embedded</name>
    <value>true</value>    <!--启用一个内嵌的故障转移,与ZKRMStateStore一起使用。-->
  </property>
  <property>
    <name>yarn.resourcemanager.cluster-id</name>
    <value>yrc</value>    <!-- 指定RM的cluster id -->
  </property>
  <property>
    <name>yarn.resourcemanager.ha.rm-ids</name>
    <value>rm1,rm2</value>    <!-- 指定RM的名字 -->
  </property>
   <property>
    <name>yarn.resourcemanager.hostname.rm1</name>
    <value>master1</value>    <!-- 分别指定RM的地址 -->
  </property>
    <property>
    <name>yarn.resourcemanager.hostname.rm2</name>
    <value>master2</value>    <!-- 分别指定RM的地址 -->
  </property>
  <property>
    <name>yarn.resourcemanager.ha.id</name>
    <value>rm1</value>
    <description>If we want to launch more than one RM in single node, we need this configuration</description>
  </property> 
  <property>  
    <name>yarn.resourcemanager.recovery.enabled</name>  
    <value>true</value>  
  </property>  
  <property>  
    <name>yarn.resourcemanager.store.class</name>  
    <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>  
  </property>    
  <property>
    <name>yarn.resourcemanager.zk-address</name>
    <value>master1:2181,master2:2181,slaver1:2181</value>    <!-- 指定zk集群地址 -->
  </property>
  <property>
    <name>yarn.nodemanager.aux-services</name>
    <value>mapreduce_shuffle</value>
  </property>
</configuration>

五:HDFS Federation(HDFS联邦)

      参考之前的博客:HDFS Federation(HDFS 联邦)(Hadoop2.3)



0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    Thinkgamer微博
    个人微信,一起交流!

     扫一扫,关注我




    个人资料
    • 访问:695176次
    • 积分:8922
    • 等级:
    • 排名:第2108名
    • 原创:211篇
    • 转载:22篇
    • 译文:2篇
    • 评论:259条
    个人简介
    姓名:Thinkgamer

    Github:https://github.com/thinkgamer

    主攻:云计算/python/数据分析

    程度:熟悉/熟悉/熟悉

    微信:gyt13342445911

    Email:thinkgamer@163.com

    工作状态:在职ing

    心灵鸡汤:只要努力,你就是下一个大牛...

    hadoop/spark/机器学习群:279807394(大神建的群,蹭个管理员)

    欢迎骚扰........
    博客专栏
    最新评论