日志

Hadoop NameNode 高可用架构

NameNode是HDFS(hadoop分布式文件系统)的核心组件,在hadoop 1.x中NameNode存在SPOF(单点故障)问题,NameNode存储了HDFS的元数据信息,一旦NameNode宕机那么整个HDFS就无法访问,依赖HDFS的服务也会被波及(HBase、Hive…)同样无法访问,整个集群陷入瘫痪。NameNode的单点故障问题也使得Hadoop在1.x时代一直都只能用作离线存储和离线计算,无法满足对高可用要求很高的应用场景。Hadoop2.x针对NameNode的SPOF问题提出了高可用架构方案(HA),目前已经能在生产环境下应用。本文主要介绍该高可用架构的主备切换机制。

一、NameNode高可用架构

Hadoop NameNode高可用架构

Hadoop NameNode高可用架构

二、组件概述

Active NameNode 与 Standby NameNode

在NameNode的HA方案中有两个不同状态的NameNode,分别为活跃态(Active)和后备态(Standby),其中只有Active NameNode能对外提供服务,Standby NameNode会根据Active NameNode的状态变化,在必要时可切换成Active.

ZKFC

ZKFC即ZKFailoverController,是基于Zookeeper的故障转移控制器,它负责控制NameNode的主备切换,ZKFC会监测NameNode的健康状态,当发现Active NameNode出现异常时会通过Zookeeper进行一次新的选举,完成Active和Standby状态的切换

HealthMonitor

阅读全文

日志

Hadoop之YARN/MRv2

YARN又称为Mapreduce version 2(MRv2)是hadoop2.x的新架构,它将旧Hadoop Mapreduce框架中的JobTracker的资源管理和作业生命周期管理拆分成两个组件即ResourceManager(RM)和ApplicationMaster(AM)

一、为何需要MRv2?

mr1vsmr2

MRv1与MRv2对比

MRv1资源管理问题

  1. Hadoop1.0引入了“slot”的概念,每个slot代表了各个节点上的一份资源(CPU、内存等),MRv1把Map和Reduce的资源单独区分,即Map slot、Reduce slot,两个阶段的slot不能共享,这意味着资源的利用率大大降低
  2. 非MR应用不能分享资源,所以只能运行MR计算框架的应用
  3. 每个集群只有一个JobTracker,限制了集群的扩展,集群规模限制在4000个节点左右

MRv2资源管理方案

  1. 舍弃“slot”的概念,每个节点以“资源”(CPU、内存等)为单位分配给有需要的应用
  2. 支持运行MR应用和非MR应用
  3. JobTracker的大量功能被迁移到ApplicationMaster(AM),集群内可以存在多个AM(每个应用程序都拥有一个独立的AM),集群可以扩展到上万个节点

二、YARN架构

YARN_Architecture

YARN架构图(via Apache Hadoop)

资源管理器(ResourceManager,RM)

ResourceManager运行在主节点(Master)上,负责全局资源调度(分配/回收),处理各个应用的资源请求,ResourceManager由调度器(Scheduler)和应用管理器(ApplicationsManager, AsM)组成

  • 调度器(Scheduler)
    调度器根据资源调度策略(例如Capacity Scheduler、Fair Scheduler),将包含适当资源(CPU、内存等)的资源容器(Container)分配给相应的节点,应用程序的各个任务均在容器内执行,且只能使用容器分配到的资源.调度器只负责资源调度,不关心应用的执行状态.
    阅读全文
日志

Hadoop之HDFS(NameNode、DataNode、SecondaryNameNode)

HDFS(hadoop分布式文件系统)是Hadoop的核心组成部分,HDFS采用master/slave架构,一个HDFS集群由一个NameNode(不考虑HA/Federation)和多个DataNode组成

hdfs架构

HDFS架构图(via Apache Hadoop)

一、NameNode

  • NameNode是HDFS的中心,也称作Master
  • NameNode只保存HDFS的元数据,负责管理HDFS的命名空间(namespace)和控制文件的访问操作
  • NameNode不保存任何实际的数据或数据集,真正的数据由DataNode负责存储
  • NameNode拥有HDFS内所有文件的数据块(blocks)列表及其位置,因而NameNode能通过这些数据块信息来重构对应的文件
  • NameNode是HDFS的核心,一旦NameNode挂了,整个集群将无法访问
  • NameNode具有单点故障问题(Hadoop2之后可以通过High Available方案解决)
  • NameNode需要配置相对较多的内存(相比DataNode而言),因为NameNode会把HDFS的命名空间和文件数据块映射(Blockmap)保存在内存中,这也意味着集群的横向扩展受到NameNode的限制,因为集群增长到一定的规模后NameNode需要的内存也会更大,另外由于所有的元数据操作都需要通过NameNode进行,这意味着集群的性能受到NameNode的限制(Hadoop2之后可以通过Federation方案解决)
  • NameNode有两个核心的数据结构,FsImage和EditsLog,FsImage是HDFS命名空间、文件数据块映射、文件属性等信息的镜像,EditsLog相当于一个日志文件,它记录了对HDFS元数据进行修改的所有事务操作,当NameNode启动时会首先合并FsImage和EditsLog,得到HDFS的最新状态然后写入FsImage镜像文件中,并使用一个新的EditsLog文件进行记录

SecondaryNameNode

“SecondaryNamenode”这个名字具有误导性,它不能和DataNode交互,更不能替代NameNode,相反它是用来弥补NameNode的一些缺点,由于NameNode启动时会合并FsImage和EditsLog,但随着集群的运行时间变长,EditsLog会变得非常庞大,这意味着下一次启动需要花很长的时间来进行合并操作.

SecondaryNameNode负责解决以上的问题
阅读全文