Note：这里描述的黑名单是指jobtracker网页summary表格中显示的”Blacklisted Nodes"，称之为集群黑名单.

在HADOOP-4305之前，Hadoop中每个job会维护一个TaskTracker黑名单，这里称之为job黑名单。简单来讲就是当一个job中有4个task曾经在某个tasktracker上

失败过，则该job就将这个tasktracker加入自己的job黑名单，即该job的其他task不再调度到这个tasktracker上。HADOOP-4305中认为所有的job黑名单应该汇

总一起，让jobtracker从全局的角度排除那些导致大量task失败的TaskTracker。因为如果很多job将某一个tasktracker加入了job黑名单，很可能这个

tasktracker确实有问题，不应该再让他跑task了。

从以往运维Hadoop集群经验来看，确实存在这样的tasktracker导致了大量task失败从而拖慢整个业务线。而调查该tasktracker后发现其自身确实有问题，如

userlogs的子目录达到上限、根盘空间满了等。而我们的解决方案通常是根据实际案例增加对应监控来逐个解决。比如监控userlogs子目录数达到阈值后即清

理最老的目录。再比如监控根盘空间，如果达到了阈值就停掉tasktracker进程，并报警给管理员等。而HADOOP-4305希望Hadoop自身智能地发现类似问题并自

己解决。智能解决当然能减轻运维人员的负担，但也引入了很多问题。比如判断错误，将不该黑掉的tasktracker黑了等。而且一旦一个tasktracker被黑了，

运维人员需要调查被黑原因，也要想办法去恢复。有时候这个负担比外围监控更大。但是对于运维一个已经启用集群黑名单机制的集群来说，只能先去熟悉这

个机制，再去优化并监控。下面描述下HADOO-4305给出的机制。

Part 1/2：Tasktracker加入集群黑名单机制：

当一个job成功结束时，对该job黑名单中的tasktracker做如下三个判断：

/**

* 强调下这里值的是成功的job，因为失败job的task失败大多是因为自身有bug导致的，不能冤枉tasktracker。

* 而事实上成功job中失败的task也可能是job自身问题导致的，所以我不认可这个机制。

**/

1、这个tasktracker已经被至少4个job加入了黑名单；

/**

* 这里的4个是可配置的，配置参数为：

mapred.max.tracker.blacklists

**/

2、到目前为止该tasktracker被加入job黑名单的次数，超过了集群中所有tasktracker被加入job黑名单平均次数的50%；

/**

* 这里的50%也是可配置的，配置参数为：

mapred.cluster.average.blacklist.threshold

**/

3、已经加入黑名单的tasktracker个数不超过集群总tasktracker的50%；

/**

* 这条限制是不能有超过一半的tasktracker被放入黑名单，目的是防止因太多tasktracker放入黑名单而严重影响集群工作。

* 这里的50%是不可配置的。

**/

以上三条如果均满足，则将job黑名单中的tasktracker加入集群黑名单，以后将不在该tasktracker上调度任何task。

Part 2/2: 已加入集群黑名单的tasktracker的恢复机制：

Jobtracker收到集群黑名单中的tasktracker发来的心跳时，做如下判断：

/**

* 加入集群黑名单的tasktracker仍然照常发送心跳。

**/

1、如果该tasktracker已经重启，则直接从集群黑名单中取出，并完全恢复正常；

/**

* 这是最常用的恢复方法。

**/

2、如果该tasktracker在24小时内未被加入过job黑名单，则其加入job黑名单的计数减1，并允许调度task。

/**

* 这里的24小时是不可配置的；

* 由于tasktracker加入集群黑名单后不能调度task，也就没有机会加入job黑名单了，因此几乎所有集群黑名单中tasktracker都会在24小时之后开始调度，然

后被一个job加入job黑名单后又不能调度了。

* 如此反复，因此这条其实没啥用，常用的恢复方法还是重启tasktracker。

**/

以上描述了HADOOP-4305给出的黑名单机制，个人感觉问题很多，最好不要启用。如果已经启用的话，最好把可配置的两个参数设大些。