首先，今天是羊年初一。祝看到这篇博文的朋友们新春快乐！身体健康！心想事成！万事胜意！
言归正传。hadoop中的两大核心分别是HDFS以及MapReduce。HDFS分布式文件系统有NameNode、DataNode以及SecondaryNameNode三种节点进程，同时MR有JobTracker和TaskTracker两种节点进程。（当然这是基于hadoop 1.x版本来讨论的，至于2.x的NameNode联邦和YARN的话，我们下次再讨论）
对于HDFS文件系统，NN 是负责文件系统管理，包括所有文件的命名以及它们所包含的的目录内容，所有文件的元数据，文件的块映射，节点（也就是DN）的块存储信息以及目前的文件复制状态。DN是负责存储数据并定期向NN汇总复制状态以及块信息。这里NN与DN通信主要是通过心跳机制（heartbeat messages）进行通信。而SecondaryNameNode主要是及时更新集群信息，辅助NN的，它并不是NN的hot-backup哦！但我们可以通过它来恢复NN，这是对的。
现在我们来讨论一下里面的一些细节。
【当DN宕掉的时候】使用hadoop dfsadmin -report命令查看DN宕掉前后的报告。可以发现DFS remaining，DFS userd，以及Datanode available的数据的变化。每一个DN都有自己管理的replicas。如果一个DN宕掉了，那么NN会令其他DN恢复宕掉的那个DN的备份，所以可以看到参数Under replicated blocks的数据变化。当然，这是在参数dfs.replication的threshold之内，如果剩下的DN数少于复制因子数的话，估计就不会再复制了。
【当NN宕掉的时候】这对于hadoop集群来说可是一个毁灭性的灾难。因为NN是整个集群关键。我们必须事先保存好tmp目录中的name目录中内容，因为里面的两个文件是关键。一个fsimage，另一个是version。具体做法可以参看本人之前的一篇博文利用hadoop1.x集群进行探索性实验（二）【模拟namenode崩溃，通过secondary namenode恢复namenode】。这里重点说一下fsimage文件，它保存着整个HDFD文件系统的所有文件属性以及块信息等细节。为了不让任何修改信息丢失，在每次启动的时候，NN都会根据edits log来update这个文件。同时在刚启动集群的时候通过web UI会发现文件系统处于safe mode。这是因为这时候DN正在向NN报告块信息。NN会令文件系统一直处于只读状态直到其确认有一定比例的块已经达到了预期的复制值。可能大家会有疑问，如果经常这样，那么那些大的集群启动的过程不就会非常漫长？？这个时候，我们的SecondaryNameNode出场了！它会在每隔一段时间根据edits log来update fsimage这个文件。从而加快NN的启动。
【当JT宕掉的时候】它并不会影响到HDFS文件系统的正常运行，但是想要提交MR作业恐怕就不行了。但是NN宕掉的话，别说HDFS文件系统崩溃了，就连MR作业也别想运行了！同时，MR Job会将作业的临时数据写到HDFS中，并在作业结束后自动删除。如果因为JT宕掉了而令到作业失败，那么这些临时文件恐怕需要手动删除了。
【当TT宕掉的时候】JT会重新寻找可用的TT来继续完成作业，所以并不担心会有多么大的问题。同时可以在mapred-site.xml中设置mapred.tasktracker.expiry.interval属性来定义检查时长，如果超出了规定时间都接收不到心跳信息，则认为此TT已经dead。
好了，就讨论到这里啦！当知道了这些细节后，也为我们管理hadoop集群提供了莫大的便利。