hadoop namenode深度剖析

1、NAMENODE内部结构(fsimage+edits+blockmap)
     fsimage:保存了最新的元数据检查点;
     edits:保存了HDFS中自最新的元数据检查点后的命名空间变化记录;

     BlockMap: 在fsimage中,并没有记录每一个block对应到哪几个datanodes的对应表信息,而只是存储了所有的关于namespace的相关信息。而真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储,而是在所有datanode启动时,每个datanode对本地磁盘进行扫描,将本datanode上保存的block信息汇报给namenode,namenode在接收到每个datanode的块信息汇报后,将接收到的块信息,以及其所在的datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanode向namenode汇报块信息的过程叫做blockReport,而namenode将block -> datanodes list的对应表信息保存在一个叫BlocksMap数据结构中。

 

为防止edits中保存的最新变更记录过大,standby nn会定期合并fsimage和edits文件形成新的fsimage文件,然后重新记录edits文件。

Fsimage是一个二进制文件,它记录了HDFS中所有文件和目录的元数据信息。关于fsimage的内部结构我们可以参看下图:
fsimage

第一行是文件系统元数据,第二行是目录的元数据信息,第三行是文件的元数据信息。

NameNode将这些信息读入内存之后,构造一个文件目录结构树,将表示文件或目录的节点填入到结构中。
在NameNode加载fsimage完成之后,BlocksMap中只有每个block到其所属的datanodes list的对应关系信息还没建立。然后通过dn的blockReport来收集构建。当所有的DataNode汇报给NameNode的blockReport处理完毕后,BlocksMap整个结构也就构建完成了。

     文件和block的映射,固化在磁盘上。而block和DataNode的映射在DataNode启动时上报给NameNode

      以上内容来自: http://blog.csdn.net/yy10992/article/details/50081783
2、NAMENODE HA

dfs.namenode.edits.dir (NameNode 编辑目录) :  写入 NameNode 编辑的本地文件系统上的目录。未指定将存放在namenode数据目录中。
dfs.journalnode.edits.dir (JournalNode 编辑目录):用于存储 NameNode 编辑的本地文件系统目录。journalnode所在节点的目录,存放editlog和其他信息。
dfs.namenode.shared.edits.dir (共享编辑目录):用于存储 NameNode 编辑的共享存储设备上的目录,例如基于 Quorum 的存储 URI 或 NAS 上的 NFS 装载的本地目录。
<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>qjournal://master:8485;slave1:8485;slave2:8485/hadoop-journal</value>
</property>
多个NN数据同步通过NFS或QJM的方式进行,NFS是操作系统层面的配置,而QJM是hadoop自带的软件配置,一般用的较多的是QJM配置。
同一时间只有一个namenode可往JNS的中写数据。
为了让Standby Node与Active Node保持同步,这两个Node都与一组称为JNS的互相独立的进程保持通信(Journal Nodes)。当Active Node上更新了namespace,它将记录修改日志发送给JNS的多数派。Standby noes将会从JNS中读取这些edits,并持续关注它们对日志的变更。Standby Node将日志变更应用在自己的namespace中,当failover发生时,Standby将会在提升自己为Active之前,确保能够从JNS中读取所有的edits;即在failover发生之前,Standy持有的namespace应该与Active保持完全同步。
在standby NameNode节点上会一直运行一个叫做CheckpointerThread的线程,这个线程调用StandbyCheckpointer类的doWork()函数,而doWork函数会每隔Math.min(checkpointCheckPeriod, checkpointPeriod)秒来坐一次合并操作,相关代码如下:

    try {
              Thread.sleep(1000 * checkpointConf.getCheckPeriod());
            } catch (InterruptedException ie) {
    }

    public long getCheckPeriod() {
        return Math.min(checkpointCheckPeriod, checkpointPeriod);
    }

    checkpointCheckPeriod = conf.getLong(
            DFS_NAMENODE_CHECKPOINT_CHECK_PERIOD_KEY,
            DFS_NAMENODE_CHECKPOINT_CHECK_PERIOD_DEFAULT);
            
    checkpointPeriod = conf.getLong(DFS_NAMENODE_CHECKPOINT_PERIOD_KEY,
                                    DFS_NAMENODE_CHECKPOINT_PERIOD_DEFAULT);
 


上面的checkpointCheckPeriod和checkpointPeriod变量是通过获取hdfs-site.xml以下两个属性的值得到:

    <property>
      <name>dfs.namenode.checkpoint.period</name>
      <value>3600</value>
      <description>The number of seconds between two periodic checkpoints.
      </description>
    </property>

    <property>
      <name>dfs.namenode.checkpoint.check.period</name>
      <value>60</value>
      <description>The SecondaryNameNode and CheckpointNode will poll the NameNode
      every 'dfs.namenode.checkpoint.check.period' seconds to query the number
      of uncheckpointed transactions.
      </description>
    </property>

 
当达到下面两个条件的情况下,将会执行一次checkpoint:

    boolean needCheckpoint = false;
    if (uncheckpointed >= checkpointConf.getTxnCount()) {
         LOG.info("Triggering checkpoint because there have been " +
                    uncheckpointed + " txns since the last checkpoint, which " +
                    "exceeds the configured threshold " +
                    checkpointConf.getTxnCount());
         needCheckpoint = true;
    } else if (secsSinceLast >= checkpointConf.getPeriod()) {
         LOG.info("Triggering checkpoint because it has been " +
                secsSinceLast + " seconds since the last checkpoint, which " +
                 "exceeds the configured interval " + checkpointConf.getPeriod());
         needCheckpoint = true;
    }

 
 当上述needCheckpoint被设置成true的时候,StandbyCheckpointer类的doWork()函数将会调用doCheckpoint()函数正式处理checkpoint。当fsimage和edits的合并完成之后,它将会把合并后的fsimage上传到Active NameNode节点上,Active NameNode节点下载完合并后的fsimage,再将旧的fsimage删掉(Active NameNode上的)同时清除旧的edits文件。步骤可以归类如下:
  (1)、配置好HA后,客户端所有的更新操作将会写到JournalNodes节点的共享目录中,可以通过下面配置


    <property>
      <name>dfs.namenode.shared.edits.dir</name>
      <value>qjournal://XXXX/mycluster</value>
    </property>

    <property>
      <name>dfs.journalnode.edits.dir</name>
      <value>/export1/hadoop2x/dfs/journal</value>
    </property>

 

(2)、Active Namenode和Standby NameNode从JournalNodes的edits共享目录中同步edits到自己edits目录中;
  (3)、Standby NameNode中的StandbyCheckpointer类会定期的检查合并的条件是否成立,如果成立会合并fsimage和edits文件;
  (4)、Standby NameNode中的StandbyCheckpointer类合并完之后,将合并之后的fsimage上传到Active NameNode相应目录中;
  (5)、Active NameNode接到最新的fsimage文件之后,将旧的fsimage和edits文件清理掉;
  (6)、通过上面的几步,fsimage和edits文件就完成了合并,由于HA机制,会使得Standby NameNode和Active NameNode都拥有最新的fsimage和edits文件(之前Hadoop 1.x的SecondaryNameNode中的fsimage和edits不是最新的)
JournalNode服务器:运行的JournalNode进程非常轻量,可以部署在其他的服务器上。注意:必须允许至少3个节点。当然可以运行更多,但是必须是奇数个,如3、5、7、9个等等。当运行N个节点时,系统可以容忍至少(N-1)/2(N至少为3)个节点失败而不影响正常运行。
dfs.ha.automatic-failover.enabled:启动自动failover,依赖于zookeeper集群和ZKFailoverController(ZKFC)
ZKFailoverController: ZK客户端用来监控namenode的状态。每个运行nn的节点必须要运行一个zkfc。
zkfc提供以下功能:
health monitor: zkfc定期对本地nn发起health检查,如正确返回,则认为NN正常,否则被认为失效节点。
session management: 当本地NN正常时,ZKFC会在zk中注册一个session,如果该NN是ACTIVE状态,还会持ephemeral节点作为锁;一旦NN不正常,则该session会自动删除。
active选举: 当本地NN正常时,且没有其他的NN持有独占锁,ZKFC会去获得锁,一旦成功,就需要执行Failover(对之前的NN进行隔离,再将本地NN转换到Active状态),然后成为active的NN节点。

为了确保快速切换,standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点,所有的datanodes必须配置两个NameNode的地址,发送数据块位置信息和心跳给他们两个。
hdfs haadmin -transitionToActive nn1 :将指定的namenode ID切换为Active或者standby
hdfs haadmin -DFSHAAdmin -failover nn1 nn2 :在两个Namenode之间failover。这个指令会触发将first节点failover到second节点。如果first处于standby,那么只是简单的将second提升为Active。如果first为Active,那么将会友好的将其切换为standby,如果失败,那么fencing methods将会触发直到成功,此后second将会提升为Active。如果fencing method失败,那么second将不会被提升为Active。
FAQ:
1、如果Zookeeper失效,将会怎么样?
如果zookeeper集群故障,那么Automatic Failover将不会触发,即使Namenode失效,这也意味着ZKFC无法正常运行。不过,如果Namenodes正常(即使有一个失效),那么HDFS系统将不会受到影响。因为HDFS Client并没有基于zookeeper做任何事情,当zookeeper集群仍需要尽快的恢复以避免当前Active失效而造成的“split-brain”等问题。
2、是否可以在Namenodes之间指定优先级?
NO,这是不能支持的。首先启动的Namenode将作为Active,我们只能认为控制Namenode启动的顺序来做到“优先级”。
3、在Automatic Failover中,手动Failover怎么做?
和普通的Failover一样,我们总是可以通过"hdfs haadmin -DFSHAAdmin -failover"来实现手动Failover。



以上内容摘自:

http://blog.csdn.net/zh521zh/article/details/51788901

http://blog.csdn.net/shift_alt_ctrl/article/details/69944390


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 可能是以下原因导致hadoop namenode启动不了: 1.配置文件错误:检查hadoop配置文件中的参数是否正确设置,特别是hdfs-site.xml和core-site.xml文件。 2.权限问题:检查hadoop文件系统的权限是否正确设置,确保hadoop用户对文件系统有足够的权限。 3.端口冲突:检查hadoop namenode所使用的端口是否被其他进程占用,可以使用netstat命令查看端口占用情况。 4.磁盘空间不足:检查hadoop namenode所在的磁盘空间是否足够,如果磁盘空间不足,可能会导致hadoop namenode启动失败。 5.日志文件错误:检查hadoop namenode的日志文件,查看是否有错误信息,根据错误信息进行排查和解决。 希望以上信息能够帮助您解决hadoop namenode启动不了的问题。 ### 回答2: 首先,需要检查hadoop namenode的日志以查找任何错误信息。可以通过以下命令访问hadoop日志: cd /hadoop/logs tailf hadoop-hdfs-namenode-*.log 如果没有错误信息,则可以进一步检查以下内容: 1. 确认hadoop的配置文件是否正确配置。namenode的配置文件通常在/hadoop/etc/hadoop/hdfs-site.xml中。可以检查以下参数是否设置正确: <property> <name>dfs.namenode.rpc-address</name> <value>namenode-hostname:8020</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/hadoop/hdfs/name</value> </property> <property> <name>dfs.replication</name> <value>3</value> </property> 2. 检查hadoop的文件系统是否正确格式化。如果文件系统未正确格式化,则namenode可能无法启动。可以通过以下命令格式化文件系统: hadoop namenode -format 3. 检查系统资源是否足够。namenode需要足够的内存和硬盘空间来持久性存储文件系统的元数据。可以通过使用以下命令检查系统资源: free -mh df -h 4. 检查网络连接是否正常。namenode的启动需要依赖于网络连接。可以使用以下命令检查网络连接: ping namenode-hostname 如果上述方法都无法解决问题,则建议尝试重新安装hadoop并重新配置namenode。或联系hadoop社区,以寻求更深入的支持。 ### 回答3: 当Hadoop Namenode不能启动时,可能会发生多种原因。下面列出了几个常见的问题及其解决方案。 1. 数据目录中的文件损坏或丢失 - 在Hadoop中,Namenode存储了整个文件系统的名称空间及其文件的元数据。如果数据目录中的某些文件已损坏或丢失,Namenode将无法启动。解决此问题的方法是尝试恢复这些文件或在安装备份副本之后重新格式化Namenode。 2. 内存不足 - 如果您的机器没有足够的内存来支持Namenode进程,则可能会出现启动失败的问题。您可以通过增加内存或禁用其他应用程序以释放一些内存来解决此问题。 3. 配置文件错误 - 如果您最近对Hadoop配置文件(如core-site.xml和hdfs-site.xml)进行了更改,并且更改不正确,则可能会导致Namenode无法启动。请检查配置文件并确保它们正确配置。 4. 端口冲突 - Namenode启动需要侦听不同的端口以接收客户端请求。如果其他进程正在使用相同的端口,则会发生端口冲突,并且Namenode将无法启动。您可以通过查找并杀死占用该端口的进程来解决此问题,并将其更改为其他未使用的端口。 5. 文件系统权限问题 - Namenode需要对数据目录和元数据文件具有适当的访问权限才能启动。如果权限不正确,则可能会出现启动失败的问题。请确保Hadoop用户具有适当的读取和写入权限,以及对Namenode文件具有所有权。 6. Java版本不兼容 - Namenode需要与Hadoop兼容的Java版本。如果Java版本过低或过高,可能会导致Namenode启动失败。请确保您的Java版本符合Hadoop的要求。 总之,启动失败的问题可能有很多原因。您需要审查错误日志以确定具体原因,并采取相应的解决方案。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值