一、HA部署架构

如上图所示,我们可以将其分为三个部分:

1.NN和DN组成Hadoop业务组件。浅绿色部分。

2.中间深蓝色部分,为Journal Node,其为一个集群,用于提供高可用的共享文件存储(元数据存储)。

3.蓝色部分为Zookeeper,提供自动NN切换。

hadoop全分布式安装 中,我们已经部署了一套全分布式的Hadoop集群,包含1个NN和3个DN。

我们在全分布式的基础上将其中一个DN(安装SNN的节点)变为SBNN(备用NN)。

在全分布式中,存在一个SNN(secondary Node),那是Hadoop 1.x中采用的技术。在hadoop 2.x中,使用SBNN(standby Namenode)来完成SNN的功能,并提供HA 备用。

各部分组件工作原理介绍:

1.NN之间的元数据同步:

  1)多个NN之间要同步的元数据分为两种,静态数据和动态数据。静态数据指HDFS上存放文件的权限、偏移量等信息,动态数据指这些文件存放的块的信息。

  2)静态信息由NN直接持久化到磁盘,而动态数据是由DN向上汇报的。

  3)动态数据的同步,无需多个NN之间传递数据,只需要DN同时向多个NN汇报数据即可。

  4)静态数据则可以通过JN集群或NFS(已淘汰,存在单点故障)来实现。

2.Journal Node:

    1)JN节点组成的集群,用于存放多个NN之间共享的元数据,功能类似于我们在全分布式部署时指定的/var/hadoop文件夹。

  2)当主NN挂掉时,SBNN可以从JN集群中同步元数据。JN集群提供高可用,保证元数据的安全性和一致性。

  3)JN集群的节点数量一般为单数,使用过半机制,例如3个节点的集群可以允许一台宕机,5个节点的集群可以允许两台宕机。如果是偶数(一般不用偶数),6个节点的集群,也只能允许两台宕机。

3.Zookeeper:

  1)每一个NN上存在一个Failover Controller进程(简称ZKFC),即图中蓝色椭圆部分。

  2)Zookeeper提供选举机制,所有的NN通过ZKFC进程向Zookeeper申请成为主节点,即注册,谁注册成功,谁就是主节点,其余的为备用节点。

  3)注册成功的NN会在Zookeeper上产生一个znode节点,节点之下是该NN的信息,我们可以把Zookeeper看成一个小型的数据库。

  4)Zookeeper除了提供注册功能(register),还提供事件监控功能(event)。这里的事件是指NN是否出现故障,由处于NN节点上得ZKFC进程来监听,ZKFC提供健康监控和选举功能。当ZKFC发现NN出现故障,则马山通知Zeekeeper。

  5)Zookeeper知道主节点挂掉后,则会通知SBNN节点(其实是SBNN委托Zookeeper来监控主节点)。

  6)SBNN收到通知后,会将自己的级别从备提升为Active(这里实际上是一个由Zookeeper发起的回调,回调的是客户端的函数,这里的客户端就是ZKFC)。

  7)当SBNN变成ANN后,他会强制性的将前任ANN的Active状态进行变更。避免形成Split brain(脑裂)情况出现。

二、部署时要注意的点(写在前面)

1.由于两个NN之间要互相操作(例如SBNN在NN出现问题的使用要操作NN,杀掉相应进程),所以两台NN之间需要相互做免秘钥登录。

2.在配置好Hadoop后,格式化HDFS之前,要先启动 Journal Nodes

三、节点规划

我们对节点所要担任的角色进行规划:

  NN-1 NN-2 DN ZK ZKFC JNN
Node01 *       * *
Node02   * * * * *
Node03     * *   *
Node04     * *    

1)NN-1和NN-2表示两个NameNode。

2)ZK集群有3个节点,分别在node02-04。

3)ZKFC一定是对应NameNode的。

4)JNN集群的三个节点分别在node01-03。

四、Hadoop HA配置流程及解释

参照官方文档:

https://hadoop.apache.org/docs/r2.6.5/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

即基于QJM的HA环境搭建,另一种方式基于NFS(不推荐)。

1.NN之间免秘钥操作

# node01上操作
ssh-keygen -t rsa
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node02
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node03
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node04
# node02上操作
ssh-keygen -t rsa
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node01
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node03
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node04

2.配置hdfs-site.xml

参照官方文档中 Deployment 小节的 Configuration details部分:

先在hdfs-site.xml中为HA的多个NN节点定义一个逻辑名称,来代表这一组NN,这里叫mycluster:

<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>

然后定义这里HA有哪些NN节点:

<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>

定义nn1和nn2的确切节点名(这里的nn1要与前面对应,可修改为自己想要的名称):

<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>node01:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>node02:8020</value>
</property>

注意:这里的端口号默认是8020,在前面我们部署的单节点情况下,使用的是9000端口。

定义http的访问端口,即提供WEB访问服务的端口号(这里同单节点一样,使用50070端口):

<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>node01:50070</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>node02:50070</value>
</property>

定义JNN节点的edits.dir:

<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://node01:8485;node02:8485;node03:8485/mycluster</value>
</property>

注意:这里的格式要正确,只需要修改JN所处的实际节点,端口是8485,最后的mycluster是我们的HA逻辑ID,但可以不与HA逻辑名相同,主要是用于区分多个HA集群共用一个JNN的情况。

指定NN进行故障转移时,使用的代理类(这里照着官方网站配就行):

<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

定义SBNN在要接替前任ANN时,如何来隔离前任ANN(可能是登录前任ANN来杀掉进程),从而保证只有一个Active节点来写JNN,避免Split brain的发生:

这里采用ssh的方式来隔离:

<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property> <property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/root/.ssh/id_rsa</value>
</property>

注意:这里使用的是私钥,需要将id_rsa的绝对路径配置进去。(秘钥有rsa和dsa两种,都可以)

定义JN的edits存放位置(前面配置的dfs.namenode.shared.edits.dir只是指定了JNN的节点位置):

<property>
<name>dfs.journalnode.edits.dir</name>
<value>/var/hadoop/ha/journalnode</value>
</property>

3.配置core-site.xml

在配置完hdfs-site.xml后,已经定义了逻辑名、包含节点、服务端口等信息。此时,要在core-site.xml中配置对应的信息。

<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>

注意:我们之前在部署单NN节点时,这里使用的是hdfs://node01:9000,这里需要修改成HA集群的逻辑ID。

定义数据的存储位置:

<property>
<name>hadoop.tmp.dir</name>
<value>/var/hadoop/ha</value>
</property>

注意:将全分布式的/var/hadoop/full修改为/var/hadoop/ha;

4.启动JNN集群(重要)

修改完Hadoop的配置文件,在格式化HDFS之前,需要首先启动JNN集群,否则edits文件没有地方存储,则无法启动Hadoop。

[大数据] hadoop高可用(HA)部署(未完)的更多相关文章

  1. Hadoop 高可用(HA)的自动容灾配置

    参考链接 Hadoop 完全分布式安装 ZooKeeper 集群的安装部署 0. 说明 在 Hadoop 完全分布式安装 & ZooKeeper 集群的安装部署的基础之上进行 Hadoop 高 ...

  2. 大数据入门第十天——hadoop高可用HA

    一.HA概述 1.引言 正式引入HA机制是从hadoop2.0开始,之前的版本中没有HA机制 2.运行机制 实现高可用最关键的是消除单点故障 hadoop-ha严格来说应该分成各个组件的HA机制——H ...

  3. 大数据(3) - 高可用 HDFS HA

    HDFS HA高可用 1 HA概述 1)所谓HA(high available),即高可用(7*24小时不中断服务). 2)实现高可用最关键的策略是消除单点故障.HA严格来说应该分成各个组件的HA机制 ...

  4. hadoop高可用HA的配置

    zk3 zk4 zk5 配置hadoop的HA大概可以分为以下几步: 配置zookpeer(namenode之间的通信要靠zk来实现) 配置hadoop的 hadoop-env.sh hdfs-sit ...

  5. 【Hadoop】2、Hadoop高可用集群部署

    1.服务器设置 集群规划 Namenode-Hadoop管理节点 10.25.24.92 10.25.24.93 Datanode-Hadoop数据存储节点 10.25.24.89 10.25.24. ...

  6. hadoop在zookeeper上的高可用HA

    (参考文章:https://www.linuxprobe.com/hadoop-high-available.html) 一.技术背景 影响HDFS集群不可用主要包括以下两种情况:一是NameNode ...

  7. hadoop学习笔记(七):hadoop2.x的高可用HA(high avaliable)和联邦F(Federation)

    Hadoop介绍——HA与联邦 0.1682019.06.04 13:30:55字数 820阅读 138 Hadoop 1.0中HDFS和MapReduce在高可用.扩展性等方面存在问题: –HDFS ...

  8. 使用kubeadm进行单master(single master)和高可用(HA)kubernetes集群部署

    kubeadm部署k8s 使用kubeadm进行k8s的部署主要分为以下几个步骤: 环境预装: 主要安装docker.kubeadm等相关工具. 集群部署: 集群部署分为single master(单 ...

  9. 基于 ZooKeeper 搭建 Hadoop 高可用集群

    一.高可用简介 二.集群规划 三.前置条件 四.集群配置 五.启动集群 六.查看集群 七.集群的二次启动 一.高可用简介 Hadoop 高可用 (High Availability) 分为 HDFS ...

随机推荐

  1. BUUOJ misc 金三胖

    可以看到是有三帧的内容有flag的 直接 convert aaa.gif .png 逐帧分解,得到: flag{he11ohongke} (kali真好用呀)

  2. LCA模板(数剖实现)

    题目链接:https://www.luogu.org/problemnew/show/P3379 题意:LCA模板题. 思路:今天开始学树剖,先拿lca练练.树剖解lca,两次dfs复杂度均为O(n) ...

  3. CNN中feature map、卷积核、卷积核的个数、filter、channel的概念解释

    CNN中feature map.卷积核.卷积核的个数.filter.channel的概念解释 参考链接: https://blog.csdn.net/xys430381_1/article/detai ...

  4. ARM Cortex-M 系列 MCU 错误追踪库 心得

    一. 感谢CmBacktrace开源项目,git项目网站:https://github.com/armink/CmBacktrace 二. 移植CmBacktrace 2.1 准备好CmBacktra ...

  5. codeforces 816B Karen and Coffee (差分思想)

    题目链接 816B Karen and Coffee 题目分析 题意:有个人在学泡咖啡,因此看了很多关于泡咖啡温度的书,得到了n种推荐的泡咖啡温度范围[L1,R1] ,此人将有k种做法推荐的温度记为可 ...

  6. MyISAM与InnoDB的索引差异

    数据库的索引分为主键索引(Primary Index)与普通索引(Secondary Index).InnoDB和MyISAM是怎么利用B+树来实现这两类索引的,又有什么差异呢?一.MyISAM的索引 ...

  7. redis 学习(11)-- redis pipeline

    redis pipeline 什么是流水线(pipeline) 首先来看 redis 执行一次操作所需要的时间: 1 次时间 = 1 次网络时间 + 1次命令时间 执行 n 次就需要: n 次时间 = ...

  8. O018、理解 Keystone 核心概念

    参考https://www.cnblogs.com/CloudMan6/p/5365474.html   作为OpenStack的基础支持服务,Keystone做了下面几件事情:       1.管理 ...

  9. 精通shell编程--最后的总结

    不得不说shell语法是丑陋的,操作是简单高效的,最后一次学习总结shell shell总结 字符串删除与替换等常见操作 ## 字符串长度 a=1234 echo "${#a}" ...

  10. SpringMVC基础03——常用注解之@RequestMapping

    1.用法 SpringMVC使用@RequestMapping注解,为控制器指定可以处理哪些URL请求,并且可以指定处理请求的类型(POST/GET),如果@RequestMapping没有指定请求的 ...