前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Hadoop基础教程-第9章 HA高可用(9.1 HDFS 高可用介绍)

Hadoop基础教程-第9章 HA高可用(9.1 HDFS 高可用介绍)

作者头像
程裕强
发布2022-05-06 18:52:11
8420
发布2022-05-06 18:52:11
举报
文章被收录于专栏:大数据学习笔记

第9章 HA高可用

9.1 HDFS 高可用介绍

HDFS HA(High Availability)高可用配置官方参考网址 http://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

9.1.1 背景

Prior to Hadoop 2.0.0, the NameNode was a single point of failure (SPOF) in an HDFS cluster. Each cluster had a single NameNode, and if that machine or process became unavailable, the cluster as a whole would be unavailable until the NameNode was either restarted or brought up on a separate machine. 在Hadoop 2.0.0之前,NameNode是HDFS集群中的单点故障(SPOF)。 每个集群都有一个NameNode,如果该机器或进程变得不可用,则整个集群将不可用,直到NameNode重新启动或在单独的计算机上启动。

下面两个方面影响了HDFS集群的总体可用性:

  • In the case of an unplanned event such as a machine crash, the cluster would be unavailable until an operator restarted the NameNode. 在计划外事件(如机器崩溃)的情况下,集群将不可用,直到操作员重新启动NameNode。
  • Planned maintenance events such as software or hardware upgrades on the NameNode machine would result in windows of cluster downtime. NameNode机器上的计划维护事件(如软件或硬件升级)将导致集群停机的窗口。

The HDFS High Availability feature addresses the above problems by providing the option of running two redundant NameNodes in the same cluster in an Active/Passive configuration with a hot standby. This allows a fast failover to a new NameNode in the case that a machine crashes, or a graceful administrator-initiated failover for the purpose of planned maintenance. HDFS高可用性功能通过提供在具有热备用的主动/被动配置中的同一集群中运行两个冗余名称节点的选项来解决上述问题。 这允许在机器崩溃的情况下快速故障转移到新的NameNode,或者为了计划维护而对管理员启动的优化转换进行了优雅。

9.1.2 架构

Hadoop2.x(HA)中HDFS的高可靠指的是可以同时启动2个NameNode。其中一个处于工作状态(Active ),另一个处于随时待命状态(Standby)。当一个Active NameNode所在的服务器宕机时,可以在数据不丢失的情况下,手工或者自动将另一个Standby NameNode切换到Active 并继续提供服务。

JournalNode作用: (1)为了使备用节点(Standby NameNode)将其状态与Active节点保持同步,两个节点与一组名为“JournalNode”(JN)的单独守护程序进行通信。 (2)当Active NameNode执行任何命名空间修改时,会把最近的操作记录写到本地的一个edits文件中(edits file),并传输到大部分中JournalNode(写入2n+1个journalnode上,只要有n+1个写入成功就认为这次写入操作成功了)。 (3)standby namenode定期的检查,从JournalNode把最近的edit文件读过来,然后把edits文件和fsimage文件合并成一个新的fsimage。Standby NameNode可以确保在集群出错时,NameNode命名空间状态已经完全同步了。 (4)standby namenode合并生成新的fsimage后会通知active namenode获取这个新fsimage。active namenode获得这个新的fsimage文件之后,替换原来旧的fsimage文件。

主备节点的切换: 为了提供快速故障切换,还需要备用节点具有关于集群中块的位置的最新信息。为了实现这一点,DataNodes被配置为具有两个NameNodes的位置,并且向两者发送块位置信息和心跳。 人工切换是通过执行HA管理的命令来改变namenode的状态,从standby到active,或者从active到standby。自动切换则在active namenode挂掉的时候,standby namenode自动切换成active状态,取代原来的active namenode成为新的active namenode,HDFS继续正常工作。

对于HA群集的正确操作至关重要,因此一次只能有一个NameNodes处于活动状态。否则,命名空间状态将在两者之间迅速分歧,冒数据丢失或其他不正确的结果。为了确保这个属性并防止所谓的“分裂大脑情景”,JournalNodes将只允许一个NameNode作为一个作者向JournalNodes写数据。在故障切换期间,要变为活动状态的NameNode将简单地接管写入JournalNodes的角色,这将有效地防止其他NameNode继续处于活动状态,允许新的Active安全地进行故障切换。

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

  • JournalNode的作用是在HA的两个NameNode之间保持editlog的共享同步
  • Zookeeper的作用是两个NameNode之间互相的错误感知(active的掉了,standby的可以看见)。

9.1.3 硬件资源

为了部署HA群集,您应该准备以下内容:

  • NameNode机器 - 运行Active和Standby NameNodes的计算机应具有彼此相同的硬件,以及与非HA集群中使用的硬件相同的硬件。
  • JournalNode机器 - 运行JournalNodes的机器。JournalNode守护进程是相对轻量级的,所以这些守护进程可能合理地并置在具有其他Hadoop守护程序的机器上,例如NameNodes,JobTracker或YARN ResourceManager。注意:必须至少有3个JournalNode守护程序,因为编辑日志修改必须写入大多数JN。这将允许系统容忍单个机器的故障。您还可以运行超过3个JournalNodes,但为了实际增加系统可以容忍的故障数量,您应该运行奇数JN(即3,5,7等)。请注意,当使用N JournalNodes运行时,系统最多可以忍受(N-1)/ 2故障,并继续正常工作。

请注意,在HA群集中,Standby NameNode还执行命名空间状态的检查点,因此不需要在HA群集中运行Secondary NameNode,CheckpointNode或BackupNode。其实这样做会是一个错误。这也允许正在重新配置非HA使能的HDFS集群的HA被启用以重新使用它们之前专用于Secondary NameNode的硬件。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2017-07-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第9章 HA高可用
  • 9.1 HDFS 高可用介绍
    • 9.1.1 背景
      • 9.1.2 架构
        • 9.1.3 硬件资源
        相关产品与服务
        大数据
        全栈大数据产品,面向海量数据场景,帮助您 “智理无数,心中有数”!
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档