hdfs中的NameNode,SecondaryNameNode,BackupNode

NameNode: 暂且叫它为元数据结点。

它实现了NamenodeProtocols 中的接口,而该接口分别有三个父类:

ClientProtocol, 与客户端的通信。

DatanodeProtocol, DN 的通信。

NamenodeProtocol, BNSNN 的通信。

主要有二大功能:

1.    文件元信息的管理,由 FSNamesystem 类完成,主要提供了文件的相关操作,将文件信息保存到内存中,同时将操作日志保存到日志文件中。

2.    数据块的管理,由BlockManager 类完成,负责保存数据块的相关信息,以及对数据块的复制,监测工作等。

SecondaryNameNode 第二个数据结点,主要是备份主结点的文件信息,不备份数据块的信息,另外,它还会将 fsimage edits 日志合并成一个新的 fsimage ,再将新的 fsimage 上传给 NN, 这样使得 NN 中的 edits 不会一直是递增的,可以使得当 NN 挂了后,能够快速的恢复起来

它的主要工作在这个 doCheckpoint() 方法中,每隔一段时间会启动检查点一次,是由两个配置参数来控制的:

fs.checkpoint.period ,指定连续两次检查点的最大时间间隔, 默认值是 1 小时。

fs.checkpoint.size 定义了 edits 日志文件的最大值,一旦超过这个值会导致强制执行检查点(即使没到检查点的最大时间间隔)。默认值是 64MB

void doCheckpoint () throws IOException {

    // Do the required initialization of the merge work area.

    startCheckpoint();

     // Tell the namenode to start logging transactions in a new edit file

    // Returns a token that would be used to upload the merged image.

    CheckpointSignature sig = namenode .rollEditLog();

    // error simulation code for junit test

    if (ErrorSimulator.getErrorSimulation (0)) {

      throw new IOException( "Simulating error0 " +

                            "after creating edits.new" );

    }

    downloadCheckpointFiles(sig);   // Fetch fsimage and edits

    doMerge(sig);                   // Do the merge

    //

    // Upload the new image into the NameNode. Then tell the Namenode

    // to make this new uploaded image as the most current image.

    //

    putFSImage(sig);

    // error simulation code for junit test

    if (ErrorSimulator.getErrorSimulation (1)) {

      throw new IOException( "Simulating error1 " +

                            "after uploading new image to NameNode" );

    }

    namenode .rollFsImage();

    checkpointImage .endCheckpoint();

    LOG .warn( "Checkpoint done. New Image Size: "

               + checkpointImage .getFsImageName().length());

  }

BackupNode 备份结点。这个结点的模式有点像 mysql 中的主从结点复制功能, NN 可以实时的将日志传送给 BN ,而 SNN 是每隔一段时间去 NN 下载 fsimage edits 文件,而 BN 是实时的得到操作日志,然后将操作合并到 fsimage 里。

NN 里提供了二个日志流接口: EditLogOutputStream EditLogInputStream 。即当 NN 有日志时,不仅会写一份到本地 edits 的日志文件,同时会向 BN 的网络流中写一份,当流缓冲达到阀值时,将会写入到 BN 结点上, BN 收到后就会进行合并操作,这样来完成低延迟的日志复制功能。

总结:

当前的备份结点都是冷备份,所以还需要实现热备份,使得 NN 挂了后,从结点自动的升为主结点来提供服务。

NN 的效率问题: NN 的文件过多导致内存消耗问题, NN 中文件锁问题, NN 的启动时间。

 

参考资料:

http://jiajun.javaeye.com/blog/809125

http://blog.csdn.net/shirdrn/archive/2009/10/07/4639345.aspx

http://hadoop.apache.org/common/docs/r0.18.2/cn/hdfs_user_guide.html#Secondary+NameNode

https://issues.apache.org/jira/browse/HADOOP-4539

http://datasearch.ruc.edu.cn/~boliangfeng/blog/?p=551

没有更多推荐了,返回首页