Hadoop商业环境实战-HDFS NameNode 宕机元数据一致保障及SNN机制深入研究

栏目: 服务器 · 发布时间: 6年前

内容简介：版权声明：本套技术专栏是作者（秦凯新）平时工作的总结和升华，通过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。版权声明：禁止转载，欢迎学习。QQ邮箱地址：1120746959@qq.com，如有任何商业交流，可随时联系。seen_txid: 是一个事务ID，这个事务ID是EditLog最新的一个结束事务id，当NameNode重启时，会顺序遍历从edits_0000000000000000001到seen_txid所记录的txid所在的日志文件

1 从文件目录树谈起(FSImage与EditLog)

文件目录树存在于NameNode的内存里，维护了整个HDFS这个分布式文件系统元数据信息。
任何对文件的创建，修改，删除都会在内存中完成，并持久化到磁盘，也即edits log。
元数据的存储形式主要有3类：内存镜像、磁盘镜像(FSImage)、日志(EditLog)。
在Namenode启动时，会加载磁盘镜像到内存中以进行元数据的管理，存储在NameNode内存;
磁盘镜像是某一时刻HDFS的元数据信息的快照，包含所有相关Datanode节点文件块映射关系和命名空间(Namespace)信息，存储在NameNode本地文件系统;
日志文件记录client发起的每一次操作信息，即保存所有对文件系统的修改操作，用于定期和磁盘镜像合并成最新镜像，保证NameNode元数据信息的完整，存储在NameNode本地和共享存储系统Quorum Journal Manager(QJM)中。
SNN会定期将本地FSImage和从QJM上拉回的ANN的EditLog进行合并，合并完后再通过RPC传回ANN。
悖论：若频繁的修改内存里的元数据，并持久化，会存在大量的随机IO，则性能极低。因此JournalNodes诞生了，利用ZKFC选举和双缓存机制实现高并发数据读写。

Hadoop商业环境实战-HDFS NameNode 宕机元数据一致保障及SNN机制深入研究

seen_txid: 是一个事务ID，这个事务ID是EditLog最新的一个结束事务id，当NameNode重启时，会顺序遍历从edits_0000000000000000001到seen_txid所记录的txid所在的日志文件，进行元数据恢复，如果该文件丢失或记录的事务ID有问题，会造成数据块信息的丢失。

2 Secondary NameNode 优胜劣汰的弃儿（单点故障）

整个核心分为最近更新的edit logs 和全局系统快照fsimage 。NameNode 宕机后，根据其最近更新的edit logs 和全局系统快照fsimage（Secondary NameNode帮忙协助处理的）在重启时更新到内存进行回放，即可重新恢复整个系统的元数据。

fsimage - 它是在NameNode启动时对整个文件系统的快照。
edit logs - 它是在NameNode启动后，对文件系统的改动序列。

Secondary NameNode 诞生的重点原因阐述：

hadoop仅有单NameNode时：因为只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。
怎么去管理edit logs是一个挑战。 NameNode的重启会花费很长时间，因为有很多改动（在edit logs中）要合并到fsimage文件上。如果NameNode挂掉了，那我们就丢失了很多改动，因为此时的fsimage文件非常旧。
为了减小edit logs文件的大小和得到一个最新的fsimage文件，初期引入了Secondary NameNode机制。
Secondary NameNode会定时到NameNode中去获取edit logs，并更新到Secondary NameNode 自己的fsimage上。一旦它有了新的fsimage文件，它将其拷贝回NameNode中。 NameNode在下次重启时可以直接使用这个新的fsimage文件，从而减少重启的时间。
secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。

2 JournalNodes 历史动乱的维护者（集群模式）

在一个典型的HA集群中，每个NameNode是一台独立的服务器。在任一时刻，只有一个NameNode处于active状态，另一个处于standby状态。
active状态的NameNode负责所有的客户端操作，standby状态的NameNode处于从属地位，维护着数据状态，随时准备切换。
两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。
standby状态的NameNode有能力读取JournalNodes中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了。

3 宕机内存元数据一致性回放SNN机制（高可用）

第一步：通知hdfs客户端，我要上传一份文件。（提前设置副本）
第二步：更新Active NameNode(ANN)的内存元数据，并写一份edits log到JournalNodes集群上，另一份写在本地。
第三步：Standby NameNode （SNN）实时读取JournalNodes中更新的 edits log，更新Standby NameNode内存元数据，并每隔一段时间（SNN上有一个线程StandbyCheckpointer），元数据写入到磁盘的fsimage文件中，并同步到Active NameNode。
第四步：一旦Active NameNode宕机，Standby NameNode 直接读取最近更新的edits log（不会太多）和 fsimage文件，进行内存中回放，即可实现快速恢复使用。
第五步：如果没有宕机，hdfs客户端负责分布式写副本即可。