本文详细介绍Hadoop的高可用性部署过程，包括HDFS和YARN的HA配置，Zookeeper集群搭建，以及JournalNode的设置。通过具体的步骤和配置示例，帮助读者理解如何在多节点环境下实现Hadoop服务的连续性和可靠性。
Hadoop
Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。
HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。
Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。
Hadoop解决哪些问题？
海量数据需要及时分析和处理
海量数据需要深入分析和挖掘
数据需要长期保存
海量数据存储的问题：
磁盘IO称为一种瓶颈，而非CPU资源
网络带宽是一种稀缺资源
硬件故障成为影响稳定的一大因素
Hadoop环境搭建
系统环境：
server1:172.25.24.1
server2:172.25.24.2
server3:172.25.24.3
server4:172.25.24.4
单机版
useradd -u 800 hadoop
passwd hadoop
su - hadoop
tar zxf jdk-7u79-linux-x64.tar.gz
ln -s jdk1.7.0_79/ java
vim .bash_profile
source .bash_profile
tar zxf hadoop-2.7.3.tar.gz
cd hadoop-2.7.3/etc/hadoop/
vim hadoop-env.sh
cd ~/hadoop-2.7.3
bin/hadoop #启动
mkdir input
cp etc/hadoop/*.xml input/
bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar #查看jar包中的方法
bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar grep input output 'dfs[a-z.]+'
伪分布式
cd etc/hadoop/
vim core-site.xml
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://172.25.24.1:9000</value>
</property>
</configuration>
vim hdfs-site.xml
<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
</configuration>
ssh免密认证
ssh-keygen #全部回车即可
ssh-copy-id 172.25.24.1 #此处密码为hadoop用户密码
ssh server1
ssh 172.25.24.1
ssh localhost
ssh 0.0.0.0
cd ~/hadoop-2.7.3/etc/hadoop/
vim slaves #hdfs启动时会访问此文件
将localhost改为本机ip
cd ~/hadoop-2.7.3
bin/hdfs namenode -format
sbin/start-dfs.sh #启动
可以浏览器访问本机ip：50070
在Utilities的 Browse the file system 中查看
bin/hdfs dfs -mkdir /user
bin/hdfs dfs -mkdir /user/hadoop
bin/hdfs dfs -put input/
rm -fr input output
bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar grep input output 'dfs[a-z.]+'
bin/hdfs dfs -ls
bin/hdfs dfs -cat output/*
bin/hdfs dfs -get output
cat output/*
分布式
Server1
cd ~/hadoop-2.7.3/
sbin/stop-dfs.sh #关闭hadoop
vim etc/hadoop/hdfs-site.xml
vim etc/hadoop/slaves
172.25.24.2
172.25.24.3
rm -fr /tmp/*
exit
yum install -y nfs-utils
/etc/init.d/rpcbind start
vim /etc/exports
/home/hadoop *(rw,anonuid=800,anongid=800)
/etc/init.d/nfs start
showmount -e
Server2
yum install -y nfs-utils
/etc/init.d/rpcbind start
useradd -u 800 hadoop
mount 172.25.24.1:/home/hadoop/ /home/hadoop/
su - hadoop #第一次切换等待时间可能较长，查看可以发现所有数据都已同步，并且各节点间实现免密
Server3步骤同server2
Server1
cd ~/hadoop-2.7.3
bin/hdfs namenode -format
sbin/start-dfs.sh #启动
此时server2与server3上有DataNode进程生成
bin/hdfs dfs -mkdir /user
bin/hdfs dfs -mkdir /user/hadoop
bin/hdfs dfs -put etc/hadoop/ input
bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar wordcount input output #统计单词频率
bin/hdfs dfs -cat output/* #查看输出结果
在线添加和移除节点
1）添加
Server4
cd hadoop-2.7.3
vim etc/hadoop/slaves
172.25.24.2
172.25.24.3
172.25.24.4
sbin/hadoop-daemon.sh start datanode #启动server4
此时在监控页面Datanodes中查看，server4已添加
dd if=/dev/zero of=bigfile bs=1M count=500 #建立一个500M的文件
bin/hdfs dfs -put bigfile #上传
在监控页面查看得，总共存储两份
再上传一个大文件
查看
2）删除
在线删除节点会进行数据迁移
Server4
cd
ln -s hadoop-2.7.3 hadoop
vim etc/hadoop/hdfs-site.xml
vim /home/hadoop/hadoop/etc/hadoop/exclude_hosts
172.25.24.4
vim etc/hadoop/slaves
172.25.24.2
172.25.24.3
Server1
bin/hdfs dfsadmin -refreshNodes #刷新节点信息
在监控页面可以发现server4上的数据正在迁移
此时server4上的数据已经全部转移到其他节点上了
也可以用命令查看
bin/hdfs dfsadmin -report
Hdfs和yarn高可用
环境：
Server1：DFSZKFailoverController，NN，RM 172.25.24.1
Server5：DFSZKFailoverController，NN，RM 172.25.24.5
Server2：JN，QuorumPeerMain，DN，NM 172.25.24.2
Server3：JN，QuorumPeerMain，DN，NM 172.25.24.3
Server4：JN，QuorumPeerMain，DN，NM 172.25.24.4
RHEL6.5 selinux and iptables is disabled
Hadoop 、jdk、zookeeper 程序使用 nfs 共享同步配置文件
在典型的 HA 集群中,通常有两台不同的机器充当 NN。在任何时间,只有一台机器处于
Active 状态;另一台机器是处于 Standby 状态。Active NN 负责集群中所有客户端的操作;而 Standby NN 主要用于备用,它主要维持足够的状态,如果必要,可以提供快速的故障恢复。
为了让 Standby NN 的状态和 Active NN 保持同步,即元数据保持一致,它们都将会和
JournalNodes 守护进程通信。当 Active NN 执行任何有关命名空间的修改,它需要持久化到一半以上的 JournalNodes 上(通过 edits log 持久化存储),而 Standby NN 负责观察 edits log的变化,它能够读取从 JNs 中读取 edits 信息,并更新其内部的命名空间。一旦 Active NN出现故障,Standby NN 将会保证从 JNs 中读出了全部的 Edits,然后切换成 Active 状态。Standby NN 读取全部的 edits 可确保发生故障转移之前,是和 Active NN 拥有完全同步的命名空间状态。
为了提供快速的故障恢复,Standby NN 也需要保存集群中各个文件块的存储位置。为
了实现这个,集群中所有的 Database 将配置好 Active NN 和 Standby NN 的位置,并向它们发送块文件所在的位置及心跳，如下图所示:
在任何时候,集群中只有一个 NN 处于 Active 状态是极其重要的。否则,在两个 Active NN的状态下 NameSpace 状态将会出现分歧,这将会导致数据的丢失及其它不正确的结果。为了保证这种情况不会发生,在任何时间,JNs 只允许一个 NN 充当 writer。在故障恢复期间,将要变成 Active 状态的 NN 将取得 writer 的角色,并阻止另外一个 NN 继续处于 Active状态。
为了部署 HA 集群,你需要准备以下事项:
(1)、NameNode machines:运行 Active NN 和 Standby NN 的机器需要相同的硬件配
置;
(2)、JournalNode machines:也就是运行 JN 的机器。JN 守护进程相对来说比较轻
量,所以这些守护进程可以可其他守护线程(比如 NN,YARN ResourceManager)运行在
同一台机器上。在一个集群中,最少要运行 3 个 JN 守护进程,这将使得系统有一定的容错
能力。当然,你也可以运行 3 个以上的 JN,但是为了增加系统的容错能力,你应该运行奇
数个 JN(3、5、7 等),当运行 N 个 JN,系统将最多容忍(N-1)/2 个 JN 崩溃。
在 HA 集群中,Standby NN 也执行 namespace 状态的 checkpoints,所以不必要运行
Secondary NN、CheckpointNode 和 BackupNode;事实上,运行这些守护进程是错误的。
Hdfs高可用
部署Zookeeper集群,Zookeeper 集群至少三台,总节点数为奇数个
Server1
安装 zookeeper,因为nfs缘故，只需在server1上配置即可
tar zxf zookeeper-3.4.9.tar.gz
cd zookeeper-3.4.9/conf
cp zoo_sample.cfg zoo.cfg
vim zoo.cfg #编辑 zoo.cfg 文件
server.1=172.25.24.2:2888:3888
server.2=172.25.24.3:2888:3888
server.3=172.25.24.4:2888:3888
#各节点配置文件相同,并且需要在/tmp/zookeeper 目录中创建 myid 文件,写入
一个唯一的数字,取值范围在 1-255。比如:172.25.0.2 节点的 myid 文件写入数
字“1”,此数字与配置文件中的定义保持一致,(server.1=172.25.24.2:2888:3888
)其它节点依次类推
Server2
mkdir /tmp/zookeeper
vim /tmp/zookeeper/myid
1
Server3
mkdir /tmp/zookeeper
vim /tmp/zookeeper/myid
2
Server4
mkdir /tmp/zookeeper
vim /tmp/zookeeper/myid
3
在各节点启动服务:
zookeeper-3.4.9/bin/zkServer.sh start
bin/zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /home/hadoop/zookeeper-3.4.9/bin/../conf/zoo.cfg
Mode: leader
bin/zkCli.sh -server 127.0.0.1:2181 #连接 zookeeper
[zk: 127.0.0.1:2181(CONNECTED) 0] help
配置参数详解:
clientPort
客户端连接 server 的端口,即对外服务端口,一般设置为 2181 吧。
dataDir
存储快照文件 snapshot 的目录。默认情况下,事务日志也会存储在这里。建议同时配置参数dataLogDir, 事务日志的写性能直接影响 zk 性能。
tickTime
ZK 中的一个时间单元。ZK 中所有时间都是以这个时间单元为基础,以毫秒计,用来调节心和超时。例如,session 的最小超时时间是 2*tickTime。
dataLogDir
事务日志输出目录。尽量给事务日志的输出配置单独的磁盘或是挂载点,这将极大的提升ZK 性能。 (No Java system property)
globalOutstandingLimit
最大请求堆积数。默认是 1000。ZK 运行的时候, 尽管 server 已经没有空闲来处理更多的客户端请求了,但是还是允许客户端将请求提交到服务器上来,以提高吞吐性能。当然,为了防止 Server 内存溢出,这个请求堆积数还是需要限制下的。(Java system property:zookeeper.globalOutstandingLimit.)
preAllocSize
预先开辟磁盘空间,用于后续写入事务日志。默认是 64M,每个事务日志大小就是 64M。如 果 ZK 的 快 照 频 率 较 大 的 话 , 建 议 适 当 减 小 这 个 参 数 。 (Java systemproperty:zookeeper.preAllocSize)
snapCount
每进行 snapCount 次事务日志输出后,触发一次快照(snapshot), 此时,ZK 会生成一个snapshot.文件,同时创建一个新的事务日志文件 log.。默认是 100000.(真正的代码实现中,会进行一定的随机数处理,以避免所有服务器在同一时间进行快照而影响性能)(Javasystem property:zookeeper.snapCount)
traceFile
用于记录所有请求的 log,一般调试过程中可以使用,但是生产环境不建议使用,会严重影响性能。(Java system property:? requestTraceFile)
maxClientCnxns
单个客户端与单台服务器之间的连接数的限制,是 ip 级别的,默认是 60,如果设置为 0,那么表明不作任何限制。请注意这个限制的使用范围,仅仅是单台客户端机器与单台 ZK服务器之间的连接数限制,不是针对指定客户端 IP,也不是 ZK 集群的连接数限制,也不是单台 ZK 对所有客户端的连接数限制。指定客户端 IP 的限制策略,这里有一个 patch,可以尝试一下:http://rdc.taobao.com/team/jm/archives/1334(No Java system property)
clientPortAddress
对于多网卡的机器,可以为每个 IP 指定不同的监听端口。默认情况是所有 IP 都监听clientPort 指定的端口。 New in 3.3.0
minSessionTimeoutmaxSessionTimeout
Session 超时时间限制,如果客户端设置的超时时间不在这个范围,那么会被强制设置为最大或最小时间。默认的 Session 超时时间是在 2 * tickTime ~ 20 * tickTime 这个范围 New in 3.3.0
fsync.warningthresholdms
事务日志输出时,如果调用 fsync 方法超过指定的超时时间,那么会在日志中输出警告信息。默认是 1000ms。(Java system property: fsync.warningthresholdms)New in 3.3.4autopurge.purgeInterval
在上文中已经提到,3.4.0 及之后版本,ZK 提供了自动清理事务日志和快照文件的功能,这个参数指定了清理频率,单位是小时,需要配置一个 1 或更大的整数,默认是 0,表示不开启自动清理功能。(No Java system property) New in 3.4.0
autopurge.snapRetainCount
这个参数和上面的参数搭配使用,这个参数指定了需要保留的文件数目。默认是保留 3个。(No Java system property) New in 3.4.0
electionAlg
在之前的版本中, 这个参数配置是允许我们选择 leader 选举算法,但是由于在以后的版本中,只会留下一种“
TCP-based version of fast leader election”
算法,所以这个参数目前看来没有用了,这里也不详细展开说了。(No Java system property)
initLimit
Follower 在启动过程中,会从 Leader 同步所有最新数据,然后确定自己能够对外服务的起始状态。Leader 允许 F 在 initLimit 时间内完成这个工作。通常情况下,我们不用太在意这个参数的设置。如果 ZK 集群的数据量确实很大了,F 在启动的时候,从 Leader 上同步数的时间也会相应变长,因此在这种情况下,有必要适当调大这个参数了。(No Java system property)
syncLimit
在运行过程中,Leader 负责与 ZK 集群中所有机器进行通信,例如通过一些心跳检测机制,来检测机器的存活状态。如果 L 发出心跳包在 syncLimit 之后,还没有从 F 那里收到响应,那么就认为这个 F 已经不在线了。注意:不要把这个参数设置得过大,否则可能会掩盖一些问题。(No Java system property)
leaderServes
默认情况下,Leader 是会接受客户端连接,并提供正常的读写服务。但是,如果你想让Leader 专注于集群中机器的协调,那么可以将这个参数设置为 no,这样一来,会大大提高写操作的性能。(Java system property: zookeeper.leaderServes)。
server.x=[hostname]:nnnnn[:nnnnn]
这里的 x 是一个数字,与 myid 文件中的 id 是一致的。右边可以配置两个端口,第一个端口用于 F 和 L 之间的数据同步和其它通信,第二个端口用于 Leader 选举过程中投票通信。(No Java system property)
group.x=nnnnn[:nnnnn]weight.x=nnnnn
对机器分组和权重设置,可以 参见这里(No Java system property)
cnxTimeout
Leader 选举过程中,打开一次连接的超时时间,默认是 5s。(Java system property: zookeeper.cnxTimeout)
zookeeper.DigestAuthenticationProvider.superDigest
ZK 权 限 设 置 相 关 , 具 体 参 见 《 使 用 super 身 份 对 有 权 限 的 节 点 进 行 操 作 》 和《 ZooKeeper 权限控制》
skipACL
对所有客户端请求都不作 ACL 检查。如果之前节点上设置有权限限制,一旦服务器上打开这个开头,那么也将失效。(Java system property: zookeeper.skipACL)
forceSync
这个参数确定了是否需要在事务日志提交的时候调用 FileChannel.force 来保证数据完全同步到磁盘。(Java system property: zookeeper.forceSync)
jute.maxbuffer
每个节点最大数据量,是默认是 1M。这个限制必须在 server 和 client 端都进行设置才会生效。(Java system property: jute.maxbuffer)
Hadoop 配置
Server1
vim etc/hadoop/core-site.xml
<configuration>
<!-- 指定 hdfs 的 namenode 为 masters (名称可自定义)-->
<property>
<name>fs.defaultFS</name>
<value>hdfs://masters</value>
</property>
<!-- 指定 zookeeper 集群主机地址 -->
<property>
<name>ha.zookeeper.quorum</name>
<value>172.25.24.2:2181,172.25.24.3:2181,172.25.24.4:2181</value>
</property>
</configuration>
vim etc/hadoop/hdfs-site.xml
<configuration>
<property>
<name>dfs.replication</name>
<value>3</value>
</property>
<!-- 指定 hdfs 的 nameservices 为 masters,和 core-site.xml 文件中的设置保持一致 -->
<property>
<name>dfs.nameservices</name>
<value>masters</value>
</property>
<!-- masters 下面有两个 namenode 节点,分别是 h1 和 h2 (名称可自定义)-->
<property>
<name>dfs.ha.namenodes.masters</name>
<value>h1,h2</value>
</property>
<!-- 指定 h1 节点的 rpc 通信地址 -->
<property>
<name>dfs.namenode.rpc-address.masters.h1</name>
<value>172.25.24.1:9000</value>
</property>
<!-- 指定 h1 节点的 http 通信地址 -->
<property>
<name>dfs.namenode.http-address.masters.h1</name>
<value>172.25.24.1:50070</value>
</property>
<!-- 指定 h2 节点的 rpc 通信地址 -->
<property>
<name>dfs.namenode.rpc-address.masters.h2</name>
<value>172.25.24.5:9000</value>
</property>
<!-- 指定 h2 节点的 http 通信地址 -->
<property>
<name>dfs.namenode.http-address.masters.h2</name>
<value>172.25.24.5:50070</value>
</property>
<!-- 指定 NameNode 元数据在 JournalNode 上的存放位置 -->
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://172.25.24.2:8485;172.25.24.3:8485;172.25.24.4:8485/masters</value>
</property>
<!-- 指定 JournalNode 在本地磁盘存放数据的位置 -->
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/tmp/journaldata</value>
</property>
<!-- 开启 NameNode 失败自动切换 -->
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
<!-- 配置失败自动切换实现方式 -->
<property>
<name>dfs.client.failover.proxy.provider.masters</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<!-- 配置隔离机制方法,每个机制占用一行-->
<property>
<name>dfs.ha.fencing.methods</name>
<value>
sshfence
shell(/bin/true)
</value>
</property>
<!-- 使用 sshfence 隔离机制时需要 ssh 免密码 -->
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/hadoop/.ssh/id_rsa</value>
</property>
<!-- 配置 sshfence 隔离机制超时时间 -->
<property>
<name>dfs.ha.fencing.ssh.connect-timeout</name>
<value>30000</value>
</property>
</configuration>
启动 hdfs 集群(按顺序启动)
1）在三个 DN 上依次启动 zookeeper 集群
在各节点启动服务
bin/zkServer.sh start
bin/zkServer.sh status
2)在三个 DN 上依次启动 journalnode(第一次启动 hdfs 必须先启动 journalnode)
sbin/hadoop-daemon.sh start journalnode
3)格式化 HDFS 集群
hadoop/bin/hdfs namenode -format
Namenode 数据默认存放在/tmp,需要把数据拷贝到 h2
scp -r /tmp/hadoop-hadoop 172.25.24.5:/tmp
-
格式化 zookeeper (只需在 h1 上执行即可)
hadoop/bin/hdfs zkfc -formatZK
5)启动 hdfs 集群(只需在 h1 上执行即可)
hadoop/sbin/start-dfs.sh
6）查看各节点状态
jps
浏览器查看
- 测试故障自动切换
杀掉server1NN进程
依然可以访问,此时 h2 转为 active 状态接管 namenode
hadoop/bin/hdfs dfs -ls
启动 h1 上的 namenode,此时为 standby 状态
hadoop/sbin/hadoop-daemon.sh start namenode
yarn 高可用
cd ~/hadoop/etc/hadoop/
cp mapred-site.xml.template mapred-site.xml
vim mapred-site.xml
<configuration>
<!-- 指定 yarn 为 MapReduce 的框架 -->
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
</configuration>
vim yarn-site.xml
<configuration>
<!-- Site specific YARN configuration properties -->
<!-- 配置可以在 nodemanager 上运行 mapreduce 程序 -->
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<!-- 激活 RM 高可用 -->
<property>
<name>yarn.resourcemanager.ha.enabled</name>
<value>true</value>
</property>
<!-- 指定 RM 的集群 id -->
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>RM_CLUSTER</value>
</property>
<!-- 定义 RM 的节点-->
<property>
<name>yarn.resourcemanager.ha.rm-ids</name>
<value>rm1,rm2</value>
</property>
<!-- 指定 RM1 的地址 -->
<property>
<name>yarn.resourcemanager.hostname.rm1</name>
<value>172.25.24.1</value>
</property>
<!-- 指定 RM2 的地址 -->
<property>
<name>yarn.resourcemanager.hostname.rm2</name>
<value>172.25.24.5</value>
</property>
<!-- 激活 RM 自动恢复 -->
<property>
<name>yarn.resourcemanager.recovery.enabled</name>
<value>true</value>
</property>
<!-- 配置 RM 状态信息存储方式,有 MemStore 和 ZKStore-->
<property>
<name>yarn.resourcemanager.store.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
</property>
<!-- 配置为 zookeeper 存储时,指定 zookeeper 集群的地址 -->
<property>
<name>yarn.resourcemanager.zk-address</name>
<value>172.25.24.2:2181,172.25.24.3:2181,172.25.24.4:2181</value>
</property>
</configuration>
启动 yarn 服务
hadoop/sbin/start-yarn.sh
RM2 上需要手动启动RM
hadoop/sbin/yarn-daemon.sh start resourcemanager
最好是把 RM 与 NN 分离运行,这样可以更好的保证程序的运行性能。
浏览器访问server1 ip:8088查看
点击 Cluster --> About
测试 yarn 故障切换
杀掉server1的RM进程
依然可以访问,此时 RM2 转为 active 状态接管 ResourceManager
启动 RM1 上的resourcemanager ,此时为 standby 状态
hadoop/sbin/yarn-daemon.sh start resourcemanager
扫一扫
1433
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
