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"
fi
if [ "x${ZOO_LOG4J_PROP}" = "x" ]
then
ZOO_LOG4J_PROP="INFO,ROLLINGFILE"
fi
// 修改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
// 关闭
$ zkServer.sh stop
6 Hadoop HA配置
// 在hadoop-master1节点解压hadoop安装包
$ tar-xvf hadoop-2.6.0-cdh5.7.1.tar.gz -C /home/hadoop/app/cdh/
// 删除安装包
$ rmhadoop-2.6.0-cdh5.7.1.tar.gz
// 修改hadoop-env.sh文件
$ cd/home/hadoop/app/cdh/hadoop-2.6.0-cdh5.7.1/etc/hadoop
$ vimhadoop-env.sh
exportJAVA_HOME=/home/hadoop/app/jdk1.7.0_79
// 配置core-site.xml文件
$ vim core-site.xml
// 配置hdfs-site.xml文件
$ vim hdfs-site.xml
// 配置mapred-site.xml文件
$ vim mapred-site.xml
// 配置yarn-site.xml文件
$ vim yarn-site.xml
// 配置slaves文件
$ vimslaves
hadoop-slave1
hadoop-slave2
hadoop-slave3
// 创建配置文件中涉及的目录
$ cd/home/hadoop/app/cdh/hadoop-2.6.0-cdh5.7.1/
$ mkdir-p data/tmp
$ mkdir-p data/journal
$ mkdir-p data/namenode
$ mkdir-p data/datanode
// 将hadoop工作目录同步到集群其它节点
$ scp-r /home/hadoop/app/cdh/hadoop-2.6.0-cdh5.7.1/hadoop-master2:/home/hadoop/app/cdh/
scp -r/home/hadoop/app/cdh/hadoop-2.6.0-cdh5.7.1/ hadoop-slave1:/home/hadoop/app/cdh/
scp -r/home/hadoop/app/cdh/hadoop-2.6.0-cdh5.7.1/ hadoop-slave2:/home/hadoop/app/cdh/
scp -r/home/hadoop/app/cdh/hadoop-2.6.0-cdh5.7.1/ hadoop-slave3:/home/hadoop/app/cdh/
// 在集群各节点上修改用户环境变量
$ vim .bash_profile
export HADOOP_HOME=/home/hadoop/app/cdh/hadoop-2.6.0-cdh5.7.1
export LD_LIBRARY_PATH=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
// 使修改的环境变量生效
$ source .bash_profile
// 解决本地库文件不存在的问题
在apache官网下载hadoop-2.6.0.tar.gz,解压后将lib/native下所有文件复制到$HADOOP_HOME/lib/native中。
7 Hadoop集群的初始化
// 启动zookeeper集群(分别在slave1、slave2和slave3上执行)
$ zkServer.sh start
// 格式化ZKFC(在master1上执行)
$ ./hdfs zkfc -formatZK // /usr/local/soft/hadoop-2.6.0/bin
// 启动journalnode(分别在slave1、slave2和slave3上执行)
$ hadoop-daemon.sh start journalnode
// 格式化HDFS(在master1上执行)
$ hdfs namenode -format
// 将格式化后master1节点hadoop工作目录中的元数据目录复制到master2节点
$ scp-r app/cdh/hadoop-2.6.0-cdh5.7.1/data/namenode/*hadoop-master2:/home/hadoop/app/cdh/hadoop-2.6.0-cdh5.7.1/data/namenode/
// 初始化完毕后可关闭journalnode(分别在slave1、slave2和slave3上执行)
$ hadoop-daemon.sh stop journalnode
8 Hadoop集群的启动
8.1 集群启动步骤
// 启动zookeeper集群(分别在slave1、slave2和slave3执行)
$ zkServer.sh start
// 启动HDFS(在master1执行)
$ start-dfs.sh
备注:此命令分别在master1/master2节点启动了NameNode和ZKFC,分别在slave1/slave2/slave3节点启动了DataNode和JournalNode,如下图所示。
// 启动YARN(在master2执行)
$ start-yarn.sh
备注:此命令在master2节点启动了ResourceManager,分别在slave1/slave2/slave3节点启动了NodeManager。
// 启动YARN的另一个ResourceManager(在master1执行,用于容灾)
$ yarn-daemon.sh start resourcemanager
// 启动YARN的安全代理(在master2执行)
$ yarn-daemon.sh start proxyserver
备注:proxyserver充当防火墙的角色,可以提高访问集群的安全性
// 启动YARN的历史任务服务(在master1执行)
$ mr-jobhistory-daemon.sh starthistoryserver
备注:yarn-daemon.sh start historyserver已被弃用;CDH版本似乎有个问题,即mapred-site.xml配置的mapreduce.jobhistory.address和mapreduce.jobhistory.webapp.address参数似乎不起作用,实际对应的端口号是10200和8188,而且部需要配置就可以在任意节点上开启历史任务服务。
8.2 集群启动截图
hadoop-master1开启了NameNode、ResourceManager、HistoryServer和ZKFC,如下图所示:
hadoop-master2开启了NameNode、ResourceManager、ProxyServer和ZKFC,如下图所示:
hadoop-slave1、hadoop-slave2和hadoop-slave3分别开启了DataNode、JournalNode、NodeManager和ZooKeeper,如下图所示:
8.3 Web UI
下图为http://hadoop-master1:50070,可看到NameNode为active状态:
下图为http://hadoop-master2:50070,可看到NameNode为standby状态:
HDFS还有一个隐藏的UI页面http://hadoop-master1:50070/dfshealth.jsp比较好用:
下图为http://hadoop-master2:8088,可看到ResourceManager为active状态:
下图为http://hadoop-master1:8088,可看到ResourceManager为standby状态,它会自动跳转到http://hadoop-master2:8088:
下图为http://hadoop-master1:19888,可查看历史任务信息:
9 功能测试
// 向HDFS上传数据
$ hadoopfs -put webcount.txt /input
// 查看HDFS上的数据
$ hadoopfs -ls /input
$ hadoopfs -cat /input/webcount.txt
// 向YARN提交MapReduce任务,该任务用于分析网站日志文件webcount.txt统计每小时的点击次数
$ hadoopjar mr-webcount-0.0.1-SNAPSHOT.jar com.mr.demo.WebCountDriver/input/webcount.txt /output/webcount 1 1
// 在HDFS查看结果
$ hadoopfs -ls /output/webcount
$ hadoopfs -cat /output/webcount/part-r-00000
// 通过Web UI查看任务信息和历史任务信息
相关推荐
Hadoop 2.0 引入了高可用性(HA)特性,极大地提高了系统的稳定性。本文将详细介绍在Hadoop 2.0环境下进行集群部署的关键步骤。 1. **创建统一用户账户** 在所有节点上创建相同用户名(如 hadoop)是部署的基础,...
2. HDFS HA(High Availability):为了解决NameNode单点故障问题,Hadoop 2.0实现了NameNode高可用,通过热备机制确保服务不间断。 3. 更强的容错性和可扩展性:通过改进的数据节点心跳机制和快速失败检测,Hadoop...
Hadoop 2.0 在原有的基础上引入了关键改进,包括高可用性(HA)、YARN(Yet Another Resource Negotiator)和HDFS联邦。 1. **Hadoop 2.0 高可用性(HA)**: - HDFS HA 通过引入Active/Standby NameNode的角色,...
通过以上步骤,我们可以成功地搭建一个基于Hadoop 2.6.4的高可用集群。这种集群不仅提供了更强的容错能力,还确保了系统的稳定性和可用性。在实际部署过程中,还需要根据具体的业务需求进行相应的优化调整,例如性能...
综上所述,Hadoop2.0在HDFS、MapReduce和YARN等方面都进行了重大的改进和优化,不仅解决了Hadoop1.0中的许多局限性,还极大地提升了系统的可扩展性、可靠性和资源利用率,为大数据处理领域带来了新的突破。
Hadoop 2.0 引入了高可用性(HA)机制,其中 NameNode 可以处于 Active 和 Standby 两种状态。Active NameNode 提供数据服务,而 Standby NameNode 则同步 Active NameNode 的状态,在 Active NameNode 失效时能够...
### Hadoop2.x HA环境搭建知识点详解 #### 一、HA2.0集群搭建与测试 **准备工作:** 1. **停掉之前的服务:** - 在搭建Hadoop2.x HA集群之前,需要确保所有相关的服务都已经停止运行,避免与新搭建的集群产生...
- HA(High Availability)支持:为NameNode提供了高可用性,确保了服务的连续性。 3. **MapReduce改进:** - MapReduce 2.0 (MRv2):基于YARN的新一代MapReduce框架,使得MapReduce与其他大数据处理框架如Spark、...
### Hadoop-CCAH攻略详解:大数据平台必备知识点 #### 一、Cloudera Certified Administrator for Apache Hadoop (CCAH) **CCAH**是Cloudera认证为管理员提供的专业认证,旨在验证应试者在管理和维护Apache Hadoop...
为解决单点故障问题,Hadoop2.0引入了HA和YARN。 4.2 High Availability(HA) HA通过设置多个NameNode实现,确保即使主NameNode故障,系统仍能继续运行。 4.3 Yet Another Resource Negotiator(YARN) YARN作为...
Hadoop 1.0代的版本主要包括0.20.x、0.21.x和0.22.x,而Hadoop 2.0代的版本则包括0.23.x和2.x,其中2.x版本相较于0.23.x增加了NameNode高可用性(HA)和线性兼容性(Wire-compatibility)等特性。此外,市面上存在多...
3. **高可用性**:CDH支持多种HA模式,确保关键服务的持续运行。 4. **安全性增强**:CDH提供了Kerberos认证、SSL加密等安全特性,保障数据安全。 5. **兼容性和稳定性**:CDH经过严格的测试,确保与Apache Hadoop的...
- **HA的概念**: 高可用性(HA)的目标是通过冗余设计来消除单点故障,保证服务的连续性和数据的持久性。虽然不可能达到100%的可用性,但通过合理的架构设计可以极大地减少服务中断时间。 - **HA监控工具**: 在...