Hadoop的HA

1,Hadoop的HA是什么

        从Hadoop2开始,可以允许有2个NameNode,一个是active(活跃状态),另一个是standby(待命状态),其中active状态的NameNode对外提供服务,Hadoop1没有此特性.

2,Hadoop的HA带来的好处

在Hadoop1里面只能有一个NameNode,带来的灾难就是单点故障( single point of failure (SPOF)),每个集群只有一个NameNode,如果计算机或者进程不可用,则整个集群不可用,直到NameNode重新启动或者在单独的计算机.

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

在发生意外事件(如机器崩溃)的情况下,集群将不可用,直到技术人员把NameNode重新启动之后.

如果NameNode对应的计算机节点需要进行硬件或者软件的升级,就需要停止NameNode服务,这又会导致集群宕机.

Hadoop的HA就可以允许在计算机崩溃的情况下,快速切换到新的NameNode,或者允许处于计划维护NameNode有运维人员直接切换到standby服务器上面

                                                                               -------以上取自hadoop.apache.org官网解答

3,HA的两种模式

HA的架构模式其实是有两种,HDFS High Availability Using the Quorum Journal Manager(企业级开发专用)和NFS for the shared storage 共享编辑日志模式(基本上不用)

共享编辑日志模式-您将需要有一个共享目录,两台NameNode机器都可以对其进行读/写访问。通常,这是一个支持NFS的远程文件管理器,并安装在每个NameNode计算机上。当前仅支持一个共享的edits目录。因此,系统的可用性受到此共享编辑目录的可用性的限制,因此,为了消除所有单点故障,共享编辑目录需要冗余。具体来说,有到存储的多个网络路径,以及存储本身的冗余(磁盘,网络和电源)。因此,建议共享存储服务器是高质量的专用NAS设备,而不是简单的Linux服务器。

                                                                                -------以上取自hadoop.apache.org官网解答         

所有企业开发里面目前还没遇到过使用这种模式的.下面详细介绍QJM模式

4,QJM模式硬件资源

为了部署高可用性群集,您应该准备以下内容:

NameNode计算机-运行活动NameNode和Standby NameNode的计算机应具有彼此等效的硬件,以及与非HA群集中将使用的硬件相同的硬件。

JournalNode计算机-运行JournalNode的计算机。JournalNode守护程序相对较轻,因此可以合理地将这些守护程序与其他Hadoop守护程序(例如NameNode,JobTracker或YARN ResourceManager)并置在计算机上。注意:必须至少有3个JournalNode守护程序,因为必须将编辑日志修改写入大多数JN。这将允许系统容忍单个计算机的故障。您可能还会运行3个以上的JournalNode,但是为了实际增加系统可以容忍的故障数量,您应该运行奇数个JN(即3、5、7等)。请注意,当与N个JournalNode一起运行时,系统最多可以容忍(N-1)/ 2个故障,并继续正常运行。

                                                                                -------以上取自hadoop.apache.org官网解答 

这里解释一下,JournalNode上面之所以建议是奇数台,是因为HDFS底层算法他是(N-1)/2的故障,假如是偶数台,4台,(4-1)/2=1,也就是1台挂了,就会导致所有的JournalNode都不能正常运行,但是其实我只挂了一台而已,另外三台完全可以支撑完运行,如果是奇数3台的话,(3-1)/2=1台,挂了一台,还剩下两台,这时候就不能正常运行,但是,再挂一台是不是就超过了过半性原则,这个奇数过半性原理在整个Hadoop中使用很广泛

5,QJM模式架构图


HA的QLM模式架构图

以三台服务器为例:

dachun001:zookeeper    nn(NameNode)    zkfc(ZookeeperFailoverControl)       JournalNode  dn(DataNode)

dachun002:zookeeper    nn(NameNode)    zkfc(ZookeeperFailoverControl)       JournalNode  dn(DataNode)

dachun003:zookeeper                                  zkfc(ZookeeperFailoverControl)       JournalNode  dn(DataNode)

每个进程的作用:

active NameNode:

接收client的rpc请求,同时自己的editlog写一条日志记录,同时发送给JournalNode日志集群写一条记录,同时接收DataNode的心跳和块报告

standby NameNode:

同时接收JournalNode日志集群的的记录,在自己本身执行,使得自己的元数据和active NameNode是一致的,这步叫做重演

同时也接受DataNode的心跳报告(这个是为了在进行从standby演变到active状态时候更加平滑)

也随时等待从standby-->active状态,对外提供服务。

JournalNode:

JouralNode守护进程相当的轻量级,可以和Hadoop的其他进程部署在一起

active NameNode -->  standby  NameNode的同步数据进程.

datanode: 

同时向两个nn发送 心跳 and 块报告

 zkfc(ZookeeperFailoverControl)进程:

监控NameNode的健康状态,可以理解为NameNode和zookeeper的桥梁,standby-active或者active-standby是通过zkfc进程  

NameNode通过zkfc向zookeeper集群定期发送心跳,使得自己被选举上,

当被zookeeperk集群选举为active时,

zkfc进程通过rpc调用NameNode状态变为active。


在典型的HA群集中,将两个单独的计算机配置为NameNode。在任何时间点,恰好其中一个NameNode处于活动状态,而另一个处于Standby状态。Active NameNode负责群集中的所有客户端操作,而Standby只是充当从属,并保持足够的状态以在必要时提供快速故障转移。

为了使Standby节点保持其状态与Active节点同步,两个节点都与称为“ JournalNodes”(JN)的一组单独的守护程序进行通信。当活动节点执行任何名称空间修改时,它会持久地将修改记录记录到这些JN的大多数中。Standby节点能够从JN读取编辑内容,并不断监视它们以查看编辑日志的更改。当“备用节点”看到编辑内容时,会将其应用到自己的名称空间。发生故障转移时,备用服务器将确保在将自身升级为活动状态之前,已从JournalNode读取所有编辑内容。这样可确保在发生故障转移之前,名称空间状态已完全同步。

为了提供快速故障转移,备用节点还必须具有有关集群中块位置的最新信息。为了实现这一点,DataNode被配置了两个NameNode的位置,并向两者发送块位置信息和心跳。

对于HA群集的正确操作至关重要,一次只能有一个NameNode处于活动状态。否则,名称空间状态将在两者之间迅速分散,从而有数据丢失或其他不正确结果的风险。为了确保此属性并防止所谓的“裂脑情况”,JournalNode将仅一次允许一个NameNode成为作者。在故障转移期间,将变为活动状态的NameNode将仅承担写入JournalNodes的角色,这将有效地防止另一个NameNode继续处于活动状态,从而使新的Active可以安全地进行故障转移。


Yarn的HA


yarn的HA相对于HDFS的HA就没有这么复杂,他的NM(NodeManager)只会向active的RM(ResourceManager)发送心跳信息,

zkfc是和ResourceManager在同一个进程中,即ZKFC是一个线程ResourceManager进程中,如果这个ResourceManager进程挂了,这个ZKFC线程就挂了

RM(ReourceManager)进程:

a.启动时会向zk(zookeeper)集群的hadoop-ha目录写个lock文件,

写成功就标识为active,否则为standby。

standby rm(ResourceManager)会一直监控lock文件是否存在,如果不存在就尝试去创建,争取为active。

b.会接收client客户端的请求,接收和监控nm的资源汇报,

负责资源的分配和调度,启动和监控application master。

rmstore:

a.rm的作业信息是存储在zk(zookeeper)的/rmstore,

active rm会向这个目录写作业app信息。

b.当active rm挂了,另外一个standby rm成功转为active状态,

就会从这里读取对应的作业的信息,

重新构建作业的内存信息,启动内部服务,

开始接收NM(NodeManager)心跳,构建集群资源信息,且开始接收客户端提交的作业的请求。

hdfs的HA和yarn的HA区别

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,015评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,262评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,727评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,986评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,363评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,610评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,871评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,582评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,297评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,551评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,053评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,385评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,035评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,079评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,841评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,648评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,550评论 2 270

推荐阅读更多精彩内容