动态调整配置

对于Hadoop集群这样的分布式系统，有些参数是需要经常调整的，但是又不想重启daemon进程。原因很明显，重启任何一个daemon进程都是要付出代价的。例如重启master相当于停服务，集群直接不可用；重启TaskTracker会导致部分task失败重跑，延长job运行时间等。因此动态调整配置是迫切需要的。总结起来，要实现动态调整配置，大概有以下几种方法：

1、通过命令行方式手工刷新配置

这种方法的操作方式是首先将本地配置文件按照需要改好，然后执行命令行刷新配置。本质上是通过RPC通知daemon重新加载某些配置项并执行相关操作。常见的实例有，0.19的刷新NameNode的黑白名单：bin/hadoop dfsadmin –refreshNodes；0.20的刷新JobTracker的queue-acls：bin/hadoop mradmin –refreshQueueAcls (HADOOP-5396)；以及0.21引入的刷新JobTracker的黑白名单bin/hadoop mradmin –refreshNodes (HADOOP-5643)等。这种方法用起来非常优雅，但扩展性不好，通常用来实现非常明确的重量级需求。

2、通过网页修改配置

这种方法的操作方式是打开daemon提供的servlet网页，输入相关配置项及参数，点击确定。即通过http的方式向daemon传递某些配置信息。常见的实例是更新log级别，即Hadoop的所有daemon都提供的logLevel服务。这种方式使用起来非常方便，但不能持久化保存，重启daemon就恢复，通常用来临时调整，如debug等。

3、启用线程监控配置

这种方法不需要刷新，确认等操作，只需要修改本地配置文件即可。通常的实现方式是在daemon进程中专门启动一个线程来监控配置文件，如果发现有改动就立即重新加载配置并执行相应操作。常见的实例是FairScheduler有一个update线程会定期检查fair-scheduler.xml文件修改时间，如果有改动就重新加载。这种方式非常适合需要经常修改的配置文件，而且很容易实现自动化配置。我们自己实现的用户身份验证、acl验证等都采用了这种方式。当然这种方式也有缺点，就是需要启动一个线程。因此实现时应尽量使用已有线程或其他定期触发事件。如HADOOP-4885实现了自动恢复NameNode Storage，就采用定期的Checkpoint事件来触发，避免了新增线程。

4、通过网页确认修改

HADOOP-7001引入了一种新的动态调整配置方法，即首先在daemon本地修改hadoop-site.xml等配置文件，然后打开servlet提供的网页查看并确认修改，进而触发相应的接口实现。这种方式具有很强的通用性，但是每个配置的修改都要自己实现。HDFS-1477采用HADOOP-7001的接口实现了一个动态修改NameNode心跳间隔的例子，但意义不大，没有被社区采纳。我们计划采用这种方式实现动态调整TaskTracker的map/reduce slots配置并将尽快反馈给社区。