Hadoop框架基础（五）

** Hadoop框架基础（五）

已经部署了Hadoop的完全分布式集群，我们知道NameNode节点的正常运行对于整个HDFS系统来说非常重要，如果NameNode宕掉了，那么整个HDFS就要整段垮掉了，所以人类思考，能不能让世界多一点爱：），我们能不能弄个备用的NameNode，一旦正在使用的NameNode原地爆炸了，另一台备用的NameNode能立刻代替原先NameNode的位置，继续让HDFS系统正常运行？（同理，ResourceManager也是可以的。）

世界果然充满爱，动物管理员横空出世——zookeeper框架

** ZooKeeper

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

** 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原理简述

当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，那么将判断是不是有半数以上的服务器选举它，如果是则设置选举状态，选举结束。

* 否则这是一条与当前逻辑时钟不符合的消息，那么说明在另一个选举过程中已经有了选举结果，于是将该选举结果加入到集合中，再根据集合来判断是否可以结束选举，如果可以也是保存逻辑时钟，设置选举状态，选举结束。

原理引用网络上的一张图，如图所示：

在此举个例子：假设有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， 如图：

创建这个目录：

$ mkdir /opt/modules/zookeeper-3.4.5/zkData

* 启动zookeeper

单节点启动，切换到zookeeper的安装根目录：

$ bin/zkServer.sh start

查看启动状态：

$ bin/zkServer.sh status，如图：

** 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地址，如图：

* 添加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。

** NameNode的HA部署

目标： 防止单个namenode宕机以后,整个HDFS集群失效

集群规划：

注意：建议配置之前把之前服务器配置备份一次,方便以后使用

$ cp -ra hadoop-2.5.0/ back-up-hadoop-2.5.0/，如图：

* 配置core-site.xml，如图：

 

* 配置：hdfs-site.xml，如图：

* 拷贝文件给其他服务器

删除三台服务器的数据目录，去每个机器上执行该命令：

$ 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进程如下图：

* 浏览器浏览，以下两个地址均可以访问HDFS：

http://z01:50070/

http://z02:50070/

* 手动把nn1设置为active

$ bin/hdfs haadmin -transitionToActive nn1

以上为手动故障转移，如果我们想自动切换故障，需要进行如下配置，即开启故障自动转移功能

*关闭所有HDFS服务

在[nn1]执行：

$ sbin/stop-dfs.sh，如图：

配置core-site.xml

添加属性：

ha.zookeeper.quorum：z01:2181,z02:2181,z03:2181

配置hdfs-site.xml

添加属性：

dfs.ha.automatic-failover.enabled.mycluster：true

* 拷贝文件给后面两台服务器

$ 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/

* 启动Zookeeper服务

$ bin/zkServer.sh start

启动zookeeper，初始化HA在Zookeeper中状态

$ bin/hdfs zkfc -formatZK

*启动HDFS服务

在[nn1]执行：

$ sbin/start-dfs.sh

nn1与nn2的jps如图所示：

* 查看活跃状态

$ 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集群失效

集群规划：

* 配置：yarn-site.xml，如图：

* 拷贝给其他服务器并修改

$ 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/

如图：

$ bin/yarn jar MyWordCount.jar /input/words/words.txt /output/

** 总结

这一节简单介绍了zookeeper并阐述其工作原理，成功使用zookeeper部署了NameNode HA和Resourcemanager HA。


个人微博：http://weibo.com/seal13

QQ大数据技术交流群（广告勿入）：476966007


作者：Z尽际链接：https://www.jianshu.com/p/b39f71b1522b來源：简书著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

原文地址：https://www.cnblogs.com/wzlbigdata/p/8277648.html

时间： 2024-10-03 10:19:07

Hadoop框架基础（五）的相关文章

Hadoop 框架基础（四）

** Hadoop 框架基础(四) 上一节虽然大概了解了一下 mapreduce,徒手抓了海胆,不对,徒手写了 mapreduce 代码,也运行了出来.但是没有做更深入的理解和探讨. 那么-- 本节目标: * 深入了解 mapreduce 过程 * 成功部署 Hadoop 集群 ** mapreduce 原理 想要了解 mapreduce 原理,我们必须搞清楚处理数据时的每一个重要阶段,首先,贴上一张官方的图: 我们依次讨论每一个过程以及该过程对应的作用: 我先在这里假设一个情景,我现在有一个

HBase框架基础（五）

* HBase框架基础(五) 本节主要介绍HBase中关于分区的一些知识. * HBase的RowKey设计 我们为什么要讨论rowKey的设计?或者说为什么很多工作岗位要求有rowKey的优化设计经验?这个我们需要简单的谈一谈HBase的存储情景. 简单讨论: ** 一个Table表可以划分为多个Region ** 每个Regin维护着不同的范围的rowKey,如何维护呢?Region提供了StartKey和EndKey来表示某一个范围内的rowKey,比如,我们有3个Region,维护的ro

从hadoop框架与MapReduce模式中谈海量数据处理

前言 几周前,当我最初听到,以致后来初次接触Hadoop与MapReduce这两个东西,我便稍显兴奋,觉得它们很是神秘,而神秘的东西常能勾起我的兴趣,在看过介绍它们的文章或论文之后,觉得Hadoop是一项富有趣味和挑战性的技术,且它还牵扯到了一个我更加感兴趣的话题:海量数据处理. 由此,最近凡是空闲时,便在看“Hadoop”,“MapReduce”“海量数据处理”这方面的论文.但在看论文的过程中,总觉得那些论文都是浅尝辄止,常常看的很不过瘾,总是一个东西刚要讲到紧要处,它便结束了,让我好生“愤懑

从Hadoop框架与MapReduce模式中谈海量数据处理（含淘宝技术架构）

从hadoop框架与MapReduce模式中谈海量数据处理 前言 几周前,当我最初听到,以致后来初次接触Hadoop与MapReduce这两个东西,我便稍显兴奋,认为它们非常是神奇,而神奇的东西常能勾起我的兴趣,在看过介绍它们的文章或论文之后,认为Hadoop是一项富有趣味和挑战性的技术,且它还牵扯到了一个我更加感兴趣的话题:海量数据处理. 由此,近期凡是空暇时,便在看"Hadoop","MapReduce""海量数据处理"这方面的论文.但在看论

海量数据处理之从Hadoop框架与MapReduce模式中谈海量数据处理（淘宝技术架构）

几周前,当我最初听到,以致后来初次接触Hadoop与MapReduce这两个东西,我便稍显兴奋,觉得它们很是神秘,而神秘的东西常能勾起我的兴趣,在看过介绍它们的文章或论文之后,觉得Hadoop是一项富有趣味和挑战性的技术,且它还牵扯到了一个我更加感兴趣的话题:海量数据处理. 由此,最近凡是空闲时,便在看"Hadoop","MapReduce""海量数据处理"这方面的论文.但在看论文的过程中,总觉得那些论文都是浅尝辄止,常常看的很不过瘾,总是一个东

Hive框架基础（二）

* Hive框架基础(二) 我们继续讨论hive框架 * Hive的外部表与内部表 内部表:hive默认创建的是内部表 例如: create table table001 (name string , age string) location '/input/table_data'; 此时:会在HDFS上新建一个table001表的数据存放地 接着执行: load data inpath'/input/data 'into table table001;(注意,load关键字后没有跟local关

hadoop rpc基础

第一部分: hadoop rpc基础 RPC,远程程序调用,分布式计算中C/S模型的一个应用实例. 同其他RPC框架一样,Hadoop分为四个部分: 序列化层:支持多种框架实现序列化与反序列化 函数调用层:利用java反射与动态代理实现 网络传输层:基于TCP/IP的Socket机制 服务的处理框架:基于Reactor模式的事件驱动IO模型 Hadoop RPC主要对外提供2种接口 public static ProtocolProxy getProxy/waitForProxy: 构造一个客户

企业级应用框架（五）IOC容器在框架中的应用

前言 在上一篇我大致的介绍了这个系列所涉及到的知识点,在本篇我打算把IOC这一块单独提取出来讲,因为IOC容器在解除框架层与层之间的耦合有着不可磨灭的作用.当然在本系列前面的三篇中我也提供了一种基于反射的解耦方式,但是始终不是很优雅,运用到项目中显得别扭.目前,我所掌握的IOC容器主要有两个:一个是 unity,另一个则是spring.net,经过慎重的思考我还是决定选择unity 2.0做为本系列的IOC容器,原因主要有两个:第一,他是一个轻量级的容器且师出名门(微软),第二,它提供了简单的拦

将 Shiro 作为应用的权限基础 五：SpringMVC+Apache Shiro+JPA(hib

点击链接加入群[JavaEE(SSH+IntelliJIDE+Maven)]:http://jq.qq.com/?_wv=1027&k=L2rbHv 将 Shiro 作为应用的权限基础 五:SpringMVC+Apache Shiro+JPA(hibernate)整合配置 配置web.xml,applicationContext.xml, spring-mvc.xml,applicationContext-shiro.xml,而且都有详细的说明. web.xml是web项目最基本的配置文件,看这