请选择 进入手机版 | 继续访问电脑版
设为首页收藏本站

可可云计算

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

搜索
查看: 925|回复: 0

Hadoop框架基础(五)

[复制链接]

1214

主题

1279

帖子

4286

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
4286
发表于 2017-5-24 11:47:33 | 显示全部楼层 |阅读模式
已经部署了Hadoop的完全分布式集群,我们知道NameNode节点的正常运行对于整个HDFS系统来说非常重要,如果NameNode宕掉了,那么整个HDFS就要整段垮掉了,所以人类思考,能不能让世界多一点爱:),我们能不能弄个备用的NameNode,一旦正在使用的NameNode原地爆炸了,另一台备用的NameNode能立刻代替原先NameNode的位置,继续让HDFS系统正常运行?(同理,ResourceManager也是可以的。)
世界果然充满爱,动物管理员横空出世——zookeeper框架
1240.jpg

** ZooKeeper
这个框架的翻译为动物园管理员,想想其实是有道理的,大数据领域,Hadoop框架是大象,Hive框架是蜜蜂(为啥是个大象头哎喂?),Pig框架是猪,都是人类的好朋友,所以有个动物管理员也不差异。接下来简单介绍一下zookeeper框架。
1240.jpg

** zookeeper功能:
* 统一命名服务(Name Service)
* 配置管理(Configuration Management)
* 集群管理(Group Membership)
* 共享锁(Locks)/同步锁
** zookeeper简述:
apache开源项目,提供分布式集群,属于Hadoop底下的一个分支,为分布式应用提供协调服务,官方网站:zookeeper.apache.org,zookeeper服务器为奇数个,即2n+1个服务器,允许有n个机器宕机,不影响整个系统的运行。比如:3台机器,其中有1台机器宕机,且存活的Server的数目不得少于n+1.,不会影响整个系统运行。 zookeeper集群会选择出一个leader服务器,其他服务器角色是follower,它使用的FastLeaderELection选举算法是类fast paoxs的算法(有兴趣的可以周边查阅下),投票数量结果过半的服务器选为leader服务器。
** zookeeper原理简述
1240.jpg

当leader崩溃或者leader失去大多数的follower,这时候zookeeper进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的Server都恢复到一个正确的状态,系统默认的选举算法为fast paxos。
** zookeeper的Fast Leader选举机制
首先介绍几个概念
服务器ID
比如有三台服务器,编号分别是1,2,3。
编号越大在选择算法中的权重越大。
数据ID
服务器中存放的最大数据ID.
值越大说明数据越新,在选举算法中数据越新权重越大。
逻辑时钟
或者叫投票的轮数,同一轮投票过程中的逻辑时钟值是相同的。每投完一轮票这个数据就会增加,然后与接收到的其它服务器返回的投票信息中的数值相比,根据不同的值做出不同的判断。
选举状态
LOOKING,竞选状态。
FOLLOWING,随从状态,同步leader状态,参与投票。
OBSERVING,观察状态,同步leader状态,不参与投票。
LEADING,领导者状态。
选举消息内容
在投票完成后,需要将投票信息发送给集群中的所有服务器,它包含如下内容。
服务器ID
数据ID
逻辑时钟(或者理解为选举轮数,从0开始递增)
选举状态
开始投票:
1、恢复数据
zookeeper服务器中的每份数据,都有一个对应的id值,这个值是依次递增的,越新的数据,对应的ID值就越大,所以先把数据恢复到最新。
2、广播投票到其他服务器
恢复数据到最新之后,每个zookeeper服务器发送自己选举的leader(崭新状态首次投票推选自己),这个协议中包含了以下几部分的数据:
* 当前的服务器的id,即sid
* 当前服务器的最大的数据id,这个值大的服务器,说明存放了更新的数据.
* 当前服务器本次的逻辑时钟的值
* 当前机器的选举状态
3、接收其他服务器的广播
每个服务器将自己的数据(以上4个)广播给其他服务器,同时也接收其他服务器广播过来的数据,之后:
如果所接收数据中服务器的状态还是在选举阶段(LOOKING 状态),那么首先判断逻辑时钟值,又分为以下三种情况:
* 如果发送过来的逻辑时钟大于目前的逻辑时钟,那么说明这次选举更加的新,此时需要更新一下本机的逻辑时钟值,同时将之前收集到的来自其他服务器的选举清空,因为这些数据已经过期了。然后判断是否需要更新当前自己的选举情况。在这里是根据选举sid和保存的最大数据id来进行判断的,这两种数据之间对这个选举结果的影响的权重关系是:首先看数据id,数据id大者胜出;其次再判断sid,sid大者胜出。然后再将自身最新的选举结果广播给其他服务器。
* 如果发送过来数据的逻辑时钟小于本机的逻辑时钟,说明对方在一个相对较早的选举进程中,此时只需要发送自己的选举数据即可。
* 两边的逻辑时钟相同,此时只需要判断是否需要更新本机的数据,如果更新了再将自己最新的选举结果广播出去就是了。
然后再处理两种情况:
* 服务器判断是不是已经收集到了所有服务器的选举状态,如果是,那么这台服务器选举的leader就定下来了,然后根据选举结果设置自己的角色(FOLLOWING还是LEADER),选举结束。
* 即使没有收集到所有服务器的选举状态,也可以根据该节点上选择的最新的leader是不是得到了超过半数以上服务器的支持,如果是,那么当前线程将被阻塞等待一段时间(这个时间在finalizeWait定义)看看是不是还会收到当前leader的数据更优的leader,如果经过一段时间还没有这个新的leader提出来,那么这台服务器最终的leader就确定了,否则进行下一次选举。
如果所接收服务器不在选举状态,也就是在FOLLOWING或者LEADING状态做以下两个判断:
* 如果逻辑时钟相同,将该数据保存到recvset,如果所接收服务器宣称自己是leader,那么将判断是不是有半数以上的服务器选举它,如果是则设置选举状态,选举结束。
* 否则这是一条与当前逻辑时钟不符合的消息,那么说明在另一个选举过程中已经有了选举结果,于是将该选举结果加入到集合中,再根据集合来判断是否可以结束选举,如果可以也是保存逻辑时钟,设置选举状态,选举结束。
原理引用网络上的一张图,如图所示:
1240.jpg

在此举个例子:假设有5台机器
服务器1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,服务器1的状态一直属于Looking。
服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务器2胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是LOOKING。
服务器3启动,给自己投票,同时与之前启动的服务器1,2交换信息,由于服务器3的编号最大所以服务器3胜出,此时投票数正好大于半数,所以服务器3成为leader,服务器1,2成为follower。
服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服务器4的编号大,但之前服务器3已经胜出,所以服务器4只能成为follower。
服务器5启动,后面的逻辑同服务器4成为follower。
zookeeper安装:
* 下载地址传送门:
zookeeper下载:链接:http://pan.baidu.com/s/1o78IBsY 密码:xh3k
* 解压到modules目录中
* 修改配置文件(cp -a命令意为保留原文件属性的情况下,复制文件)
复制conf目录下的zoo_sample.cfg文件并重命名为zoo.cfg文件
$ cp -a zoo_sample.cfg zoo.cfg,执行后,如图:


对文件做如下修改:
$ vi zoo.cfg
dataDir=/opt/modules/zookeeper-3.4.5/zkData, 如图:
1240.jpg

创建这个目录:
$ mkdir /opt/modules/zookeeper-3.4.5/zkData
* 启动zookeeper
单节点启动,切换到zookeeper的安装根目录:
$ bin/zkServer.sh start
查看启动状态:
$ bin/zkServer.sh status,如图:
1240.jpg

** zookeeper集群的部署
集群规划如下:


* 修改zoo.cfg
dataDir=/opt/modules/zookeeper-3.4.5/zkData
server.1=192.168.122.200:2888:3888
server.2=192.168.122.201:2888:3888
server.3=192.168.122.202:2888:3888
注意:这里我使用的是三台服务器的ip地址,如图:
1240.jpg

* 添加myid文件,注意一定要在linux里面创建
$ vi zkData/myid
添加内容:1
* 把zookeeper目录拷贝给其他集群服务器
$ scp -r zookeeper-3.4.5/ z02:/opt/modules/
$ scp -r zookeeper-3.4.5/ z03:/opt/modules/
修改myid文件
z02 为 2
z03 为 3
* 依次启动所有集群服务
$ bin/zkServer.sh start
* 检查每个服务器的状态
$ bin/zkServer.sh status
一顿操作之后,如图:通过查看状态,可以发现,现在的leader服务器是z02,其他的服务器为follower。
1240.jpg

** NameNode的HA部署
目标: 防止单个namenode宕机以后,整个HDFS集群失效
集群规划:
1240.jpg

注意:建议配置之前把之前服务器配置备份一次,方便以后使用
$ cp -ra hadoop-2.5.0/ back-up-hadoop-2.5.0/,如图:


* 配置:hdfs-site.xml,如图:
1240.jpg

* 配置core-site.xml,如图:
1240.jpg

* 拷贝文件给其他服务器
删除三台服务器的数据目录,去每个机器上执行该命令:
$ rm -rf data/  
拷贝给其他两台服务器:
$ scp etc/hadoop/core-site.xml etc/hadoop/hdfs-site.xml  z02:/opt/modules/hadoop-2.5.0/etc/hadoop/
$ scp etc/hadoop/core-site.xml etc/hadoop/hdfs-site.xml  z03:/opt/modules/hadoop-2.5.0/etc/hadoop/
* 启动服务
* 在各个JournalNode节点上,输入以下命令启动journalnode服务:
$ sbin/hadoop-daemon.sh start journalnode
* 在[nn1]上,对其进行格式化,并启动
$ bin/hdfs namenode -format
$ sbin/hadoop-daemon.sh start namenode
* 在[nn2]上,同步nn1的元数据信息,并启动
$ bin/hdfs namenode -bootstrapStandby
$ sbin/hadoop-daemon.sh start namenode
* 在nn1中与nn2中查看jps进程如下图:
1240.jpg

* 浏览器浏览,以下两个地址均可以访问HDFS:
http://z01:50070/
http://z02:50070/
* 手动把nn1设置为active
$ bin/hdfs haadmin -transitionToActive nn1
以上为手动故障转移,如果我们想自动切换故障,需要进行如下配置,即开启故障自动转移功能
配置hdfs-site.xml
添加属性:
dfs.ha.automatic-failover.enabled.mycluster:true
配置core-site.xml
添加属性:
ha.zookeeper.quorum:z01:2181,z02:2181,z03:2181
* 拷贝文件给后面两台服务器
$ scp etc/hadoop/core-site.xml etc/hadoop/hdfs-site.xml z02:/opt/modules/hadoop-2.5.0/etc/hadoop/
$ scp etc/hadoop/core-site.xml etc/hadoop/hdfs-site.xml z03:/opt/modules/hadoop-2.5.0/etc/hadoop/
* 启动服务
$ bin/zkServer.sh start
* 关闭所有HDFS服务
在[nn1]执行:
$ sbin/stop-dfs.sh,如图:


启动zookeeper,初始化HA在Zookeeper中状态
$ bin/hdfs zkfc -formatZK
* 启动HDFS服务
在[nn1]执行:
$ sbin/start-dfs.sh
$ bin/hdfs haadmin -transitionToActive nn1
nn1与nn2的jps如图所示:
1240.jpg

* 查看活跃状态
$ bin/hdfs haadmin -getServiceState nn1
$ bin/hdfs haadmin -getServiceState nn2
如图:


* 测试,访问如下站点也可以查看NameNode的活跃状态:
http://z01:50070/
http://z02:50070/
此时kill掉active的NameNode进程,查看standby状态会自动切换到active
** Yarn的HA部署
目标: 防止单个resourcemanager宕机以后,整个YARN集群失效
集群规划:
1240.jpg

* 配置:yarn-site.xml,如图:
1240.jpg

* 拷贝给其他服务器并修改
$ scp etc/hadoop/yarn-site.xml z02:/opt/modules/hadoop-2.5.0/etc/hadoop/
$ scp etc/hadoop/yarn-site.xml z03:/opt/modules/hadoop-2.5.0/etc/hadoop/
* 启动每个服务器的服务
通过jps查看每个服务器的zookeeper服务QuorumPeerMain已经运行,没有运行则开启,方式前文已经说过,不再赘述。
在 z02中:
$ sbin/start-yarn.sh
在z03中:
$ sbin/yarn-daemon.sh start resourcemanager
查看服务状态:
$ bin/yarn rmadmin -getServiceState rm1
$ bin/yarn rmadmin -getServiceState rm2
如图:


测试:
运行我们之前打好的jar包,进行wordcount实例运算,在运算过程中kill掉active的rm,观察任务运行。
先开启HDFS服务(忘记的请看上边的内容),再上传一个words.txt文档到HDFS,再开始单词统计,涉及命令:
$ bin/hdfs dfs -mkdir /input/
$ bin/hdfs dfs -mkdir /input/words/
$ bin/hdfs dfs -put words.txt /input/words/
如图:
1240.jpg

$ bin/yarn jar MyWordCount.jar /input/words/words.txt /output/
** 总结
这一节简单介绍了zookeeper并阐述其工作原理,成功使用zookeeper部署了NameNode HA和Resourcemanager HA。

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /3 下一条

Archiver|手机版|小黑屋|可可云计算 ( 京ICP备13045856号  

GMT+8, 2018-5-24 12:24 , Processed in 0.110942 second(s), 35 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表