《高可用性的HDFS-HADOOP分布式文件系统深度实践》读书笔记

最近有项目在用HADOOP,比较关心NameNode的HA机制,翻了《高可用性的HDFS》,感觉整体内容并不多,较多的是代码、环境安装和测试,不过对于我这个门外汉来说,快速入门吧。以下是笔记:

HDFS的HA主要由NameNode的HA决定,NameNode的可靠性主要取决于自身计算机硬件系统的可靠性、系统软件以及HDFS软件的可靠性;NameNode的可维护性则取决于元数据的可靠性以及NameNode服务恢复时间。

比较成熟的HA解决方案有:

  • Hadoop的元数据库备份方案
  • Hadoop的Secondary NameNode方案
  • Hadoop的Checkpoint Node方案
  • Hadoop的Backup Node方案
  • DRDB方案
  • Facebook的Avatarnode方案
    元数据备份方案和DRRB方案不能单独使用,因为在系统的运行期间,没有相应的checkpoint机制,会造成日志的无限制增长。

Hadoop的元数据库备份方案

hadoop的自身failover机制,配置dfs.name.dir,将元数据保存到多个目录(一个本地,一个远程,通过NFS进行共享)

  • hadoop自带机制,成熟可靠,元数据有多个备份,写多份效率低;
  • 没有做到热备,需要重启NameNode,恢复时间与文件系统规模成正比;

Hadoop的Secondary NameNode方案

启动一个Secondary NameNode节点,定期从NameNode下载元数据信息(元数据镜像fsimage和操作日志edits),然后将fsimage和edits进行合并,生成新的fsimage,本地保存再推送到NameNode,再重置edits。

  • 定期做checkpoint,Secondary NameNode不是最新数据,存在一致性问题;
  • 没有热备;

Hadoop的Checkpoint Node方案

原理同上,但采用checkpoint机制进行备份。

Hadoop的Backup Node方案

不成熟,0.21以上版本支持,特性开发中

最终目标是为HDFS提供NameNode的热备节点,减少服务恢复时间,实现原理:通过同步更新机制,在BackupNode节点中保存一份与NameNode完全一致的内存镜像,并且当NameNode无法提供服务时,能自动接管。

三个阶段:

  • Checkpoint Node,定期checkpoint到磁盘;
  • Backup Node,改进checkpoint机制,同步更新backup node内存,backup node利用自身镜像做checkpoint;
  • Standby Node,实现热备。
    目前0.21.0实现了第一、二阶段。

在第二阶段的Backup Node中,采用了日志池(journal spool)的机制,用于缓存NameNode发送过来的来不及处理的日志记录。

DRDB方案

  • 元数据有多个备份,并且保持最新状态
  • 备份工作由DRDB完成,NameNode无需同步写多个备份目录,效率由于hadoop元数据备份方案;
  • 没有热备,备份节点切换时间长

Facebook的AvatarNode方案

Facebook提出并实现了HDFS的热备。Active Node作为Primary NameNode对外提供服务,Standby Node处于Safe mode模式,内存中保存Primary NameNode最新的元数据信息。Active Node和Standy Node通过NFS共享存储进行交互。DataNode同时向Active Node和Standby Node发送Block location信息。

  • 提供热备,切换时间短;
  • facebook的代码版本;
  • Primary AvatarNode和Standby Node都继承自NameNode,Primary AvatarNode对外提供服务;
  • Standyby AvatarNode也运行一个NameNode进程,并与Primary AvatarNode的内存元数据保持同步,两者通过NFS进行元数据同步;
  • DataNode将Primary AvatarNode和Standby AvatarNode视之为两个NameNode,分别上报Block信息等;
  • Clients是Facebook提供的AvatarNode客户端;
  • NFS理论上是一个新的单一故障点(应该可以用SYMANTEC CFS代替
    注:BackupNode类似于同步写,日志要等待BackupNode更新后再将日志记录写到磁盘;而AvatarNode则是异步写,将日志写入NFS共享目录即结束。

Block更新同步问题:客户端写入一个文件A,写入成功后,Data Node分别向Primary和Standby报告Block位置信息,但由于同步周期未到,Standby里没有文件A的信息,此时Standby会循环检查对应关系,直到收到Primary送过来的日志有关于文件A与Block的对应关系信息。

关于源代码:

  • Patch方式,直接作用于hadoop官方版,支持0.20;
  • Facebook维护的hadoop分支;

元数据解析

元数据有三类重要信息:

  • 文件和目录自身的属性信息,例如文件名,目录名,父目录信息,文件大小,创建时间,修改时间等;
  • 文件内存存储相关信息,例如文件分块,副本个数,每个副本所在的DataNode信息等;
  • HDFS中素有DataNode的信息,用于DataNode管理;
    从来源上讲,元数据主要来源于NameNode磁盘上的元数据文件,包括元数据镜像fsimage和元数据操作日志edits两个文件。

INode

文件和目录的抽象,所有INode信息完全位于内存。(类FSImage是内存元数据和磁盘元数据文件之间的桥梁,做内存数据持久化和磁盘文件加载)。

  • HDFS没有采用定期导出元数据的办法,而是采用FSImage+edits的备份机制。
  • HDFS启动时会读取元数据镜像文件和日志文件到内存,进行合并形成最新的内存元数据,再保存到磁盘,形成新的磁盘镜像文件和日志文件。需要消耗一定的时间做合并
  • 运行过程中HDFS不再从内存中到处元数据,而只是记录日志文件。

Block

按照文件大小划分成块,默认Block大小为64MB。

磁盘元数据文件

  • fsimage:元数据镜像文件,存储的是某一时刻NameNode内存元数据信息,包括所有的INode信息、正在写入的文件信息以及其他的一些状态信息;
  • edits:日志文件,保存了该时刻以后元数据的操作记录;
  • fstime:保存了最近一次Checkpoint的时间;
  • VERSION:标志性文件,最后创建,表明前三个文件创建成功。
  • fsimage, edits都有两个状态,以文件名区分。fsimage.ckpt表示checkpoint过程中上传到NameNode的fsimage文件,checkpoint结束时重明明;edits.new同样如此。

几个统计数据

  • facebook集群存储了1.5亿个文件,加载namenode元数据和等待块位置映射信息上报这两个阶段各自耗费的时间大概都在20分钟左右;
  • 在yahoo运行的15个集群中,三年时间内,只有3次NamoNode的故障与硬件问题有关。

关于hadoop的版本

hadoop version

  • Facebook Hadoop分支的版本是再0.20-append基础上,加入自身特性发展起来的;
  • Clourera CDH3
    BTW. 这是第一篇用Mou编写的markdown格式的文章,挺方便的,要是支持直接发布到wordpress上就更好了。