HDFS的启动流程和HA
HDFS的启动流程
- 当 NameNode 启动时HDFS首先将Fsimage读入内存对元数据进行恢复，然后再读edits文件中的更新操作在恢复后的元数据上进行执行，使得此时的NameNode中保存的是停止前的最新状态，然后删除旧的edits (这个过程称为检査点)，最后等待各个DataNode向 NameNode 汇报文件块的信息来组装 block ID 映射关系。
- DataNode 启动时会扫描本地文件系统，产生一个本地文件对应的 HDFS 文件块的列表(每个文件块会对应一个本地文件)，然后作为报告发送到 NameNode(这个报告称为块状态报告)。
- NameNode 在接收到每个 DataNode 的块汇报信息后，将其和所在的 DataNode 信息等保存在内存中。
HDFS的HA
Hadoop1.x
如果 NameNode失效，可以通过 SecondaryNameNode 中保存的 FSImage 和 edits 数据恢复出 NameNode 最近的状态。
为了加快 NameNode 重启速度，SecondaryNameNode 还会定期合并 edits。
Hadoop2.x
任何时刻，只有一个 NameNode处于 Active状态，另一个处于 Standby 状态。Active NameNode 负责所有的客户端操作，而 Standby NameNode 只是简单的充当 Slave，它负责维护状态信息以便在需要时能快速切换。
主备切换控制器 ZKFailoverController
- ZKFailoverController 作为独立的进程运行，对 NameNode的主备切换进行总体控制。
- ZKFailoverController 能及时检测到NameNode的健康状况，在主 NameNode故障时借助 Zookeeper实现自动的主备选举和切换，当然 NameNode目前也支持不依赖于 Zookeeper的手动主备切换。
Zookeeper 集群的目的是为主备切换控制器提供主备选举支持。
联邦模式
通过阅读专栏之前的内容我们知道 HDFS 集群的元数据信息是存放在 NameNode 的内存中的，当集群扩大到一定的规模以后， NameNode 内存中存放的元数据信息可能会非常大，由于 HDFS 的所有的操作都会和 NameNode 进行交互， 当集群很大时， NameNode 会成为集群的瓶颈。
在 Hadoop2.x 诞生之前，HDFS 中只能有一个命名空间，对于 HDFS 中的文件没有办法完成隔离。正因为如此，在 Hadoop2.x中引入了Federation的机制，可以解决如下场景的问题。
- HDFS集群扩展性。多个 NameNode 分管一部分目录，使得一个集群可以扩展到更多节点，不再像 1.0 中由于内存的限制制约文件存储数目。
- 性能更高效。多个 NameNode 管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。
- 良好的隔离性。用户可根据需要将不同业务数据交由不同 NameNode 管理这样不同业务之间影响很小。