高可用HA和搭建Zookeeper

HDFS2.xHA技术

标签（空格分隔）： Hadoop:高可用HA
Hadoop1.0中HDFS和MapReduce在高可用和扩展性上存在着一些问题
1.HDFS存在问题：
1）NameNode单点故障，难于应用于在线的场景
2）namenode压力过大，且内存受限，影响扩展
2.MapReduce存在的问题
1）JobTracker访问压力过大，影响扩展

3.hadoop2.x是由于HDFS MapReduce YARN三部分组成
HDFS：支持联邦，HA
1）2.x支持两个NameNode主从框架
NameNode—>多个DataNode
NameNode单点故障，namenode对外提供服务，备NameNode防止主挂了充当新的主
2）3.x实现一个新的一主多备
MapReduce是运行在yarn的基础上，基于离线计算
YARN：资源管理系统
单点压力过大：
水平扩展，自持多个NameNode
所有的NameNode共享所有dataNode的存储资源
每一个NameNode分管一部分目录

4.什么是应用程序的高可用：
高可用性(high availability 简称HA)：通常用来描述一个系统经过专门的设计，从而减少停工时间，而保持服务的高度可用性

5.高可用程序的类型
1）主从方式（冷备）
两个相同的应用程序，一个对外提供服务称为主程序，另外一个平时不运行（只要负责跟对外提供服务的主机进行数据备份）称为备程序，就是一个程序的备份
一旦主出现问题，备份提供恢复操作
2）双主互备(热备)
两个相同的应用程序，同时对外提供服务（这两个从互相作为对方备份而存在，双主热备）当启动一个出现问题时，另外一个可以对外提供服务，不会造成服务器宕机。
绿色部分：
单独来讲绿色部分就已经是HA (手动HA)
Namenode:用来存储元数据使用的
NameNode中的元数据是用来增删查改和DataNode汇报块信息的位置
Namenode和DataNode之间使用心跳进行联系

现在我们要做HA：
客户端只能访问Active的NameNode，所以数据应该存储在当前NameNode中，那么standby的NameNode是不是应该存储相同的数据？
这样一来，active的NameNode，NN的单点故障，standby的NN，起到一样的作用，就必须同步当前的ActiveNN中的数据

问题：如何将运输的元数据传递给standbyNN?

假设：我们拿到了NameNode的源码，我们进行修改，使用一种什么方式可以进行数据传输？
因为hadoop的编写是Java所编写，数据传输应该使用流
因为是服务器，服务器和服务器之间的连接使用的是网线，网络流
网络流—>TCP/IP–>socket
我们就可以使用哪个Socket的方式进行数据传输
通过上述的分析，此时我们只需要创建Socket连接就可完成ActiveNN和StandbyNN之间的数据通信
如何解决数据通信问题，也就是数据一致性问题
针对状态，可以借助一个共享村塾系统来实现

提供三个解决方案：
1。NFS(NetWorkFile System)系统是Linux锁提供的，并且Linux系统中使用的这个服务进行数据存储，实现起来比较麻烦
2.QJM（Quorum Journal Manager）—>
3.zookeeper

总结：

1)hadoop1.x:
SecondaryNameNode他不是HA，它只是用来阶段合并edit和fsimage以及缩短集群启动时间所使用，默认是1小时进行一次整合，当NN失效色的时候，当NN实现的时候，SNN并无法立即提供服务，SNN是无法保证数据完整性
2）hadoop2.x
提供了QJM 的系统来解决当前NameNode的单点故障

1.QJM的基本原理是基于2N+1每次需要对数据进行操作，完成一个过半机制（>= N+1）会返回成功，数据不会丢失，当前这个算法容忍最多N台机器挂掉
2.HA框架中，SNN这个冷备已经不存在了，为了保持standbyNN实时的和ActiveNN的数据保持一致，他们会开启一个进程–实时监控 JN (JournalNode)
3.任何更改操作在ActiveNN上执行，JN进程同时记录并且会修改log
这个standby检测到JN中有数据同步，log发生 变化，就会同步当前数据
4.当发生故障的时候，ActiveNN挂了，StandbyNN会提升为新的ActiveNN，会读取JN里面修改的日志，这样就可以提供可靠性
5.QJM技术：
5.1不需要配置额外的高共享存储，减少复杂度和维护成本
5.2系统健壮性得到了增强
5.3JN不会因为其中一台延迟，而影响整体，也不会因为JN的政所而影响性能

zookeeper：

zkfc是依赖于zookeeper而存在的
zookeeper是一个分布式开源应用协调程序，是Google的一个开源项目，是Hadoop集合Hbase的重要组件，它是一个为分布式应用所提供的一致性服务的软件，只要提供：配置的维护，域名服务，分布式同步等。

集群角色

在zookeeper中没有主从概念，而是引用了新的机制Leader（头）,Follower(随从)和Observer（观察者）三种角色
zookeeper集群中所有的机器通过一个Leader来管理，Leader通过选举机制产生的，Leader服务器对客户端进行服务，除Leader外，其他机器，包括Follower和Observer，Follower和Observer都能够提供读取服务，区别在于Observer机器不残疾Leader的选举，zookeeper中也提供另外一个

注意：zookeeper的server必须是奇数

zookeeper中的每个server都是自私的
这几个server之间只有一个leader
ps：zk服务器的个数必须是奇数3,5,7,9这个服务器的配置需要太多

会话：Session
Session是指客户会话，在zookeeper中，一个客户端在连接服务器之间会建立一个TCP长连接，Zookeeper对外的服务器端口是2181，客户端启动是后，首先和服务器创建连接，从第一次连接开始的时候，客户端会话的声明周期就开始了，，通过这个连接，客户端能够心跳检测这个服务器保持又能保持有效的会话，也能够向Zookeeper的服务器发送请求和接收响应，同时还用该连接来接收来自服务器的watch时间通知，Session会使用Session TimeOut的值来设置一个客户端会话超时的事件，当由于服务器的压力太大，或网络故障或是客户端注定断开连接等因素锁导致的客户端断开，只要在Session TimeOut规定的事件内能够重新连接到集群上任意一台服务器，那么之前创建的会话仍然有效

zookeeper的数据结构特点：

在 分布式中我们通常说“节点”是指组成集群中的每一台机器，然而在Zookeeper中节点分为两类
1.同样指的是集群中的机器—>机器节点
2.是指数据模型中的数据单元–>Znode

每个 子目录项如 app1 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 p1这个 znode 的标识为/app1/p1znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL(ephemeral/ə’fɛmərəl/)类型的目录节点不能有子节点目录znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了znode 的目录名可以自动编号，如 app1 已经存在，再创建的话，将会自动命名为 app2znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例

和传统文件系统区别

共同点:树形文件系统,都可以存储数据
不同点:传统的文件系统专门用于存储大量数据,zk的存储少量数据
传统的文件系统目录和文件分明,zk即使文件也是文件目录
每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
节点Znode可以包含数据和子节点（但是EPHEMERAL类型的节点不能有子节点）
客户端应用可以在节点上设置监视器
节点类型

Znode有两种类型：

短暂（ephemeral）（断开连接自己删除）
持久（persistent）（断开连接不删除）
Znode有四种形式的目录节点（默认是persistent ）
PERSISTENT 持久类型
PERSISTENT_SEQUENTIAL（持久序列类型/test0000000019 ）sequential
EPHEMERAL 短暂类型
EPHEMERAL_SEQUENTIAL 短暂序列类型
创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护
在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序

Zookeeper设计目的

1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。第一个
clinet上传了数据 其他client在访问得到的是同一个数据
2.可靠性：具有简单、健壮、良好的性能，如果消息被到
一台服务器接受，那么它将被所有的服务器接受。
3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得
服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到
刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4.等待无关（wait-free）：慢的或者失效
的client不得干预快速的client的请求，使得每个client都能有效的等待。
5.原子性：更新只能成功或者失败，没有
中间状态。
6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上
消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
HA:Zookeeper部分

总结:

1.Hadoop中提供了ZKFailoverController交涉,部署在每个namenode所在的基点上,做一个进程进行监控简称ZKFC
ZKFailoverController主要包含三个组件
1.HealthMonitor:监控当前namenode时候出健康(活着)或不健康(死亡)状态,通过当前RPC来调用NN相应的方法来
完成
2.ActiveStandbyElector:管理和监控自己的zk中的状态
3.ZKFailoverController监听HealthMonitor和ActiveStandbyElector的时间来管理NN的状态
ZKFailoverController的主要职责:
**1.健康测试:**周期性的向它监控的NN发送健康探测命令,从而来确定某个NN是否处于健康的状态,若机器宕机,心跳失
败,那么zkfc就会标记当前出一个不健康的状态
集群/节点配置 NN NN DN ZK ZKFC JN
hadoop01 有 有 有
hadoop02 有 有 有 有 有
hadoop03 有 有 有
hadoop04 有 有
2.会话管理:如果NN是健康的,zkfc会和zk保持一个打开的会话状态,如果NN同时还是Active状态,那么zkfc还会在zk中
创建一个类型为短暂类型的znode,当这个NN挂掉,这个znode就会被删除,然后备用的NN将得到这个锁,升级为主
NN,同时被标记为Acitve
3.当宕机的NN重新启动的时候,他会再次注册zk,发现已经有znode锁了,它会自动变为standby状态
循环往复,就可以保证高可用的可靠性
4.zk中的leader是用过选举机制得到的

集群搭建

zookeeper的搭建：

1.必须停止集群为了以后方便，就让hadoop1-4之间互相免密
ps:这个集群配置hadoop1要和自身2-3免密hadoop2要和自身和134免密
2.将zookeeper3.4.7上传到hadoop2节点并解压到 /opt/software/下
命令：
tar -zxvf zookeeper-3.4.7.tar.gz -C /opt/software/
3.先配置zookeeper的环境变量vi /etc/profile

让文件生效 source /etc/profile
4.修改Zookeeper安装路径下的conf文件夹中的一个文件配置成Zookeeper集群
cd /opt/software/zookeeper-3.4.7/conf
需要修改将路径下的一个文件进行一个修改
[root@hadoop2 conf]# cp zoo_sample.cfg zoo.cfg
5.修改文件
vi zoo.cfg

6.上面的配置完成后需要将zookeeper中的文件夹分发给hadoop3和hadoop4
ps:下面的分发已经在/opt/software/所以使用./当前路径
scp -r ./zookeeper-3.4.7/hadoop3:/opt/software/
scp -r ./zookeeper-3.4.7/hadoop4:/opt/software/
7.分发完成后需要给hadoop3,hadoop4添加myid
先创建mkdir -p /var/software/zk
向路径下 追加文件并添加文件值：myid的值
echo 值 > /var/software/zk/myid
ps：Hadoo3 ---->2 4—>3
8.配置3和4中的 etc/profile
直接在hadoop2中进行分发即可
1）scp /etc/profile hadoop3:/etc/prrofile
2）scp /etc/profile hadoop4:/etc/prrofile
在3和4中重新加载profile文件
source /etc/profile
9.启动zookeeper集群
1)zkServer.sh start 是启动集群，执行顺序是2,3,4
2)zkServer.sh status 查看当前集群状态
3)zkServer.sh stop 停止集群

集群HA：

1.修改hadoop1中的hadoop配置文件 hdfs-site.xml
命令：vi /opt/software/hadoop-2.7.1/etc/hadoop/hdfs-site.xml

2.修改另外一个文件/opt/software/hadoop-2.7.1/etc/hadoop/core-site.xml
命令：
vi /opt/software/hadoop-2.7.1/etc/hadoop/core-site.xml

3.将修改完的配置分发给hadoop2,3,4各一份
scp /opt/software/hadoop-2.7.1/etc/hadoop/hdfs-site.xml
/opt/software/hadoop-2.7.1/etc/hadoop/core-site.xml hadoop2:/opt/software/hadoop-2.7.1/etc/hadoop/

scp /opt/software/hadoop-2.7.1/etc/hadoop/hdfs-site.xml
/opt/software/hadoop-2.7.1/etc/hadoop/core-site.xml hadoop3:/opt/software/hadoop-2.7.1/etc/hadoop/

scp /opt/software/hadoop-2.7.1/etc/hadoop/hdfs-site.xml /opt/software/hadoop-2.7.1/etc/hadoop/coresite.xml hadoop4:/opt/software/hadoop-2.7.1/etc/hadoop/

4.需要手工启动 journalnode
需要在1,2,3中执行：hadoopdaemon.sh start journalnode

5.需要在hadoop1中格式化NameNode
hdfs namenode -format
让hadoop1中的namenode要先跑起来hadoop-daemon.sh start namenode
jps可以查看一下确认跑起来
hadoop2中执行：
hdfs namenode -bootstrapStandby
需要在hadoop1中执行zkfc看格式化：
hdfs -zkfs -formatZK
就可以启动集群了

ps:如果集群关闭：启动顺序

1.先开启Zookeeper–>zkfc是依赖于zk 的
hadoop2,3,4先后执行zkServer.sh start
2.启动Hadoop集群
start-dfs.sh
3.通过jps 查看进程是否启动成功
hadoop-daemon.sh start namenode zkfc journalnode 单点启动