大数据学习-Hadoop生态章---(二) HA高可用

大数据学习-Hadoop生态章

---

(二) HA高可用

2.1. Hadoop 2.0产生背景

Hadoop 1.0中HDFS和MapReduce在高可用、扩展性等方面存在问题。

• HDFS存在的问题（如下图）：

1. NameNode单点故障，难以应用于在线场景
2. NameNode压力过大，且内存受限，影响系统扩展性
   

• MapReduce存在的问题

1. JobTracker访问压力大，影响系统扩展性
2. 难以支持除MapReduce之外的计算框架，比如Spark、Storm等.

• Hadoop 2.x由HDFS、MapReduce和YARN三个分支构

1. HDFS：分布式文件存储系统；
2. YARN：资源管理调度系统
3. MapReduce：运行在YARN上的MR；

2.2. HDFS 2.x

• 解决单点故障

HDFS HA高可用：通过主备NameNode解决，如果主NameNode发生故障，则切换到备NameNode上

• 解决内存受限问题

  (1) HDFS Federation（联邦机制）
  (2)2.x 支持2个NN节点的HA;
  3.0实现了NN一主多从，水平扩展，支持多个NameNode；
  每个NameNode分管一部分目录；
  所有NameNode共享所有DataNode存储资源;

• 2.x仅是架构上发生了变化，使用方式不变
• 对HDFS使用者透明

2.3. HDFS 2.x HA高可用

2.3.1. HDFS 2.x的HA

HDFS的高可用结构图:

JournalNode(JN)实现主备NN 间的数据共享

• 主备NameNode

• 解决单点故障(状态 ：active为主、standby为备)
  主NameNode对外提供服务，备NameNode同步主NameNode元数据，以待切换，所有DataNode同时向两个NameNode汇报数据块信息。

  主NN将对外提供服务，并将元数据放到JN上，备NN同步备份JN的上存储的元数据。

• 两种切换选择
  手动切换：通过命令实现主备之间的切换，可以用HDFS升级等场合
  自动切换：基于Zookeeper实现

• 基于Zookeeper自动切换方案
  2个NN通过获取zkfc竞争锁，来判定谁是active和standby.

2.3.2.Federation联邦

通过多个namenode/namespace把元数据的存储和管理分散到多个节点中，使到namenode/namespace可以通过增加机器来进行水平扩展。

能把单个namenode的负载分散到多个节点中，在HDFS数据规模较大的时候不会也降低HDFS的性能。可以通过多个namespace来隔离不同类型的应用，把不同类型应用的HDFS元数据的存储和管理分派到不同的namenode中。

2.4. Zookeepeer

详见：Zookeeeper详解

2.5. YARN

Hadoop 2.0新引入的资源管理任务调度系统，直接从MRv1演化而来的；

核心思想：将MRv1中JobTracker的资源管理和任务调度两个功能分开，分别由ResourceManager和ApplicationMaster进程实现。

ResourceManager： 负责整个集群的资源管理和调度。

ApplicationMaster：负责应用程序相关的事务，比如任务调度、任务监控和容错等。

YARN的引入，使得多个计算框架可运行在一个集群中.

每个应用程序对应一个ApplicationMaster（应用程序控制-主人）
目前多个计算框架可以运行在YARN上，比如MapReduce、Spark、Storm
等。

yarn资源管理任务调度流程:


流程大致如下：

• client客户端向yarn集群(ResourceManager)提交任务
• ResourceManager选择一个node创建AppMaster
• AppMaster根据任务向RM申请资源
• RM返回资源申请的结果（返回给AppMaster一批资源）
• AppMaster去对应的node上创建任务需要的资源（container形式，包括内存和CPU）
• AppMaster负责与NodeManager进行沟通，监控任务运行
• 最后任务运行成功，汇总结果。

其中ResourceManager里面一个很重要的东西，就是调度器Scheduler，调度规则可以使用官方提供的，也可以自定义。
官方大概提供了三种模式（了解）：

FIFO，最简单的先进先出，按照用户提交任务的顺序执行。这种方式最简单，但是也一大堆问题，比如任务可能独占资源，导致其他任务饿死等。

Capacity，采用队列的概念，任务提交到队列，队列可以设置资源的占比，并且支持层级队列、访问控制、用户限制、预定等等高级的玩法。

Fair share，基于用户或者应用去平分资源，灵活分配。
capacity和fair share都是采用队列的模式，队列内部基本上还是FIFO。并且同级的队列任务，如果一个队列是空闲的，那么另一个队列任务可以使用资源；如果这个队列又提交了任务，则会抢占或者等待资源释放，直到资源到达预定的分配比例。
总的来说，YARN的资源调度还是比较完善的。

2.6.MapReduce On YARN

• MapReduce On YARN：MRv2
• 将MapReduce作业直接运行在YARN上，而不是由JobTracker和TaskTracker构建的MRv1系统中
• 基本功能模块
  YARN：负责资源管理和调度
  MRAppMaster：负责任务切分、任务调度、任务监控和容错等
  MapTask/ReduceTask：任务驱动引擎，与MRv1一致
• 每个MapRduce作业对应一个MRAppMaster任务调度
  YARN将资源分配给MRAppMaster
  MRAppMaster进一步将资源分配给内部的任务
• MRAppMaster容错
  失败后，由YARN重新启动
  任务失败后，MRAppMaster重新申请资源

2.7.Hadoop2.X 集群搭建

集群合理安装部署规划(我这里以3太服务器为例)

Zookeeper Failover Controller：监控NameNode健康状态，并向Zookeeper注册NameNode，NameNode挂掉后，ZKFC为NameNode竞争锁，获得ZKFC 锁的NameNode变为active

1. 解压
   

2. 配置 hadoop-env.sh
   
   

3. 配置 core-site.xml
   

    
    	fs.defaultFS
     	hdfs://qiaoke
    
    
   	ha.zookeeper.quorum
   	node01:2181,node02:2181,node02:2181
    
    
    	 hadoop.tmp.dir
    	 /opt/hadoop2.6.5
    
   

4. 配置 hdfs-site.xml

    
    	dfs.nameservices
    	qiaoke
    
    
    	dfs.ha.namenodes.qiaoke
    	nn1,nn2
    
    
    	 dfs.namenode.rpc-address.qiaoke.nn1
    	 node01:8020
    
    
    	dfs.namenode.rpc-address.qiaoke.nn2
    	node02:8020
    
    
    	dfs.namenode.http-address.qiaoke.nn1
    	node01:50070
    
    
    	dfs.namenode.http-address.qiaoke.nn2
    	node02:50070
    
    
    	
     	dfs.namenode.shared.edits.dir
    
    
    	 
    	 dfs.namenode.shared.edits.dir
     qjournal://node01:8485;node02:8485;node03:8485/qiaoke
    
    
    	
    	dfs.client.failover.proxy.provider.qiaoke
      	org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
    
    
    	 
    	  dfs.ha.fencing.methods
    	  sshfence
    
    
    	
    	  dfs.ha.fencing.ssh.private-key-files
    	  /root/.ssh/id_rsa
    
    
    	 
    	  dfs.journalnode.edits.dir
    	  /opt/hadoop2.6.5/data
    
    
    	
    	   dfs.ha.automatic-failover.enabled
    	   true
    
   

5. 配置 zookeeper
   详见：zookeeper详解 配置章节
   a) 三台zookeeper：node01，node02，node03
   并解压ZooKeeper安装文件
   b) 编辑zoo.cfg配置文件
   

   修改
   dataDir=/opt/zookeeper
   server.1=node01:2888:3888
   server.2=node02:2888:3888
   server.3=node03:2888:3888
   

   c) 在dataDir目录中创建一个myid的文件，文件内容分别为1，2，3
   

   d) 环境变量
   
   
   

6. 配置hadoop中的slaves
   
   

7. 发送到 其他节点服务器 环境变量配置
   
   
   
   
   
   

8. 启动三个zookeeper：./zkServer.sh start
   注意:相关的zookeeper服务器都要启动
   

9. 启动三个JournalNode：./hadoop-daemon.sh start journalnode

10. 在其中一个namenode上格式化：hdfs namenode -format

11. 把刚刚格式化之后的元数据拷贝到另外一个namenode上

a)启动刚刚格式化的namenode : hadoop-daemon.sh start namenode
b)在没有格式化的namenode上执行：hdfs namenode -bootstrapStandby
c)启动第二个namenode hadoop-daemon.sh start namenode

12. 在其中一个namenode上初始化zkfc：hdfs zkfc -formatZK
13. 停止上面节点：stop-dfs.sh
14. 全面启动（在NN节点执行）：start-all.sh
15. 启动(resourcemanager，我这里是在2，3节点服务器上) ：yarn-daemon.sh start resourcemanager
16. 关机：先NN上执行 stop-all.sh
    在每个ZooKeeper节点服务器执行 zkServer.sh stop

有可能会出错的地方

1，确认每台机器防火墙均关掉
2，确认每台机器的时间是一致的
3，确认配置文件无误，并且确认每台机器上面的配置文件一样
4，如果还有问题想重新格式化，那么先把所有节点的进程关掉,
删除之前格式化的数据目录hadoop.tmp.dir属性对应的目录，所有节点同步都删掉，别单删掉之前的一个，删掉三台JN节点中dfs.journalnode.edits.dir属性所对应的目录
5，接上面的第6步又可以重新格式化已经启动了
6，最终Active Namenode停掉的时候，StandBy可以自动接管！