Hadoop学习笔记之六:HDFS功能逻辑(2)

Lease(租约)

HDFS(及大多数分布式文件系统)不支持文件并发写,Lease是HDFS用于保证唯一写的手段。

Lease可以看做是一把带时间限制的写锁,仅持有写锁的客户端可以写文件。

租约的有效期

HDFS的Lease设定了两个时间限制:softLimit(默认1m),hardLimit(默认1h);

  • Lease持有者在softLimit时限内可以写文件,且不用担心被其它写者抢走Lease;
  • 在超过softLimit仅未及hardLimit时限可以续约,否则Lease可能被其它写者申请走;
  • 在超过hardLimit后,Lease会被释放,写者需要重新申请Lease;对hardLimit的超时检查是由Namenode的lmthread线程执行;


租约的释放

对应于有效期的设计,Lease会在三种情况下被释放:

  • 客户端显式地请求NameNode对某个文件进行 recoverLease操作;
  • Lease超过softLimit,此时另一客户端申请该文件Lease;
  • Lease超过harLimit,由Namenode的lmthread线程发现并执行释放;


租约的释放会引发DataNode对block的recovery过程,当DataNode完成recover block过程后,文件会被关闭。详见Recover Block

租约的结构

Lease由<holder, lastUpdate, paths>组成;

  • holder是客户端的名字,支持以holder为粒度对holder对应的所有Lease进行续约;
  • lastUpdate是该holder上次续约时间,用于进行超时检查;
  • paths是指该holder对哪些路径持有租约;

 

NameNodeResourceMonitor

NameNodeResourceMonitor默认每5秒执行一次检查,查看保存image/edits的目录所在的磁盘卷空间。

磁盘卷空间信息获取是通过调用linux的shell命令实现。

如果剩余可用空间小于默认的100M,则认为该卷磁盘空间不足。当所有磁盘卷空间都不足时,则NameNode会进入safeMode。

 

Recover Block

客户端发起的recover block

HDFS客户端在写流水线(pipeline)的时候,如果遇到异常,会对写文件的最后一个block进行差错恢复(error recovery);这个过程被称为recover block,或block recovery;

注:

  • targets:D1、D3、D4、D5;
  • syncList:D1、D3、D4;
  • successList:D3、D4;

对该过程的简单描述如下,配合上图:

  1. 客户端C在写 D1->D2->D3->D4->D5流水线时,D2异常,C发起对文件最后一个block的recover block过程,根据一定的规则,选定D3为首DN(primaryDatanode),对targets中所有DN进行recover block;
  2. D3向其它的DataNode收集该block的信息,这个过程中可能再遇到DataNode异常或不适合recover block,如D5,将其排除后,组织成syncList队列,并选定其中最短的长度作为;
  3. D3向NameNode(N)发送消息请求更高的Block版本号;
  4. D3向syncList中所有DN发送消息,要求其对该block进行更新(包括内存对象及磁盘文件的版本号、长度,可能引发磁盘文件被切短);在这个过程中,可能再遇到DataNode异常,如D1,将其排除后,组织成successList队列;
  5. D3向N发送消息,提交recover block的结果:删除旧的block对象,增加新的block对象;
  6. 将successList返回给客户端,客户端根据该列表,重新构建流水线,继续写文件;

NameNode发起的recover block

除客户端外,在某些特殊情况下,会由NameNode发起recover block过程;其通常是由recover lease过程引起的(详见Lease(租约)的“租约释放”部分);

与客户端发起的recover block过程相比,不同之处在于:

  • recover block过程的启动过程不是由客户端请求,而是通过NameNode在响应DataNode的心跳时返回命令;
  • 客户端recover block通常不会关闭文件,以期完成恢复后继续写文件;而NameNode完成恢复后会关闭文件,以便客户端可以重新打开;


结合这两点,整个recover block过程的逻辑流程如下:

 

 

Replication(复制)

HDFS通过Replication过程保证数据块始终拥有足够多副本;

当系统发现了Block副本损坏、副本删除等操作时,会在blocksMap中对Block的副本数进行检查,将副本数不足的Block添加到FSNamesystem的neededReplications数据结构中;当进行了关闭文件、添加副本等操作后,也会检查以修正该数据结构。

Namenode节点上运行一个ReplicationMonitor线程,每dfs.replication.interval(默认为3)秒进行一次computeDatanodeWork()操作,主要是为Datanode分配Replication任务(另外还会分配删除任务);

  1. ReplicationMonitor从neededReplications中取出一定数量的Block;
  2. 为每个Block挑选Replication的源节点,将该Block添加到源节点DatanodeDescriptor的replicateBlocks数据结构中;
  3. 同时该将该Block添加到FSNamesystem的pendingReplications数据结构中;
  4. 如果复制后副本数足够,将该Block从neededReplications数据结构中移除;

之后, ReplicationMonitor线程会检查pendingReplications数据结构,找出已经超时的Replication操作,重新加入到neededReplications数据结构中。

在pendingReplications数据结构内部,使用一个数据结构保存当前pending的Replication操作,另一个数据结构保存已经超时的Replication操作,并使用一个线程(timerThread)定期(默认5m)检查,以5m超时;

整体示意图如下:

 

SafeMode(安全模式)

SafeMode是HDFS集群的一种特殊状态,在该状态下,很多对命名空间的修改都被禁止。被禁止的操作有:

  • 修改文件属性;
  • 修改文件属主;
  • 修改文件时间属性;
  • 修改文件复本数;
  • 创建/追加文件;
  • 为文件增加文件块;
  • 舍弃一个文件块;
  • 关闭文件;
  • 重命名文件;
  • 删除文件;
  • 创建目录;
  • 设置配额;
  • 对文件进行同步;fsync
  • 对文件块进行同步;commitBlockSynchronization
  • 获取下一个GenerationStamp;
  • 恢复租约;
  • 更新租约;
  • 获取、更新、销毁安全令牌;
  • 滚动元数据存储文件(fsimge及edits)

NameNode进入safeMode后,对内存及磁盘上的元数据文件的“小规模修改”都无法进行,但“大规模替换”,如加载(loadFSImage、loadFSEdit)、写出(saveNamespace)则可以进行。

safeMode的进入条件

在0.20.2-cdh3u2版本中,是否应当进入safeMode由以下参数决定:

参数名 默认值 作用
dfs.safemode.threshold.pct 95% 如果已经汇到的block数少于总block数的该比例,则需要进入safeMode;
dfs.safemode.min.datanodes 0  当前存活的datanode个数少于该数字则需要进入safeMode;

此外,当namenode节点资源不足时也会进入safeMode,见:NameNodeResourceMonitor

safeMode在以下过程中会触发条件检查:

  • 设定block总数(命名空间初始化时执行);
  • 增加安全block的个数;
  • 减少安全block的个数;
  • 注册一个datanode;(注:在hadoop-0.2x版本中,该过程并不触发条件检查)
  • 删除一个datanode;(注:同上)

safeMode监测

NameNode进入safeMode的同时,会启动一个线程进行safeMode状态监测,其每秒钟检查一次是否可以离开safeMode;离开safeMode后,线程结束。

posted @ 2013-08-12 19:04 ZisZ 阅读(...) 评论(...) 编辑 收藏