Namenode:功能
- 文件名、目录结构、文件属性权限、生成时间、副本数。
- 数据块和DataNode之间的地址映射关系
- 元数据文件的操作
- 负责管理client客户端请求,数据流不经过namenode只是通知与那个DataNode联系。文件数据块到底存放到哪些DataNode上,是由NameNode决定的,NN根据全局情况做出放置副本的决定,读取文件的时候,NN尽量让client读取离它最近的datanode上的副本,降低带宽消耗和读取时延
- 周期性的接受心跳和块的状态报告信息(包含该DataNode上所有数据块的列表)若接受到心跳信息,NN认为DN工作正常,如果在10分钟后还接受到不到DN的心跳,那么NN认为DN已经宕机
这时候NN准备要把DN上的数据块进行重新的复制。
块的状态报告包含了一个DN上所有数据块的列表,blocks report 每个1小时发送一次- 容错机制
没有Namenode,HDFS就不能工作。事实上,如果运行namenode的机器坏掉的话,系统中的文件将会完全丢失,因为没有其他方法能够将位于不同datanode上的文件块(blocks)重建文件。因此,namenode的容错机制非常重要,Hadoop提供了两种机制。
第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时,也写入到一个远程挂载的网络文件系统(NFS)。
第二种方式是运行一个辅助的Namenode(SecondaryNamenode)。 事实上SecondaryNamenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并,以防止操作日志文件(edit log)变得过大。通常,SecondaryNamenode 运行在一个单独的物理机上,因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份,万一哪天Namenode宕机了,这个备份就可以用上了。
但是辅助Namenode总是落后于主Namenode,所以在Namenode宕机时,数据丢失是不可避免的。在这种情况下,一般的,要结合第一种方式中提到的远程挂载的网络文件
系统(NFS)中的Namenode的元数据文件来使用。
Edit是什么?
edits为二进制文件,记录对HDFS的各种更新操作,客户端执行所有的写操作都会被记录到editlog中。
比如创建文件,删除文件。打开、关闭、重命名文件和目录,都会生成一个edit记录。
客户端对hdfs进行写文件时会首先被记录在edits文件中。
edits修改时元数据也会更新。每次hdfs更新时edits先更新后客户端才会看到最新信息。
Fsimage是什么?
fsimage为二进制文件,保存了最新的元数据检查点,包含了整个HDFS文件系统的所有目录和文件信息。
对于目录来说包括修改时间、访问权限控制信息(目录所属用户,所在组)等。
对于文件来说包括数据块描述信息、修改时间、访问时间等;
简单的说,Fsimage就是在某一时刻,整个hdfs的快照
就是这个时刻hdfs上所有的文件块和目录,分别的状态,位于哪些个datanode,各自的权限,副本个数等。
【注意】Block的位置信息不会保存到fsimage,由DataNode在向NameNode进行注册时重新加载和定期加载。
一般开始时对namenode的操作都放在edits中,为什么不放在fsimage中呢?
因为fsimage是namenode的完整的镜像,内容很大
如果每次都加载到内存的话生成树状拓扑结构,这是非常耗内存和CPU。
把文件和目录的元数据信息持久化地存储到fsimage文件中,每次启动时从中将元数据加载到内存中构建目录结构树
之后的操作记录在edits log中,定期将edits与fsimage合并刷到fsimage中
seen_txid 是什么?
seen_txid文件保存的是一个数字,就是最后一个edits_的数字
NameNode启动和接受请求
1、启动namenode
每次Namenode启动的时候都会将fsimage文件读入内存,并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作,保证内存中的元数据信息是最新的。
2、当NameNode接收到写请求之后
- 会先将该请求记录到edits_inprogess文件中,如果记录成功,将该请求同步更新到内存中,修改内存中的元数据,内存修改完成之后会给客户端分会一个ack表示成功。
- hdfs会给每一次的写操作分配一个编号-事务id-txid
- 当edits文件达到更新条件回会更新到fsimage中更新条件
- 文件大小:当edits_improgress文件达到指定大小会触发更新,默认是64M 大小可以由fs.checkpoint.size(core-site.xml)来指定,默认单位是字节
- 时间大小:当距离上一次更新达到指定时间间隔触发,默认是1H 大小设置fs.checkpoint.period来指定,默认单位是秒 ambari集群配置
- dfs.namenode.checkpoint.txns默认设置为1百万,定义NameNode上的未经检查的事务的数量,这将强制紧急检查点,即使尚未达到检查点周期。
- 重启更新:NameNode重启之后,会自动的将edits_inprogress中的操作更新到fsimage中
- 强制更新:hadoop dfsadmin -rollEdits
- 在更新的时候,会将edits_inprogress重命名为edit_******-******,同时产生一个新的edits_inprogress
- 如果是HA模式更新过程发生在SecondaryNamgenode 通过http get方式拉过去