1、为何不用RAID

HDFS所提供的节点间数据复制技术已可满足数据备份需求，无需使用RAID冗余机制。

RAID 0速度比JBOD（Just a Bunch Of Disks）慢，JBOD在所有磁盘之间循环调度HDFS块。RAID 0的读写操作受限于磁盘阵列中最慢盘片的速度，而JBOD的磁盘操作均独立，因而篇平均读写速度高于最慢盘片的读写速度。


2、服务是否可以放在一台服务器上

对于一个小集群（几十个节点）而言，在一台master机器上同时运行namenode和jobtracker通常没有问题（需确保至少一份namenode的元数据被另存在远程文件系统中）。但是随着HDFS中的集群和文件数不断增长，namenode需要使用更多的内存，那么namenode和jobtracker最好分别放到不同的机器中。

辅助namenode可以和namenode一起运行在同一台机器之中，但是同样由于内存使用的原因（辅助namenode和主namenode的内存需求相同），二者最好运行在独立的服务器上；对于大规模集群来说更是如此。


3、hadoop配置文件

hadoop集群的每个节点各自保存自己的配置文件，并没有放在一个单独的全局位置，由管理员去完成配置文件的同步。hadoop提供一个基本工具来进行同步，即rsync。此外，dsh或pdsh等并行shell工具也可完成该任务。


hadoop也支持为所有的master机器和worker机器采用同一套配置文件。这个做法的最大优势就是简单。但是，这种一体适用的配置模型并不适合某些集群。以扩展集群为例，当试图为集群添加新机器，且新机器的硬件规格与现有机器不同时，则需要新建一套配置文件，以充分利用新硬件的额外资源。


在这种情况下，需要引入“机器类”的概念，为每一个机器类维护单独的配置文件。hadoop没有提供这个操作的工具，需要借助外部工具来执行该配置操作。


4、独立安装MapReduce和HDFS的好处

分开两个服务的前提条件是兼容性限制放宽，这样有利于升级，例如，可以一边便捷的升级MapReduce（可能打一个补丁），一边仍然运行HDFS。


需要注意的是即使独立安装了HDFS和MapReduce，它们任然可以共享配置信息，其方法是使用--config选项（启动守护进程时），指向同一个配置目录。鉴于它们所产生的日志文件的名称不同，不会导致冲突，因此任然可以将日志输出到同一个目录中。


5、masters节点

为了运行hadoop内置脚本来操作集群服务和守护进程的启停，需要预先知道集群内的所有机器。两个文件可以达成这个目标，即masers和slaves。各文件逐行记录一些机器的名称或IP地址。masters文件的名称有点误导人，它主要记录的是拟运行辅助namenode的所有机器。


namenode在内存中保存整个命名空间中的所有元数据和块元数据，其内存需求很大。辅助namenode在大部分时间里是空闲的，但是它在创建检查点时的内存需求与namenode是差不多的。一旦文件系统包含大量文件，单台机器的物理内存便无法同时运行主namenode和辅助namenode。


辅助namenode保存一份最新的检查点，记录它创建的文件系统的元数据。将这些历史信息备份到其他节点上，有助于数据丢失（或系统崩溃）的情况下恢复namenode的元数据文件。


在一个运行大量MapReduce作业的高负载集群上，jobtracker会占用大量内存和CPU资源，因此它最好运行在一个专用节点上。