linux-hadoop高可用集群和Zookeeper

1.hadoop高可用集群
  hadoop高可用集群的配置环境和hadoop分布式部署的配置环境一样。不同的是hadoop的分布式部署只有一个master，其余节点都是leader；而hadoop的高可用集群中通常有两台不同的主机充当 NN (NN是指namenode，也就是master)，其中一个master正常工作，状态为 Active ，另一个master用作备用，状态为 Standby ，当 Active NN 发生故障不能工作时它负责接管工作，如果必要,可以提供快速的故障恢复。
  Standby NN想要接管工作就必须和 Active NN 的状态保持同步（元数据保持一致），它们都将会和JournalNodes守护进程通信。当Active NN 执行任何有关命名空间的修改,它需要持久化到一半以上的 JournalNodes 上(通过edits log 持久化存储),而 Standby NN 负责观察 edits log的变化,它能够读取从JNs 中读取 edits 信息,并更新其内部的命名空间。一旦 Active NN出现故障, Atandby NN 将会保证从 JNs 中读出了全部的 Edits,然后切换成 Active 状态。Standby NN 读取全部的 edits 可确保发生故障转移之前,是和 Active NN 拥有完全同步的命名空间状态。为了提供快速的故障恢复,StandbyNN 也需要保存集群中各个文件块的存储位置。为了实现这个,集群中所有的 Database 将配置好 Active NN 和 Standby NN 的位置,并向它们发送块文件所在的位置。
  任何时候,集群中都只能有一个 NN 处于 Active 状态。否则,在两个 Active NN的状态下 NameSpace 状态将会出现分歧,这将会导致数据的丢失及其它不正确的结果。为了保证这种情况不会发生,在任何时间,JNs 只允许一个 NN 充当writer。在故障恢复期间,将要变成 Active 状态的 NN 将取得 writer 的角色,并阻止另外一个 NN 继续处于 Active状态。

2.部署Hadoop高可用集群
  <1> NameNode machines:运行 Active NN 和 Standby NN 的机器需要相同的硬件配置;
  <2> JournalNode machines:也就是运行 JN 的机器。JN 守护进程相对来说比较轻量,所以这些守护进程可以可其他守护线程(比如 NN,YARN ResourceManager)运行在同一台机器上。在一个集群中,最少要运行 3 个 JN 守护进程,这将使得系统有一定的容错能力。当运行 N 个 JN时,系统将最多容忍(N-1)/2 个 JN 崩溃。
  <3> 在Hadoop高可用集群中,Standby NN 也执行namespace 状态的 checkpoints,所以不必要运行Secondary NN、CheckpointNode和BackupNode，事实运行这些守护进程是错误的。

(1) Zookeeper集群至少三台,总节点数为奇数个。
[hadoop@server2 ~]$ tar zxf zookeeper-3.4.9.tar.gz      ##解压安装zookeeper
[hadoop@server2 ~]$ cp zookeeper-3.4.9/conf/zoo_sample.cfg zoo.cfg
[hadoop@server2 ~]$ vim zookeeper-3.4.9/conf/zoo.cfg
vim:(在最后面写)
server.1=172.25.0.2:2888:3888
server.2=172.25.0.3:2888:3888
server.3=172.25.0.4:2888:3888
:wq
各节点配置文件相同,并且需要在/tmp/zookeeper 目录中创建 myid 文件,写入一个唯一的数字，取值范围在1-255。

接下来在各节点启动服务:
[hadoop@server2 ~]$ hadoop/bin/zkServer.sh start
[hadoop@server2 ~]$ hadoop/bin/zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /home/hadoop/zookeeper-3.4.9/bin/../conf/zoo.cfg
Mode: leader        ##本节点是一个leader
bin/zkCli.sh -server 127.0.0.1:2181 ##连接 zookeeper

配置参数详解:
clientPort  ##客户端连接server的端口,即对外服务端口,一般设置为2181
dataDir     ##存储快照文件snapshot的目录。默认情况下,事务日志也会存储在这里。建议同时配置参数 dataLogDir, 事务日志的写性能直接影响 zk 性能。
tickTime    ##ZK中的一个时间单元。ZK中所有时间都是以这个时间单元为基础,以毫秒计,用来调节心跳和超时。
dataLogDir  ##事务日志输出目录。尽量给事务日志的输出配置单独的磁盘或是挂载点,这将极大的提升ZK 性能。
globalOutstandingLimit      ##最大请求堆积数。默认是 1000 ZK运行的时候, 尽管server已经没有空闲来处理更多的客户端请求了,但是还是允许客户端将请求提交到服务器上来,以提高吞吐性能。当然,为了防止 Server 内存溢出,这个请求堆积数还是需要限制下的。
preAllocSize    ##预先开辟磁盘空间,用于后续写入事务日志。默认是 64M,每个事务日志大小就是 64M。
snapCount   ##每进行snapCount 次事务日志输出后,触发一次快照(snapshot),此时,ZK 会生成一个snapshot.*文件,同时创建一个新的事务日志文件 log.*。默认是 100000.(真正的代码实现中,会进行一定的随机数处理,以避免所有服务器在同一时间进行快照而影响性能)
traceFile   ##用于记录所有请求的 log,一般调试过程中可以使用,但是生产环境不建议使用,会严重影响性能。
maxClientCnxns  ##单个客户端与单台服务器之间的连接数的限制,是ip级别的,默认是60,如果设置为0,那么表明不作任何限制。请注意这个限制的使用范围,仅仅是单台客户端机器与单台 ZK服务器之间的连接数限制,不是针对指定客户端 IP,也不是 ZK集群的连接数限制,也不是单台 ZK 对所有客户端的连接数限制。
clientPortAddress   ##对于多网卡的机器,可以为每个 IP 指定不同的监听端口。默认情况是所有 IP 都监听
clientPort ##指定的端口。 New in 3.3.0
minSessionTimeoutmaxSessionTimeout  ##Session超时时间限制,如果客户端设置的超时时间不在这个范围,那么会被强制设置为最大或最小时间。
fsync.warningthresholdms    ##事务日志输出时,如果调用 fsync 方法超过指定的超时时间,那么会在日志中输出警告信息。默认是 1000ms
autopurge.purgeInterval     ##在上文中已经提到,3.4.0及之后版本,ZK 提供了自动清理事务日志和快照文件的功能,这个参数指定了清理频率,单位是小时,需要配置一个 1 或更大的整数,默认是 0,表示不开启自动清理功能。
autopurge.snapRetainCount   ##这个参数和上面的参数搭配使用,这个参数指定了需要保留的文件数目。默认是保留 3个。
initLimitFollower   ##在启动过程中,会从 Leader 同步所有最新数据,然后确定自己能够对外服务的起始状态。Leader 允许 F 在initLimit 时间内完成这个工作。通常情况下,我们不用太在意这个参数的设置。如果 ZK 集群的数据量确实很大了,F 在启动的时候,从 Leader 上同步数据的时间也会相应变长,因此在这种情况下,有必要适当调大这个参数了。
syncLimit   ##在运行过程中,Leader 负责与 ZK 集群中所有机器进行通信,例如通过一些心跳检测机制,来检测机器的存活状态。如果 L 发出心跳包在 syncLimit 之后,还没有从 F 那里收到响应,那么就认为这个 F 已经不在线了。注意:不要把这个参数设置得过大,否则可能会掩盖一些问题。
leaderServes    ##默认情况下,Leader 是会接受客户端连接,并提供正常的读写服务。但是,如果你想让Leader 专注于集群中机器的协调,那么可以将这个参数设置为 no,这样一来,会大大提高
写操作的性能。
server.x=[hostname]:nnnnn[:nnnnn]   ##这里的 x 是一个数字,与 myid 文件中的 id 是一致的。右边可以配置两个端口,第一个端口用于 F 和 L 之间的数据同步和其它通信,第二个端口用于 Leader 选举过程中投票通信。
group.x=nnnnn[:nnnnn]weight.x=nnnnn ##对机器分组和权重设置,可以 参见这里(No Java system property)
cnxTimeout  ##Leader 选举过程中,打开一次连接的超时时间,默认是5s
zookeeper.DigestAuthenticationProvider.superDigest  ##ZK权限设置相关,具体参见《使用super身份对有权限的节点进行操作》和《ZooKeeper 权限控制》
skipACL     ##对所有客户端请求都不作 ACL 检查。如果之前节点上设置有权限限制,一旦服务器上打开这个开头,那么也将失效。(Java system property:zookeeper.skipACL)
forceSync   ##这个参数确定了是否需要在事务日志提交的时候调用 FileChannel.force 来保证数据完全同步到磁盘。
jute.maxbuffer  ##每个节点最大数据量,是默认是 1M。这个限制必须在server 和 client 端都进行设置才会生效。

(2)Hadoop配置
[hadoop@server2 ~]$ vim hadoop/etc/hadoop/core-site.xml     ##编辑core-site.xml文件
vim:
<!-- 指定 hdfs 的 namenode 为 masters (名称可自定义)-->
<property>
<name>fs.defaultFS</name>
<value>hdfs://masters</value>
</property>
<!-- 指定 zookeeper 集群主机地址-->
<property>
<name>ha.zookeeper.quorum</name>
<value>172.25.0.2:2181,172.25.0.3:2181,172.25.0.4:2181</value>
</property>
:wq
[hadoop@server2 ~]$ vim hadoop/etc/hadoop/hdfs-site.xml     ##编辑hdfs-site.xml文件

(3)启动hdfs集群(按顺序启动)
1> 在三个DN上依次启动zookeeper集群
[hadoop@server2 ~]$ bin/zkServer.sh
start
[hadoop@server2 ~]$ jps
1222 QuorumPeerMain
1594 Jps
2>在三个 DN 上依次启动 journalnode(第一次启动 hdfs 必须先启动 journalnode)
[hadoop@server2 ~]$ sbin/hadoop-daemon.sh start journalnode
[hadoop@server2 ~]$ jps
1493 JournalNode
1222 QuorumPeerMain
1594 Jps
3>格式化 HDFS 集群
[hadoop@server2 ~]$ bin/hdfs namenode -format
Namenode 数据默认存放在/tmp,需要把数据拷贝到h2
[hadoop@server2 ~]$ scp -r /tmp/hadoop-hadoop 172.25.0.5:/tmp
4>格式化 zookeeper (只需在 h1 上执行即可)
[hadoop@server2 ~]$ bin/hdfs zkfc -formatZK
[hadoop@server2 ~]$ sbin/start-dfs.sh
5>查看各节点状态
[hadoop@server1 hadoop]$ jps    ##server1和server5是masster
1431 NameNode
1739 DFSZKFailoverController
2013 Jps
[hadoop@server2 ~]$ jps     ##server2,server3和server4是leader
1493 JournalNode
1222 QuorumPeerMain
1400 DataNode
1594 Jps
在浏览器上测试
172.25.0.1:50070
6>测试故障自动切换
[hadoop@server1 hadoop]$ jps
1431 NameNode
2056 Jps
1739 DFSZKFailoverController
[hadoop@server1 hadoop]$ kill -9 1431
[hadoop@server1 hadoop]$ jps
1739 DFSZKFailoverController
2089 Jps
[hadoop@server1 hadoop]$ bin/hdfs dfs -lsFound 1 items
drwxr-xr-x
- hadoop supergroup
0 2017-03-04 17:39 input
杀掉server1主机的 namenode进程后依然可以访问,此时server5 转为active状态接
管namenode。
[hadoop@server1 hadoop]$ sbin/hadoop-daemon.sh start namenode   ##启动 h1 上的 namenode,此时为standby状态。
在浏览器上测试:
172.25.0.1:50070    ##server1为standby状态
172.25.0.5:50070    ##server5为active状态
hadoop的高可用集群配置完毕

3.yarn的高可用
[hadoop@server1 ~]$ vim hadoop/etc/hadoop/mapred-site.xml   ##编辑mapred-site.xml文件
vim:
<!--
指定 yarn 为 MapReduce 的框架 --><property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
:wq
[hadoop@server1 ~]$ vim hadoop/etc/hadoop/yarn-site.xml     ##编辑yarn-site.xml文件
[hadoop@server1 ~]$ hadoop/sbin/start-yarn.sh
hadoop@server1 hadoop]$ jps
6559 Jps
2163 NameNode
1739 DFSZKFailoverController
5127 ResourceManager

server2需要手动启动
[hadoop@server1 ~]$ hadoop/sbin/yarn-daemon.sh start resourcemanager
最好把 RM 与 NN 分离运行

yarn故障切换测试:
[hadoop@server1 hadoop]$ jps
5918 Jps
2163 NameNode
1739 DFSZKFailoverController
5127 ResourceManager
[hadoop@server1 hadoop]$ kill -9 5127