【HDFS篇】基于HA的hadoop集群分析及搭建（ZK+zkfc）

简介:
Hadoop 1.0中HDFS和MapReduce在高可用、扩展性等方面存在问题
HDFS存在的问题
NameNode单点故障，难以应用于在线场景 HA
NameNode压力过大，且内存受限，影扩展性 F
MapReduce存在的问题响系统
JobTracker访问压力大，影响系统扩展性
难以支持除MapReduce之外的计算框架，比如Spark、Storm
HDFS HA 解决单点故障使用2个NN， 一个主一个备。
HDFS Federation 水平拓展，支持多个DN。
每个NN分管一部分目录，所有的NN共享所有的DN存储资源。

1.客户端和NN通信的时候只和active NN。不和备机通信，当主挂了，被升级成主后再通信。

中间的JN是基于集群的Journal Node，也可以用NFS文件服务器，但是有单点故障问题。他们存的是edits日志信息。异地备份的作用是的数据可靠性大大增加。
FailoverControllerAdtive 是ZKFC，其为基于ZK的故障转移。它和NN可以在一台物理服务器上，也可以是在其他的单独的服务器上，但是需要多个来判定NN是否有故障。其是单独的JVM进程。
他们会去zk上争抢主备NN .它跟Zk之间有回调，来保持NN 的稳定， 如果ZKFC自己挂了，ZK会检测到，然后把备机的NN升为主NN同时备机会把原来的主机再次降为备，确保不会有2个主。

搭建带有HA的hadoop集群。使用zookeeper协调服务。

相对于无HA的完全分布式搭建的过程，加上HA后，首先要考虑的是，node02对node01的免密钥以及node02对自己的免密钥。因为，如果node01的zkfc挂了，node02的zkfc会首先把node02的NN变成主，然后降低node01为备机。因此这个过程需要免密钥。
搭建之前需要考虑它的前置依赖。需要先处理zk，【ZK集群是可以共享的，多个HDFS的集群可共享ZK，每个HDFS集群的zkfc去共享的zk集群争抢创建的节点，但是不会冲突，因为formatZK的时候会给不通的集群创建不同的目录】
在node02先装zk。
1.解压并修改/etc/profile文件
2.修改conf下的配置文件重命名 cp zoo_sample.cfg zoo.cfg
3.vi zoocfg 修改其中的
dataDir= 为一个自定义的位置 /var/jw/zk
在底部新增如下的配置：
server.1=192.168.159.37:2888:3888
server.2=192.168.159.38:2888:3888
server.3=192.168.159.39:2888:3888
将/etc/profile文件和node02的zk文件分发给node03和node04
4.启动node03的zk
zkServer.sh start Starting zookeeper … STARTED
zkServer.sh status Error contacting service. It is probably not running.
netstat -natp | grep 2181
tcp 0 0 :::2181 :::* LISTEN 7148/java
说明已经跑起来了，但是不可用，原因是还没其他集群和他一组组建势力范围还没有过半 ,此时启动node02 会发现02的状态是：Mode: follower 而03 的状态为：Mode: lead
同理node04同样是follower 。
5.hadoop集群操作
备份原始的hadoop的目录为hadoop-full为不带HA的版本。
修改etc下的hdfs.xml文件
删除原有的secondary NN的配置信息。

<property>
  <name>dfs.nameservices</name>
  <value>mycluster</value>
</property>
<property>
  <name>dfs.ha.namenodes.mycluster</name>
  <value>nn1,nn2</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn1</name>
  <value>node01:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn2</name>
  <value>node02:8020</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn1</name>
  <value>node01:50070</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn2</name>
  <value>node02:50070</value>
</property>

<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>qjournal://node01:8485;node02:8485;node03:8485/mycluster</value>
</property>

<property>
  <name>dfs.journalnode.edits.dir</name>
  <value>/var/jw/hadoop/ha/jn</value>
</property>


<property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
  <name>dfs.ha.fencing.methods</name>
  <value>sshfence</value>
</property>
<property>
  <name>dfs.ha.fencing.ssh.private-key-files</name>
  <value>/root/.ssh/id_dsa</value>
</property>

<property>
   <name>dfs.ha.automatic-failover.enabled</name>
   <value>true</value>
 </property>

core-site.xml 改为

     19 
     20 <configuration>
     21     <property>
     22         <name>fs.defaultFS</name>
     23         <value>hdfs://mycluster</value>
     24     </property>
     25     <property>
     26         <name>hadoop.tmp.dir</name>
     27         <value>/var/sxt/hadoop/ha</value>
     28     </property>
     29 </configuration>
     30 
     31 <property>
     32    <name>ha.zookeeper.quorum</name>
     33    <value>node02:2181,node03:2181,node04:2181</value>
     34  </property>

然后分发这2个文件到node02 node03 node04 上

6.启动JN
hadoop-daemon.sh start journalnode
然后分别启动剩下的JN。

7.初始化NN
hdfs namenode -format
然后去var目录下检查是否生成dfs文件。

8.启动NN
hadoop-daemon.sh namenode

9.node02启动申请VERSION文件
hdfs namenode -bootstrapStandy
此时查看/var/jw/hadoop/ha/ 会发现多出来dfs的文件夹。这是同步node01的数据。

10.开启自动化
开启zkfc ，此前依赖是格式化 zk。
启动一个zk的客户端查看， zkCli.sh
通过help查看，用 ls / 可查看根目录下只有zookeeper目录。
hdfs zkfc -formatZK 此是再在客户端查看，[hadoop-ha, zookeeper] 多出来一个ha的目录。只是创建了一个目录而已。

最后启动集群：start-dfs.sh

[root@node01 name]# start-dfs.sh 
Starting namenodes on [node01 node02]
node01: namenode running as process 2104. Stop it first.
node02: starting namenode, logging to /opt/jw/hadoop-2.6.5/logs/hadoop-root-namenode-node02.out
node04: starting datanode, logging to /opt/jw/hadoop-2.6.5/logs/hadoop-root-datanode-node04.out
node03: starting datanode, logging to /opt/jw/hadoop-2.6.5/logs/hadoop-root-datanode-node03.out
node02: starting datanode, logging to /opt/jw/hadoop-2.6.5/logs/hadoop-root-datanode-node02.out
Starting journal nodes [node01 node02 node03]
node01: journalnode running as process 1980. Stop it first.
node03: journalnode running as process 1571. Stop it first.
node02: journalnode running as process 1730. Stop it first.
Starting ZK Failover Controllers on NN hosts [node01 node02]
node01: starting zkfc, logging to /opt/jw/hadoop-2.6.5/logs/hadoop-root-zkfc-node01.out
node02: starting zkfc, logging to /opt/jw/hadoop-2.6.5/logs/hadoop-root-zkfc-node02.out

jps检查角色，可在刚才开启的zkfc客户端的地方检查：
ls /hadoop-ha/mycluster 发现多出[ActiveBreadCrumb, ActiveStandbyElectorLock]
获取其中的数据：
get /hadoop-ha/mycluster/ActiveBreadCrumb

11.node02对自己和node01免密钥
node02上：
ssh -keygen -t dsa -P ” -f /root/.ssh/id_dsa.pub
cat id_dsa.pub >> authourized_keys
然后在node01上追加密钥文件。

测试：
第一种测试.弄死NN
kill -9 node01的NN
然后测试返现node02 由standby 便成立了active.

启动node01的NN，访问发现变成了standby。
可通过： get /hadoop-ha/mycluster/ActiveBreadCrumb 查看谁是活跃的节点。

第二种测试：弄死ZKFC
测试node02由active变成了standby
备注：开启zkfc 使用 hadoop-daemon.sh start zkfc

总结：
启动NN的前依赖是zkfc。使用zkfc的前依赖是格式化zk