HDFS HA 架构

HA背景

对于HDFS、YARN的每个角色都是一个进程,

比如HDFS:NN/SNN/DN   老大是NN

YARN:RM/NM   老大是RM

对于上面,都会存在单点故障的问题,假如老大NN或者RM挂了,那么就不能提供对外服务了,会导致整个集群都不能使用。

大数据几乎所有的组建都是主从架构(master-slave)。比如hdfs的读写请求都是先经过NN节点。(但是hbase的读写请求不是经过老大的master)。

hdfs:由NN/SNN/DN组成,SNN每小时会做一次checkpoint的操作,如果NN挂了,只能恢复到上次checkpoint的那一刻,不能实时。现在如果把SNN的角色再提升一个等级,让它和NN一样,如果NN挂了,SNN能立即切换过来就好了。

HDFS HA 架构 有两个NN节点,一个是active活跃状态,一个是standby准备状态,Active NameNode对外提供服务,比如处理来自客户端的RPC请求,而Standby NameNode则不对外提供服务,仅同步Active NameNode的状态,对Active NameNode进行实时备份,以便能够在它失败时快速进行切换。

HA介绍

HDFS High Availability (HA) 

假定:

NN1 active       ip1
NN2 standby    ip2

假如说在我们代码或者shell脚本里,写了:hdfs dfs -ls hdfs://ip1:9000/   ,那么如果NN1挂了,NN2切换到active状态了,但是在脚本里还是ip1,这个时候不可能手动去修改。肯定有问题。那么该怎么解决?

用命名空间来解决。命名空间不是进程。比如:命名空间的名称为:RUOZEG6

脚本里可以这样写:hdfs dfs -ls hdfs://RUOZEG6/

当代码执行到这一行时,它会去core-site.xml、hdfs-site.xml里面查找。在这两个配置文件里面,配置了RUOZEG6命名空间下挂了NN1和NN2。当它找到NN1,它会尝试着连接第一个机器NN1,如果发现它不是active状态,它会尝试着连接第二个机器NN2,如果发现NN1是active状态,就直接用了。

 

 

HA 进程:(假定我们现在有三台机器)

hadoop001:ZK    NN  ZKFC  JN    DN
hadoop002:ZK    NN  ZKFC  JN    DN
hadoop003:ZK                       JN    DN

NN节点有fsimage、editlog(读和写请求的记录)两个文件,有专门的进程去管理的,这个进程是JN(journalnode)日志节点,要保证NN1和NN2能实时同步,需要JN这个角色。

如果NN1挂了,需要把NN2从standby状态切换到active状态,那它是怎么切换的呢?需要ZKFC。

ZKFC: 是单独的进程,它监控NN健康状态,向zk集群定期发送心跳,使得自己可以被选举;当自己被zk选举为active的时候,zkfc进程通过RPC协议调用使NN节点的状态变为active。对外提供实时服务,是无感知的。

所以在上面,需要在三台机器上都部署一下zookeeper,作为一个集群,ZK集群,是用于做选举的。选举谁来做老大(active),谁做standby。集群中ZK的个数是2n+1,这样能投票保证最后有一个胜出。

生产上zookeeper部署的个数经验:如果集群中有20台节点,那么可以在5台上部署zk。如果总共有七八台,也部署5台zk。如果总共有20~100台节点,可以部署7台/9台/11台 zk。如果大于100台,可以部署11台zk。如果有很多,比如上万台那看情况可以多部署几台。但是,不是说zk节点越多越好因为做投票选举动作的时候,投票谁做active,谁做standby是需要时间的,时间间隔太长会影响对外服务,对外服务会很慢,对于即时性服务来说,这是不允许的

对于大公司比如BAT公司,他们的集群有很多台,比如几百台几千台,zk部署的机器上就它一个进程,不部署其它进程了。在这里是学习或者机器很少,所以一台机器上部署多个进程。如果几百台节点,任务很重,如果部署zk的机器上有其它进程,那么它会消耗很多机器上的资源(无外乎cpu、内存、文件数、进程数),这都会影响zk响应的速度,所以一般都会把它独立出来。但是如果机器是256G内存,但是zk只用到32G,那其他的就浪费了,那么买机器的时候,可以单独给zk买32G内存的机器就可以了。

zk是最底层的,如果zk太繁忙,就可能导致standby状态不能切换到active状态,这个时候机器可能就会夯住。所以当机器夯住,standby不能切换到active的时候,有可能就是zk出问题了。

HDFS HA 架构图

官网:

翻译:

一个典型的HA集群,NameNode会被配置在两台独立的机器上,在任何时间上,一个NameNode处于活动状态,而另一个NameNode处于备份状态,活动状态的NameNode会响应集群中所有的客户端,备份状态的NameNode只是作为一个副本,保证在必要的时候提供一个快速的转移。

为了让Standby Node与Active Node保持同步,这两个Node都与一组称为JNS的互相独立的进程保持通信(Journal Nodes)。当Active Node上更新了namespace,它将记录修改日志发送给JNS的多数派。Standby noes将会从JNS中读取这些edits,并持续关注它们对日志的变更。Standby Node将日志变更应用在自己的namespace中,当failover发生时,Standby将会在提升自己为Active之前,确保能够从JNS中读取所有的edits,即在failover发生之前Standy持有的namespace应该与Active保持完全同步。

为了支持快速failover,Standby node持有集群中blocks的最新位置是非常必要的。为了达到这一目的,DataNodes上需要同时配置这两个Namenode的地址,同时和它们都建立心跳链接,并把block位置发送给它们。

任何时刻,只有一个Active NameNode是非常重要的,否则将会导致集群操作的混乱,那么两个NameNode将会分别有两种不同的数据状态,可能会导致数据丢失,或者状态异常,这种情况通常称为“split-brain”(脑裂,三节点通讯阻断,即集群中不同的Datanodes却看到了两个Active NameNodes)。对于JNS而言,任何时候只允许一个NameNode作为writer;在failover期间,原来的Standby Node将会接管Active的所有职能,并负责向JNS写入日志记录,这就阻止了其他NameNode基于处于Active状态的问题。

 

首先要部署三台zk,然后要两台NN节点,然后三台DN节点。两个NN节点之间的编辑日志需要jn来维护,做共享数据存储。

journalnode(jn): 部署多少合适?取决于HDFS请求量及数据量,比如说BT级的数据量,或者小文件很多,读写请求很频繁,那么journalnode就部署多一点,如果HDFS很悠闲,那就部署少一点,比如7个、9个这样,可以大致和zk部署的保持一致(见上面)。具体要看实际情况。(也是2n+1,可以看官网上介绍)

每个DataNode节点要向两个NameNode都发送心跳报告。(面试,为什么)

在这里ZKFC是进程,(但是在yarn ha 里,zkfc是线程)

进程:ps -ef 看到的就是进程,是由1个以上的线程组成。

线程:线程是进程的一部分

ZKFC:zookeeperfailovercontrol

客户端或者程序代码在提交的时候,去namespace找,找NN节点,如果第一次找的NN节点就是active,那么就用这个节点,如果发现它是standby,就到另外一台机器。

比如说客户端现在执行put、get、ls、cat命令,这些操作命令的记录,active NN节点会写到自己的edit log日志里面。这些操作记录,NN自己会写一份,同时,它会把这些操作记录,写给journalnode的node集群。

而另外的,standby NN节点,会实时的读journalnode的node集群,读了之后会把这些记录应用到自己的本身。这个大数据的专业名词叫做:重演。 相当于standby NN节点把active NN节点的active状态的操作记录在自己身上重演一遍。

journalnode:它是一个集群,就是用于active NN节点和standby NN节点之间同步数据的。它是单独的进程。

NN和ZKFC在同一台机器上面。

整个过程描述:当通过client端提交请求的时候,无论读和写,我们是通过命名空间RUOZEG6,去找谁是active状态,找到了就在那台机器上面,提交请求,然后就是HDFS的读写流程,读和写的操作记录,edit log,它自己会写一份,同时会把读写请求的操作记录,写一份到journalnode集群日志,进行同步之后,另外一个节点,standby 节点会把它拿过来实时的应用到自己的本身。专业的名称叫重演。同时每个DataNode会向NameNode节点发送心跳的块报告(心跳的间隔时间3600s,就是1小时,参数是什么(面试))。当active NN节点挂了,通过zk集群选举(它存储了NN节点的状态),通知ZKFC,把standby NN节点切换到active状态。ZKFC会定期的发送心跳。

ps:

HA是为了解决单点故障问题。

通过journalnode集群共享状态,也就是共享hdfs读和写的操作记录。

通过ZKFC集群选举谁是active。

监控状态,自动备援。

DN: 同时向NN1 NN2发送心跳和块报告。
ACTIVE NN: 读写的操作记录写到自己的editlog
                     同时写一份到JN集群
                     接收DN的心跳和块报告
STANDBY NN: 同时接收JN集群的日志,显示读取执行log操作(重演),使得自己的元数据和active nn节点保持一致。
                        接收DN的心跳和块报告

JounalNode: 用于active nn和 standby nn节点的数据同步, 一般部署2n+1

ZKFC: 单独的进程
           监控NN监控健康状态
           向zk集群定期发送心跳,使得自己可以被选举;
           当自己被zk选举为active的时候,zkfc进程通过RPC协议调用使NN节点的状态变为active,只有是
active状态才能对外提供服务。
           对外提供实时服务,是无感知的,用户是感觉不到的。

 

 

 

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值