CDH中的JobTracker HA方案介绍

问题导读
1.JobTracker HA的包含哪些工作流程？
2.Cloudera的JobTracker HA哪些解决了，哪些未解决？





大家都知道，Hadoop JobTracker存在单点故障，且一直没有完善的开源解决方案。在Hadoop中，由于JobTracker出现的故障的概率远远小于NameNode，因此JobTracker HA通常不用来解决JobTracker容错，而是JobTracker在线升级问题。

Cloudera在推出的4.2.0版本中，提供了一套比较完善的JobTracker HA解决方案。本文将介绍这一方案。

在正式介绍CDH解决方案之前，先简要介绍JobTracker HA的基本工作流程，可概括为以下几步：

（1） Active JobTracker通过日志记录作业运行信息；

（2） 发现Active JobTracker故障，切换到某一个Stanby JobTracker上；

（3） Stanby JobTracker通过日志恢复作业运行时信息；

（4）  以上切换过程对JobTracker的客户端（JobClient，TaskTracker和Web HTTP）透明。

对于当前几乎所有Hadoop版本，（1）和（3）已经解决，而（2）（4）则尚未解决。

Cloudera的JobTracker HA解决方案如下图所示，主要由以下几个模块组成：

(1)    JobTrackerHADaemon

运行在JobTracker端，用于控制JobTracker的启动与停止。

(2)    JobTrackerHAServiceProtocol

运行在JobTracker端，实际上是一个RPC Server，接收并处理来自MRHAAdmin（管理员）的JobTracker处理请求，比如将JobTracker转为Active状态或者Standy状态等。

(3)    MRHAAdmin

为管理员提供的工具包，管理员可通过其中的一些函数控制各个JobTracker的状态。

(4)    JobTrackerProxies

对原有RPC客户端的再次封装，使各个客户端在Active JobTracker出现故障时能够透明地将RPC请求发送至新的Active JobTracker上。

(5)    JobTrackerHAHttpRedirector

对来自Web端的HTTP请求进行重定向。当Active JobTracker出现故障时，将所有来自Active JobTracker的访问请求重新定向到新的Active JobTracker上。

当管理员想要对JobTracker进行升级切换时，只需采用一些命令先将当前Active JobTracker置为Stanby，将另外某个Stanby JobTracker置为Active，接着Hadoop内部逻辑如下：

以上只是介绍了人工触发切换模式下的JobTracker HA架构，接下来给出使用Zookeeper进行自动切换的JobTracker HA架构图：

整个架构几乎没有改变，只是由Zookeeper发现Active JobTracker出现故障后，通过一定的选举算法选出一个新的Active JobTraker，并启动该JobTracker。

CDH的JobTracker HA解决方案有一个明显不足是作业恢复粒度过大。我们知道，JobTracker HA有三个级别的作业恢复粒度，分别是：1）作业（JobTracker重启后自动重新提交之前正在运行的作业，但是所有任务，包括重启前已经运行完成的、正在运行的和尚未运行的任务，必须重新运行）、运行完成的任务（JobTracker重启后恢复各个作业已经运行完成的任务，但是之前正在运行和尚未运行的任务需要重新调度执行）和所有任务（JobTracker重启后恢复所有作业之前一模一样的状态，即所有运行完成的和正在运行的任务均保持之前状态，只需重新调度尚未运行的任务），这三个级别实现难度依次增高，但收益依次增大。对于CDH 4.2.0而言，它仅实现了作业级别的恢复粒度，属于一种最简单且收益最小的实现方式。

转载自董的博客