hadoopha（hadoop好友推荐）

by intanet.cn ca 大数据 on 2024-03-18

本篇文章给大家谈谈hadoopha，以及hadoop好友推荐对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

1、Hadoop的HA
2、请教hadoop2.0的ha如何配置
3、Hadoop HA 高可用原理及部署
4、hadoop的ha模式出现的原因

Hadoop的HA

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

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

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

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

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

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

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

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

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

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

所有企业开发里面目前还没遇到过使用这种模式的.下面详细介绍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中使用很广泛

以三台服务器为例:

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相对于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)心跳，构建集群资源信息，且开始接收客户端提交的作业的请求。

请教hadoop2.0的ha如何配置

1 Hadoop HA架构详解

1.1 HDFS HA背景

HDFS集群中NameNode 存在单点故障（SPOF）。对于只有一个NameNode的集群，如果NameNode机器出现意外情况，将导致整个集群无法使用，直到NameNode 重新启动。

影响HDFS集群不可用主要包括以下两种情况：一是NameNode机器宕机，将导致集群不可用，重启NameNode之后才可使用；二是计划内的NameNode节点软件或硬件升级，导致集群在短时间内不可用。

为了解决上述问题，Hadoop给出了HDFS的高可用HA方案：HDFS通常由两个NameNode组成，一个处于active状态，另一个处于standby状态。Active NameNode对外提供服务，比如处理来自客户端的RPC请求，而Standby NameNode则不对外物念提供服务，仅同步Active NameNode的状态，以便能够在它失败时快速进行切换。

1.2 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状态的问题。

基于QJM的HDFS HA方案如上图所示，其处理流程为：集群启动后一个NameNode处于Active状态，并提供服务，处理客户端和DataNode的请求，并把editlog写到本地和share editlog（这里是QJM）中。另外一个NameNode处于Standby状态，它启动的时候加载fsimage，然后周期性的从share editlog中获取editlog，保持与Active节点的状态同步。为了实现Standby在Active挂掉后迅速提供服务，需要DataNode同时向两个NameNode汇报，使得Stadnby保存block to DataNode信息，因为NameNode启动中最费时的工作是处理所有DataNode的blockreport。为了实现热备，增加FailoverController和Zookeeper，FailoverController与Zookeeper通信，通过Zookeeper选举机制，FailoverController通过RPC让NameNode转换为Active或Standby。

1.3 HDFS HA配置要素

NameNode机器：两台配置对等的物理机器，它们分别运行Active和Standby Node。

JouralNode机器：运行JouralNodes的机器。JouralNode守护进程相当的轻量级，可以和Hadoop的其他进程部署在一起，比如NameNode、DataNode、ResourceManager等，至少需要3个且为奇数，如果你运行了N个JNS，那么它可以允许(N-1)/2个JNS进程失效并且不影响工作。

在HA集群中，Standby NameNode还会对namespace进行checkpoint操作（继承Backup Namenode的特性），因此不需要在HA集群中运行SecondaryNameNode、CheckpointNode或者BackupNode。

1.4 HDFS HA配置参数

需要在hdfs.xml中配置如下参数：

dfs.nameservices：HDFS NN的逻辑名称，例如myhdfs。

dfs.ha.namenodes.myhdfs：给定服务逻辑名称myhdfs的节点列表，如nn1、nn2。

dfs.namenode.rpc-address.myhdfs.nn1：myhdfs中nn1对外服务的RPC地址。

dfs.namenode.http-address.myhdfs.nn1：myhdfs中nn1对外服务http地址。

dfs.namenode.shared.edits.dir：JournalNode的服务地址。

dfs.journalnode.edits.dir：JournalNode在本地磁盘存放数据的位置。

dfs.ha.automatic-failover.enabled：是否开启NameNode失败自动切换。

dfs.ha.fencing.methods ：配置隔离机制，通常为sshfence。

1.5 HDFS自动故障转移

HDFS的自动故障转移主要由Zookeeper和ZKFC两个组件组成。

Zookeeper集群作用主要有：一是故障监控。每个NameNode将会和Zookeeper建立一个持久session，如果NameNode失效，那么此session将会过期失效，此后Zookeeper将会通知另一个Namenode，然后触发Failover；二是NameNode选举。ZooKeeper提供了简单的机制来实现Acitve Node选举，如果当前Active失效，Standby将会获取一个特定的排他锁，那么获取锁的Node接下来将会成为Active。

ZKFC是一个Zookeeper的客户端，它主要用来监测和管理NameNodes的状态，每个NameNode机器上都会运行一个ZKFC程序，它的职责主要有：一是健康监控。ZKFC间歇性的ping NameNode，得到NameNode返回状态，如果NameNode失效或者不健康，那么ZKFS将会标记其为不健康；二是Zookeeper会话管理。当本地NaneNode运行良好时，ZKFC将会持有一个Zookeeper session，如果本地NameNode为Active，它同时也持有一个“排他锁”znode，如果session过期，那么次lock所对应的znode也将被删除；三是选举。当集群中其中一个NameNode宕机，Zookeeper会自动将另一个激活。

1.6 YARN HA架构

YARN的HA架构和HDFSHA类似，需要启动两个ResourceManager，这两个ResourceManager会向ZooKeeper集群注册，通过ZooKeeper管理它们的状态（Active或Standby）并进行自动故障转移。

2 高可用集群规划

2.1 集群规划

根据Hadoop的HA架构分析，规划整个集群由5台主机组成，具体情况如下表所示：

主机名

IP地址

安装的软件

JPS

hadoop-master1

172.16.20.81

Jdk/hadoop

Namenode/zkfc/resourcemanager/

JobHistoryServer

hadoop-master2

172.16.20.82

Jdk/hadoop

Namenode/zkfc/resourcemanager/

WebProxyServer

hadoop-slave1

172.16.20.83

Jkd/hadoop/zookeepe

Datanode/journalnode/nodemanager/

quorumPeerMain

hadoop-slave2

172.16.20.84

Jkd/hadoop/zookeeper

Datanode/journalnode/nodemanager/

quorumPeerMain

hadoop-slave3

172.16.20.85

Jkd/hadoop/zookeeper

Datanode/journalnode/nodemanager/

quorumPeerMain

需要说明以下几点：

HDFS HA通常由两个NameNode组成，一个处于Active状态，另一个处于Standby状态。Active NameNode对外提供服务，而Standby NameNode则不对外提供服务，仅同步Active NameNode的状态，以便能够在它失败时快速进行切换。

Hadoop 2.0官方提供了两种HDFS HA的解决方案，一种是NFS，另一种是QJM。这里我们使用简单的QJM。在该方案中，主备NameNode之间通过一组JournalNode同步元数据信息，一条数据只要成功写入多数JournalNode即认为写入成功。通常配置奇数个JournalNode，这里还配置了一个Zookeeper集群，用于ZKFC故障转移，当Active NameNode挂掉了，会自动切换Standby NameNode为Active状态。

YARN的ResourceManager也存在单点故障问题，这个问题在hadoop-2.4.1得到了解决：有两个ResourceManager，一个是Active，一个是Standby，状态由zookeeper进行协调。

YARN框架下的MapReduce可以开启JobHistoryServer来记录历史任务信息，否则只能查看当前正在执行的任务信息。

Zookeeper的作用是负责HDFS中NameNode主备节点的选举，和YARN框架下ResourceManaer主备节点的选举。

2.2 软件版本

操作系统：CentOS Linux release 7.0.1406

JDK：Java(TM)SE Runtime Environment (build 1.7.0_79-b15)

Hadoop：Hadoop 2.6.0-cdh5.7.1

ZooKeeper：zookeeper-3.4.5-cdh5.7.1

3 Linux环境准备

集群各节点进行如下修改配置：

3.1 创建用户并添加权限

// 切换root用户

$ su root

// 创建hadoop用户组

# groupadd hadoop

// 在hadoop用户组中创建hadoop用户

# useradd -g hadoop hadoop

// 修改用户hadoop密码

# passwd hadoop

// 修改sudoers配置文件给hadoop用户添加sudo权限

# vim /etc/sudoers

hadoop ALL=(ALL) ALL

// 测试是否添加权限成功

# exit

$ sudo ls /root

3.2 修改IP地址和主机名

// 切换root用户

$ su root

// 修改本机IP地址

# vim /etc/sysconfig/network-scripts/ifcfg-eth0

// 重启网络服务

# service network restart

// 修改主机名

# hostnamectl set-hostname 主机名

// 查看主机名

# hostnamectl status

3.3 设置IP地址与主机名映射

// 切换root用户

$ su root

// 编辑hosts文件

# vim /etc/hosts

172.16.20.81 hadoop-master1

172.16.20.82 hadoop-master2

172.16.20.83 hadoop-slave1

172.16.20.84 hadoop-slave2

172.16.20.85 hadoop-slave3

3.4 关闭防火墙和Selinux

// 切换root用户

$ su root

// 停止firewall防火墙

# systemctl stop firewalld.service

// 禁止firewall开机启动

# systemctl disable firewalld.service

// 开机关闭Selinux

# vim /etc/selinux/config

SELINUX=disabled

// 重启机器后root用户查看Selinux状态

# getenforce

3.5 配置SSH免密码登录

// 在hadoop-master1节点生成SSH密钥对

$ ssh-keygen -t rsa

// 将公钥复制到集群所有节点机器上

$ ssh-copy-id hadoop-master1

$ ssh-copy-id hadoop-master2

$ ssh-copy-id hadoop-slave1

$ ssh-copy-id hadoop-slave2

$ ssh-copy-id hadoop-slave3

// 通过ssh登录各节点测试是否免密码登录成功

$ ssh hadoop-master2

备注：在其余节点上执行同样的操作，确保集群中任意节点都可以ssh免密码登录到其它各节点。

3.6 安装JDK

// 卸载系统自带的openjdk

$ suroot

# rpm-qa | grep java

# rpm-e --nodeps java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64

# rpm-e --nodeps java-1.7.0-openjdk-headless-1.7.0.75-2.5.4.2.el7_0.x86_64

# rpm-e --nodeps tzdata-java-2015a-1.el7_0.noarch

# exit

// 解压jdk安装包

$ tar-xvf jdk-7u79-linux-x64.tar.gz

// 删除安装包

$ rmjdk-7u79-linux-x64.tar.gz

// 修改用户环境变量

$ cd ~

$ vim.bash_profile

exportJAVA_HOME=/home/hadoop/app/jdk1.7.0_79

exportPATH=$PATH:$JAVA_HOME/bin

// 使修改的环境变量生效

$ source.bash_profile

// 测试jdk是否安装成功

$ java-version

4 集群时间同步

如果集群节点时间不同步，可能会出现节点宕机或引发其它异常问题，所以在生产环境中一般通过配置NTP服务器实现集群时间同步。本集群在hadoop-master1节点设置ntp服务器，具体方法如下：

// 切换root用户

$ su root

// 查看是否安装ntp

# rpm -qa | grep ntp

// 安装ntp

# yum install -y ntp

// 配置时间服务器

# vim /etc/ntp.conf

# 禁止所有机器连接ntp服务器

restrict default ignore

# 允许局域网内的所有机器连接ntp服务器

restrict 172.16.20.0 mask 255.255.255.0 nomodify notrap

# 使用本机作为时间服务器

server 127.127.1.0

// 启动ntp服务器

# service ntpd start

// 设置ntp服务器开机自动启动

# chkconfig ntpd on

集群其它节点通过执行crontab定时任务，每天在指定时间向ntp服务器进行时间同步，方法如下：

// 切换root用户

$ su root

// 执行定时任务，每天00:00向服务器同步时间，并写入日志

# crontab -e

0 0 * * * /usr/sbin/ntpdate hadoop-master1 /home/hadoop/ntpd.log

// 查看任务

# crontab -l

5 Zookeeper集群安装

Zookeeper是一个开源分布式协调服务，其独特的Leader-Follower集群结构，很好的解决了分布式单点问题。目前主要用于诸如：统一命名服务、配置管理、锁服务、集群管理等场景。大数据应用中主要使用Zookeeper的集群管理功能。

本集群使用zookeeper-3.4.5-cdh5.7.1版本。首先在hadoop-slave1节点安装Zookeeper，方法如下：

// 新建目录

$ mkdir app/cdh

// 解压zookeeper安装包

$ tar -xvf zookeeper-3.4.5-cdh5.7.1.tar.gz -C app/cdh/

// 删除安装包

$ rm -rf zookeeper-3.4.5-cdh5.7.1.tar.gz

// 配置用户环境变量

$ vim .bash_profile

export ZOOKEEPER_HOME=/home/hadoop/app/cdh/zookeeper-3.4.5-cdh5.7.1

export PATH=$PATH:$ZOOKEEPER_HOME/bin

// 使修改的环境变量生效

$ source.bash_profile

// 修改zookeeper的配置文件

$ cd app/cdh/zookeeper-3.4.5-cdh5.7.1/conf/

$ cp zoo_sample.cfg zoo.cfg

$ vim zoo.cfg

# 客户端心跳时间(毫秒)

tickTime=2000

# 允许心跳间隔的最大时间

initLimit=10

# 同步时限

syncLimit=5

# 数据存储目录

dataDir=/home/hadoop/app/cdh/zookeeper-3.4.5-cdh5.7.1/data

# 数据日志存储目录

dataLogDir=/home/hadoop/app/cdh/zookeeper-3.4.5-cdh5.7.1/data/log

# 端口号

clientPort=2181

# 集群节点和服务端口配置

server.1=hadoop-slave1:2888:3888

server.2=hadoop-slave2:2888:3888

server.3=hadoop-slave3:2888:3888

# 以下为优化配置

# 服务器最大连接数，默认为10，改为0表示无限制

maxClientCnxns=0

# 快照数

autopurge.snapRetainCount=3

# 快照清理时间，默认为0

autopurge.purgeInterval=1

// 创建zookeeper的数据存储目录和日志存储目录

$ cd ..

$ mkdir -p data/log

// 在data目录中创建一个文件myid，输入内容为1

$ echo "1" data/myid

// 修改zookeeper的日志输出路径(注意CDH版与原生版配置文件不同)

$ vim libexec/zkEnv.sh

if [ "x${ZOO_LOG_DIR}" = "x" ]

then

ZOO_LOG_DIR="$ZOOKEEPER_HOME/logs"

if [ "x${ZOO_LOG4J_PROP}" = "x" ]

then

ZOO_LOG4J_PROP="INFO,ROLLINGFILE"

// 修改zookeeper的日志配置文件

$ vim conf/log4j.properties

zookeeper.root.logger=INFO,ROLLINGFILE

// 创建日志目录

$ mkdir logs

将hadoop-slave1节点上的Zookeeper目录同步到hadoop-slave2和hadoop-slave3节点，并修改Zookeeper的数据文件。此外，不要忘记设置用户环境变量。

// 在hadoop-slave1中将zookeeper目录复制到其它节点

$ cd ~

$ scp -r app/cdh/zookeeper-3.4.5-cdh5.7.1hadoop-slave2:/home/hadoop/app/cdh

$ scp -r app/cdh/zookeeper-3.4.5-cdh5.7.1 hadoop-slave3:/home/hadoop/app/cdh

//在hadoop-slave2中修改data目录中的myid文件

$ echo "2" app/cdh/zookeeper-3.4.5-cdh5.7.1/data/myid

//在hadoop-slave3中修改data目录中的myid文件

$ echo "3" app/cdh/zookeeper-3.4.5-cdh5.7.1/data/myid

最后，在安装了Zookeeper的各节点上启动Zookeeper，并查看节点状态，方法如下：

// 启动

$ zkServer.sh start

// 查看状态

$ zkServer.sh status

// 关闭

[img]

Hadoop HA 高可用原理及部署

在Hadoop 2.0之前，只有namenode一个节点，存在单点问题，namenode单点故障，难以应用与在线场景，也不利于生产上维护集群。namenode压力过大，且内存受损，影响系统延展性。0

HA：高可用集群（High Availability Cluster），是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务，把因软件、硬件、人为造成的故障对业务的影响降到最小。

在hadoop2.0引入了HA机制。hadoop2.0的HA机制官方镇链介绍了有2种方式，一种是NFS（Network File System）方式，另外一种是QJM（QuorumJournal Manager）方式。

NFS（Network File System）

在QJM出现之前，为保障集群的HA，设计的是一种基于NAS的共享存储机制，即主备NameNode间通过NAS进行元数据的同步。该方案有什么缺点呢，主要有以下几点：

1. 定制化硬件设备：必须是支持NAS的设备才能满足需求

2. 复杂化部署过程：在部署好NameNode后，还必须额外配置NFS挂载、定制隔离脚本，部署易出错

3. 简陋化NFS客户端：Bug多，部署配置易出错，导致HA不可用拆运

所以对于替代方案而言，也必须解决NAS相关缺陷才能让HA更好服务。即设备无须定制化，普通设备即可配置HA，部署简单，相关配置集成到系统本身，无需自己定制，同时元数据的同旅旅梁步也必须保证完全HA，不会因client问题而同步失败。所以引出了QJM方式。

QJM全称是Quorum Journal Manager, 由JournalNode（JN）组成，一般是奇数点结点组成。每个JournalNode对外有一个简易的RPC接口，以供NameNode读写EditLog到JN本地磁盘。当写EditLog时，NameNode会同时向所有JournalNode并行写文件，只要有N/2+1结点写成功则认为此次写操作成功，遵循Paxos协议。

hadoop的ha模式出现的原因

Hadoop HA（High Available）经过同时配置两个处于Active/Passive模式的Namenode来解决上述问题，分别叫Active Namenode和Standby Namenode。 Standby Namenode做为热备份凳埋，从而容许在机器发生故障时可以快速进伍春行故障转移，同时在平常维护的时候使用优雅的方式进行Namenode切腔粗耐换。Namenode只能配置一主一备，不能多于两个Namenode。

关于hadoopha和hadoop好友推荐的介绍到此就结束了，不知道你从中找到你需要的信息了吗？如果你还想了解更多这方面的信息，记得收藏关注本站。

数据挖掘的方法有哪些（数据挖掘的三种常用方法） vmwareworkstation15破解版（vmware workstation15破解版）