HDFS恢复过程1

运行或者移动生产环境中的Hadoop时,对很好的掌握HDFS的恢复过程是非常重要的。
HDFS中一个重要的设计需求就是要保证在生产部署中持续正确的操作。尤其复杂的是在网络和节点故障的情况下保证写入HDFS的正确性,租约恢复、block恢复和pipeline恢复保证了写的正确性。理解这些恢复操作何时何地被调用,以及做了什么,能帮助用户或者开发者理解HDFS集群的原理。

在这篇博客中,你会对那些恢复流程有个更深入的理解。首先简单介绍下HDFS write pipeline和恢复流程,对block/replica的状态和generation stamps的概念进行解释,然后逐步介绍租约恢复和block恢复。

这系列文章被分为两篇:第一篇介绍租约恢复和block恢复的细节,第二篇主要介绍pipeline恢复。想了解更多的内容,请参考设计文档:Append, Hflush, and Read for implementation details

背景

HDFS中,文件被分为块存储。HDFS中的文件可以被多client同时读,但只能被一个client写入。block的多副本存储在不同的dn上保证了HDFS的容错需求。其中副本的个数被称为副本因子。当一个新文件的block被创建,或者打开一个已经存在的文件(因为写或者追加),HDFS写操作会创建一个由dns组成的pipeline来接收并存储副本(副本因子决定了在pipeline中dns的个数)。下图是block写入pipeline的流程:
block写入pipeline
client读文件时从存放文件block的dns中选择一个dn,并请求从dn上进行数据传输。

下面两个应用场景突显了容错的重要性:

  • HBase的Region Server(RS)写时会先写入WAL,WAL是一个HDFS文件,能够防止数据丢失。如果一个RS宕机,一个新的RS会启动并通过读取WAL文件去重构先前RS的状态。如果在RS宕机的时候,写入pipeline没有完成,在pipeline中的dns上的数据可能并没有同步。为了重构RS正确的状态,HDFS必须保证从WAL中读取数据的正确性。
  • Flume客户端需要实时的将数据写入HDFS中,甚至在pipeline中存在一些dn失败或者停止响应的情况下,也必须保证能够持续的写。

租约恢复、block恢复和pipeline恢复发生在以下的情况下:

  • 在client可以往HDFS上写文件之前,必须从nn上得到一个租约(Lease),这个租约也就相当于一个写锁。租约保证了只有一个client写的语义。如果当前client想要维持写操作,租约必须在预定义的时间周期内更新租约。如果一个租约没有被更新或者持有该租约的client死了,则租约会过期。当租约过期之后,HDFS会关闭租约对应的文件并且会释放代表这个client的租约,然后其它clients就能够写这个文件了。这个过程被称为租约回收
  • 当租约恢复发生的时候,如果一个文件正在写入的最后一个block没有传播到在pipeline中的所有dn,写入到不同dn上的数据可能不同。在租约恢复导致这个文件被关闭之前,有必要保证最后一个block的所有replicas相同,这个过程被称为block恢复block恢复只有在租约恢复时被触发,并且租约恢复只会触发一个文件的最后一个block(如果该block不是COMPLETE状态)进行block恢复。
  • 在写pipeline操作中,有些dn可能会失败。如果发生失败,底层的写操作不能被简单粗暴的失败。HDFS会尝试恢复这些error,允许client能够继续写入pipeline中。从pipeline中恢复error的流程被称为pipeline恢复。

下面的章节将对这些过程进行更加深入的介绍。

Blocks、Replicas和他们的状态

为了区分Namenode中的blocks和DataNode中的blocks,将NameNode中的blocks称为blocks,将DataNode中的blocks称为replicas。

DataNode中的replica有如下状态(定义在org.apache.hadoop.hdfs.server.common.HdfsServerConstants.java中):

  • FINALIZED: 当replica是这个状态时,该replica的写入操作已经完成,数据的大小不会发生变化,除非对该replica进行append操作。有一样generation stamp(GS)的block的所有replica是相同的。finalized replica的GS可能会在block恢复中递增。
  • RBW(Replica Being Written): 不管是新建一个文件还是重新打开一个文件进行追加,此时任何一个正在被写入的replica都RBW状态。RBW状态的replica总是文件的最后一个block。数据依然正在写入该replica,replica并没有finalized。RBW replica中的数据(不一定是所有的数据)是可读的。如果有任何故障发生,RBW状态的replica会尝试保存数据。
  • RWR(Replica Waiting to be Recovered): 如果dn宕机或者重启了,其上的所有RBW状态的replicas将会将状态转换为RWR。RWR状态下的replica将会变成过期的,然后被丢弃;或者参与租约恢复中。
  • RUR(Replica Under Recovery): 在租约恢复的过程中,任何一个非TEMPORARY状态的replica都有可能转换为RUR状态。
  • TEMPORARY: 在block复制(由replication monitor或者balancer引起的block复制操作)中会出现temporary状态的replica。此状态下的replica与RBW状态类似,只是该状态下的数据是不可见的。如果block复制失败,TEMPORARY状态下的replica会被删除。

block在NameNode中的状态(定义在org.apache.hadoop.hdfs.server.common.HdfsServerConstants.java)如下:

  • UNDER_CONSTRUCTION: block正在写入时处于此状态。在UNDER_CONSTRUCTION下的block是被打开文件的最后一个block,该block的长度和generation stamp都是可变的,并且它的数据(不一定是所有的数据)是可见的。nn保持写pipeline的跟踪(有效RBW replicas的位置),和对RWR replicas的定位
  • UNDER_RECOVERY: 如果一个文件的租约超期时,该文件的最后一个block是UNDER_CONSTRUCTION,在block恢复开始时,该block会变为UNDER_RECOVERY。
  • COMMITTED: COMMITTED意味着一个block的数据和generation stamp不会发生变化(除非再次打开进行追加),并且比上报FINALIZED状态、有着相同GS/length的replicas的最小副本数少(具体不太明白,可能翻译的有问题,附上原文–and there are fewer than the minimal-replication number of DataNodes that have reported FINALIZED replicas of same GS/length)。为了提供读服务,COMMITTED状态的block必须保持对RBW replicas位置的跟踪和FINALIZED replicas的GS、length的跟踪。当client请求nn增加一个block或者关闭文件时,处于UNDER_CONSTRUCTION状态的block将变为COMMITTED状态。如果一个文件的最后一个block或者倒数第二个block是COMMITTED状态,则该文件不能被关闭,client必须进行重试。
  • COMPLETE: 当发现了有着相同GS/length的FINALIZED状态下的replicas满足最小副本数,则该block由COMMITTED转为COMPLETE状态。只有当所有的block都变成COMPLETE时,该文件才能被关闭。即使一个block不满足最小副本数,也可能被强制变为COMPLETE,例如当先前的block还没有到COMPLETE状态,client请求一个新block,此时会将先前的block强制变为COMPLETE状态。

DataNodes将replica的状态持久化到磁盘,但是NameNode并不会讲block的状态持久化到磁盘。当NameNode重启时,nn会将先前打开文件的最后一个block的状态变为UNDER_CONSTRUCTION,将其余block的状态变为COMPLETE。

replica和block的状态转换图如下:
replica-state
block-state

Generation Stamp

对于每一个block来说,GS是一个单调递增的8-byte数字,由NameNode进行维护。block和replica的GS处于下面的目的被引入:

  • 检测一个block的陈旧的replica: 也就是说,这个replica的GS小于这个block的GS。这是可能发生的,例如一个追加操作,不知什么原因跳过了此replica,没有更新此replica,使该replica的GS依然是为追加之前的GS,而其余replica的GS现在已经是追加之后的GS。
  • 当一个DataNode死了一段时间,然后又重新加入了集群,此时在此DataNode上检测过时的replica。

当下面的情况发生时,一个新的GS会产生:

  • 创建一个新文件
  • client对一个已经存在的文件进行append或者truncate
  • client在向dns上写数据时发生错误,会请求一个新的GS
  • NameNode对一个文件发起租约恢复操作

Lease Recovery and Block Recovery

Lease Manager

租约在NameNode上被lease Manager进行管理。NameNode跟踪每个client打开的写文件。client没有必要为它打开的每个写文件进行单独更新租约,而是定期的向NameNode发送一个请求对所有的文件进行租约更新。

每个NameNode管理一个单独的HDFS namespace,每个HDFS namespace会有一个单独的lease manager来管理与该namespace相关的所有client租约。Federated HDFS集群可能有多个namespace,每个namespaces都有其自己的lease manger。

lease manager维护这两个超时时间(目前这两个超时时间是不可配置的),一个是softLimit(1m),另一个是hardLimit(1h)。lease manager管理的所有租约都遵守相同的softLimit和hardLimit。在softLimit过期之前,持有某文件租约的client独占该文件的写权限。如果softLimit超期并且client并没有更新租约或者关闭了文件,另一个client能强制接管这个租约。如果hardLimit超期并且client没有更新租约,HDFS假设此client已经退出,将自动关闭代表client的文件,从而恢复租约。

事实上client持有的某个文件租约并不会阻止其它client对此文件进行读,一个文件能同时有多个client进行读,但只能有一个client进行写。

lease manager内部支持的操作:

  • 为一个client增加一个租约和路径(如果这个client已经有了一个租约,则增加这个路径到这个租约。否则,创建一个新的租约,并添加路径到租约里面)
  • 移除client的租约和路径(如果这是租约的最后一个路径,则移除这个租约)
  • 检查soft/hard limit是否过期,
  • 和对给定的client进行renew租约。

lease manager有一个monitor线程,此线程周期性(每2s)的检查所有租约是否hardLimit超期,如果超期,则对租约中的所有文件触发租约恢复。

HDFS client通过org.apache.hadoop.hdfs.LeaseRenewer.LeaseRenewer类renews它自己的租约。LeaseRenewer对每个NameNode上的每个user运行一个线程去周期性的检查,当间隔超过租约检查的一半,则更新LeaseRenewer对应的所有client的租约。

(注意: 一个HDFS client只会关联一个NameNode; 请看它的构造器 org.apache.hadoop.hdfs.DFSClient)。 如果同一个应用想要访问联邦集群的不同NS的不同的文件,需要为每一个NameNode创建client。

Lease Recovery Process

租约的恢复过程被NameNode触发用来对给定的client进行恢复租约。在通过监控线程检查到达hardLimit的有效期,或者softLimit过期时,其他客户端尝试接管租约的情况下NameNode会触发Lease Recovery。Lease Recovery会检查相同client打开的每个写文件,如果这个文件的最后一个block不是COMPLETE状态则执行block recovery,并且关闭这个文件。Block Recovery只有在Lease Recovery时会被触发

下面是给定文件f的Lease Recovery算法。当client死了,该算法适用于该client打开的每个写文件。

1、得到包含f最后一个block的dns
2、从dns中分配一个dn作为primary dn p
3、p从NameNode中得到一个新的GS
4、p从每个dn上得到block的信息
5、p就是这个block的最小长度
6、p更新dns,拥有合法的GS,即新的GS和最小的block长度。
7、p确认NameNode更新的结果.
8、NameNode更新BlockInfo
9、NameNode移除f的租约(其他写的操作现在可以维护这个文件f的租约,进行写入操作)
10、NameNode提交这些改变到edit log.
第三步到第七步是算法的block recovery部分。如果一个文件需要block recovery,NameNode从拥有该文件最后一个block的replica的DataNodes中挑选一个primary DataNode,使其DataNode协调其余DataNodes进行block recovery。结束之后,这个DataNode想NameNode报告,NameNode更新这个block的内部状态,移除这个租约,最后想edit log提交改变。

有时管理员在hardLimit未超时之前,需要强制对某个文件进行Lease Recovery,此时可以使用一个CLI
hdfs debug recoverLease [-path <path>] [-retries <num-retries>]

总结

租约恢复,块恢复,和pipeline恢复对HDFS容错至关重要。他们一起保证了HDFS写的持久性和一致性,即使是在网络或者节点异常的情况下。

在下一篇中将介绍pipeline recovery。

原文地址

您的肯定,是我装逼的最大的动力!