Hadoop NameNode HA模式的搭建以及原理

搭建HA(高可用)模式的集群参见(http://blog.cheyo.net/92.html)

转自:http://www.it165.net/admin/html/201407/3465.html

社区hadoop2.2.0 release版本开始支持NameNode的HA,本文将详细描述NameNode HA内部的设计与实现。

为什么要Namenode HA?

1. NameNode High Availability即高可用。

2. NameNode 很重要,挂掉会导致存储停止服务,无法进行数据的读写,基于此NameNode的计算(MR,Hive等)也无法完成。

Namenode HA 如何实现,关键技术难题是什么?

1. 如何保持主和备NameNode的状态同步,并让Standby在Active挂掉后迅速提供服务,namenode启动比较耗时,包括加载fsimage和editlog(获取file to block信息),处理所有datanode第一次blockreport(获取block to datanode信息),保持NN的状态同步,需要这两部分信息同步。

2. 脑裂(split-brain),指在一个高可用(HA)系统中,当联系着的两个节点断开联系时,本来为一个整体的系统,分裂为两个独立节点,这时两个节点开始争抢共享资源,结果会导致系统混乱。

3. NameNode切换对外透明,主Namenode切换到另外一台机器时,不应该导致正在连接的客户端失败,主要包括Client,Datanode与NameNode的链接。

社区NN的HA架构,实现原理,各部分的实现机制,解决了哪些问题?

1. 非HA的Namenode架构,一个HDFS集群只存在一个NN,DN只向一个NN汇报,NN的editlog存储在本地目录。

2. 社区NN HA的架构

图1,NN HA架构(从社区复制)

社区的NN HA包括两个NN,主(active)与备(standby),ZKFC,ZK,share editlog。

流程:集群启动后一个NN处于active状态,并提供服务,处理客户端和datanode的请求,并把editlog写到本地和share editlog(可以是NFS,QJM等)中。另外一个NN处于Standby状态,它启动的时候加载fsimage,然后周期性的从share editlog中获取editlog,保持与active的状态同步。为了实现standby在active挂掉后迅速提供服务,需要DN同时向两个NN汇报,使得Stadnby保存block to datanode信息,因为NN启动中最费时的工作是处理所有datanode的blockreport。为了实现热备,增加FailoverController和ZK,FailoverController与ZK通信,通过ZK选主,FailoverController通过RPC让NN转换为active或standby。

2.关键问题:

(1) 保持NN的状态同步,通过standby周期性获取editlog,DN同时想standby发送blockreport。

(2) 防止脑裂

共享存储的fencing,确保只有一个NN能写成功。使用QJM实现fencing,下文叙述原理。

datanode的fencing。确保只有一个NN能命令DN。HDFS-1972中详细描述了DN如何实现fencing

(a) 每个NN改变状态的时候,向DN发送自己的状态和一个序列号。

(b) DN在运行过程中维护此序列号,当failover时,新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回是认为该NN为新的active。

(c) 如果这时原来的active(比如GC)恢复,返回给DN的心跳信息包含active状态和原来的序列号,这时DN就会拒绝这个NN的命令。

(d) 特别需要注意的一点是,上述实现还不够完善,HDFS-1972中还解决了一些有可能导致误删除block的隐患,在failover后,active在DN汇报所有删除报告前不应该删除任何block。

客户端fencing,确保只有一个NN能响应客户端请求。让访问standby nn的客户端直接失败。在RPC层封装了一层,通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN,对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试此时和时间。

ZKFC的设计

1. FailoverController实现下述几个功能

(a) 监控NN的健康状态

(b) 向ZK定期发送心跳,使自己可以被选举。

(c) 当自己被ZK选为主时,active FailoverController通过RPC调用使相应的NN转换为active。

2. 为什么要作为一个deamon进程从NN分离出来

(1) 防止因为NN的GC失败导致心跳受影响。

(2) FailoverController功能的代码应该和应用的分离,提高的容错性。

(3) 使得主备选举成为可插拔式的插件。

图2 FailoverController架构(从社区复制)

3. FailoverController主要包括三个组件,

(1) HealthMonitor 监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成。

(2) ActiveStandbyElector 管理和监控自己在ZK中的状态。

(3) ZKFailoverController 它订阅HealthMonitor 和ActiveStandbyElector 的事件,并管理NameNode的状态。

QJM的设计

Namenode记录了HDFS的目录文件等元数据,客户端每次对文件的增删改等操作,Namenode都会记录一条日志,叫做editlog,而元数据存储在fsimage中。为了保持Stadnby与active的状态一致,standby需要尽量实时获取每条editlog日志,并应用到FsImage中。这时需要一个共享存储,存放editlog,standby能实时获取日志。这有两个关键点需要保证, 共享存储是高可用的,需要防止两个NameNode同时向共享存储写数据导致数据损坏。 是什么,Qurom Journal Manager,基于Paxos(基于消息传递的一致性算法)。这个算法比较难懂,简单的说,Paxos算法是解决分布式环境中如何就某个值达成一致,(一个典型的场景是,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列,需要在每一条指令上执行一个‘一致性算法‘以保证每个节点看到的指令一致)

图3 QJM架构

如何实现,

(1) 初始化后,Active把editlog日志写到2N+1上JN上,每个editlog有一个编号,每次写editlog只要其中大多数JN返回成功(即大于等于N+1)即认定写成功。

(2) Standby定期从JN读取一批editlog,并应用到内存中的FsImage中。

(3) 如何fencing: NameNode每次写Editlog都需要传递一个编号Epoch给JN,JN会对比Epoch,如果比自己保存的Epoch大或相同,则可以写,JN更新自己的Epoch到最新,否则拒绝操作。在切换时,Standby转换为Active时,会把Epoch+1,这样就防止即使之前的NameNode向JN写日志,也会失败。

(4) 写日志:

(a) NN通过RPC向N个JN异步写Editlog,当有N/2+1个写成功,则本次写成功。

(b) 写失败的JN下次不再写,直到调用滚动日志操作,若此时JN恢复正常,则继续向其写日志。

(c) 每条editlog都有一个编号txid,NN写日志要保证txid是连续的,JN在接收写日志时,会检查txid是否与上次连续,否则写失败。

(5) 读日志:

(a) 定期遍历所有JN,获取未消化的editlog,按照txid排序。

(b) 根据txid消化editlog。

(6) 切换时日志恢复机制

(a) 主从切换时触发

(b) 准备恢复(prepareRecovery),standby向JN发送RPC请求,获取txid信息,并对选出最好的JN。

(c) 接受恢复(acceptRecovery),standby向JN发送RPC,JN之间同步Editlog日志。

(d) Finalized日志。即关闭当前editlog输出流时或滚动日志时的操作。

(e) Standby同步editlog到最新

(7) 如何选取最好的JN

(a) 有Finalized的不用in-progress

(b) 多个Finalized的需要判断txid是否相等

(c) 没有Finalized的首先看谁的epoch更大

(d) Epoch一样则选txid大的。

原文地址:https://www.cnblogs.com/jiataoq/p/9712874.html

时间: 2024-10-12 19:57:44

Hadoop NameNode HA模式的搭建以及原理的相关文章

Hadoop在HA模式下远程上传文件的实现

在非HA模式下,只须如下代码就可以轻松实现上传文件,标红的这句是关键 public class CopyToHDFS { public static void main(String[] args) throws IOException { Configuration conf = new Configuration(); conf.set("fs.defaultFS", "hdfs://master:9000"); FileSystem fs = FileSyst

hadoop 的HA集群搭建

1.关闭防火墙 1.1 查看防火墙状态 service iptables status 1.2 关闭防火墙 service iptables off 1.3 关闭防火墙开机启动 chkconfig iptables off 2.关闭selinux vi /etc/selinux/config 将 SELINUX=enforcing 改为 SELINUX=disabled 3.ssh免密登陆 ssh-keygen -t rsa ssh-copy-id hostname 4.解压安装hadoop j

Apache hadoop namenode ha和yarn ha ---HDFS高可用性

HDFS高可用性Hadoop HDFS 的两大问题:NameNode单点:虽然有StandbyNameNode,但是冷备方案,达不到高可用--阶段性的合并edits和fsimage,以缩短集群启动的时间--当NameNode失效的时候,Secondary NN并无法立刻提供服务,Secondary NN甚至无法保证数据完整性--如果NN数据丢失的话,在上一次合并后的文件系统的改动会丢失NameNode扩展性问题:单NameNode元数据不可扩展,是整个HDFS集群的瓶颈 Hadoop HDFS高

HADOOP namenode HA

参考的文章:http://www.cnblogs.com/smartloli/p/4298430.html 当然,在操作的过程中,发现与上述文章中描述的还是有一些小小的区别. 配置好后,start-dfs.sh start-yarn.sh之后,相关的进程,会自动被启动.包括 namenode两个进程,zkfc,journal 等,不需要自己手动启动. 但是standby的namenode的resourcemanager进程没有自动启动. 我遇到的问题: org.apache.hadoop.ipc

HA模式下历史服务器配置

笔者的集群是 HA 模式的( HDFS 和 ResourceManager HA).在 ” Hadoop-2.5.0-cdh5.3.2 HA 安装" 中详细讲解了关于 HA 模式的搭建,这里就不再赘述.但网上直接将关于 HA 模式下的历史服务器的配置资料却很少. 笔者在思考,如果配置在 mapred-site.xml 中就设置一台历史服务器,那么当这台机器挂了,那么能不能有另一台机器来承担历史服务器的责任,也就是笔者理想当然的 jobhistory server HA 模式.后面经过各自尝试,得

HDFS---NameNode管理元数据及HA模式

NameNode主要保存了下面的内容 1-Block和文件之间的关系,即某一个特定文件都有哪些Block: 2-每一个Block存储在什么位置(DataNode上面): NameNode如何保证元数据的可靠性 fsimage 和内存中保存的元数据互为镜像: edits.log中存储了一段时间内所有的元数据操作:edits.log文件大小是固定的(默认是64M),那么每当edits.log文件满了,那么将这段时间之内新产生的元数据加到fsimage中,注意这个过程不是直接在内存中持久化,而是将ed

Hadoop 2.0 NameNode HA和Federation实践

参考链接:Hadoop 2.0 NameNode HA和Federation实践 Posted on 2012/12/10 一.背景 天云趋势在2012年下半年开始为某大型国有银行的历史交易数据备份及查询提供基于Hadoop的技术解决方案,由于行业的特殊性,客户对服务的可用性有着非常高的要求,而HDFS长久以来都被单点故障的问题所困扰,直到Apache Hadoop在2012年5月发布了2.0的alpha版本,其中MRv2还很不成熟,可HDFS的新功能已经基本可用,尤其是其中的的High Ava

HDFS Federation和NameNode HA的搭建

1. HDFS Federation产生背景 在Hadoop 1.0中,HDFS的单NameNode设计带来诸多问题,包括单点故障.内存受限制约集群扩展性和缺乏隔离机制(不同业务使用同一个NameNode导致业务相互影响)等,为了解决这些问题,Hadoop 2.0引入了基于共享存储的HA解决方案和HDFS Federation,这里重点介绍HDFS Federation. HDFS Federation是指HDFS集群可同时存在多个NameNode,这些NameNode分别管理一部分数据,且共享

基于Docker的Zookeeper+Hadoop(HA)+hbase(HA)搭建

公司要将监控数据存入opentsdb,而opentsdb使用了hbase作为存储.所以想搭建一套高可用的分布式存储来供opentsdb使用. 因为机器有限,所以测试过程中将三台集群的环境安装在docker上. 一:宿主机版本和docker版本 宿主机:Centos7.2  3.10.0-862.14.4.el7.x86_64 docker:Docker version 1.13.1, build 94f4240/1.13.1 二:镜像版本 docker.io/centos 三:创建docker镜