Hadoop Ha 检查点原理

转载来自:https://blog.csdn.net/amber_amber/article/details/47003589

hdfs将文件系统的元数据信息存放在fsimage和一系列的edits文件中。在启动HDFS集群时,系统会先加载fsimage,然后逐个执行所有Edits文件中的每一条操作,来获取完整的文件系统元数据。

Edits & fsimage文件
HDFS的存储元数据是由fsimage和edits文件组成。fsimage存放上次checkpoint生成的文件系统元数据,Edits存放文件系统操作日志。checkpoint的过程,就是合并fsimage和Edits文件,然后生成最新的fsimage的过程。
Edits文件: 在配置了HA的hadoop2.x版本中,active namenode会及时把HDFS的修改信息(创建,修改,删除等)写入到本地目录,和journalnode上的Edits文件,每一个操作以一条数据的形式存放。Edits文件默认每2分钟产生一个。正在写入的Edits文件以edits_inprogress_*格式存在。
fsimage文件: fsimage里保存的是HDFS文件系统的元数据信息。每次checkpoint的时候生成一个新的fsimage文件,fsimage文件同步保存在active namenode上和standby namenode上。是在standby namenode上生成并上传到active namenode上的。

checkpoint过程
配置了HA的HDFS中,有active和standby namenode两个namenode节点。他们的内存中保存了一样的集群元数据信息,这个后续我会详细用一篇文章介绍HA,所以这里就不多说了。因为standby namenode已经将集群状态存储在内存中了,所以创建检查点checkpoint的过程只需要从内存中生成新的fsimage。

详细过程如下: (standby namenode=SbNN, activenamenode=ANN)

1. SBNN查看是否满足创建检查点的条件:

(1) 距离上次checkpoint的时间间隔 >= ${dfs.namenode.checkpoint.period}
(2) Edits中的事务条数达到${dfs.namenode.checkpoint.txns}限制
这两个条件任何一个被满足了,就触发一次检查点创建。

2. SbNN将内存中当前的状态保存成一个新的文件,命名为fsimage.ckpt_txid。其中txid是最后一个edit中的最后一条事务的ID(transaction ID)。然后为该fsimage文件创建一个MD5文件,并将fsimage文件重命名为fsimage_txid。

3. SbNN向active namenode发送一条HTTP GET请求。请求中包含了SbNN的域名,端口以及新fsimage的txid。

4. ANN收到请求后,用获取到的信息反过来向SbNN再发送一条HTTP GET请求,获取新的fsimage文件。这个新的fsimage文件传输到ANN上后,也是先命名为fsimage.ckpt_txid,并为它创建一个MD5文件。然后再改名为fsimage_txid。fsimage过程完成。


checkpoint相关配置

dfs.namenode.checkpoint.period
--两次检查点创建之间的固定时间间隔,默认3600,即1小时。

dfs.namenode.checkpoint.txns
--未检查的事务数量。若没检查事务数达到这个值,也触发一次checkpoint,1,000,000。

dfs.namenode.checkpoint.check.period
--standby namenode检查是否满足建立checkpoint的条件的检查周期。默认60,即每1min检查一次。

dfs.namenode.num.checkpoints.retained
--在namenode上保存的fsimage的数目,超出的会被删除。默认保存2个。

dfs.namenode.num.checkpoints.retained
--最多能保存的edits文件个数,默认为1,000,000. 官方解释是为防止standby namenode宕机导致edits文件堆积的情况,设置的限制,不是太明白。

dfs.ha.tail-edits.period
--standby namenode每隔多长时间去检测新的Edits文件。只检测完成了的Edits, 不检测inprogress的文件。
=========================================================================================

cloudera 的检查点文档:https://blog.cloudera.com/blog/2014/03/a-guide-to-checkpointing-in-hadoop/

Hadoop中的检查点指南

了解检查点在HDFS中的工作原理可以区分健康的群集或失败的群集。

检查点是在HDFS中维护和保存文件系统元数据的重要部分。这对于有效的NameNode恢复和重启至关重要,并且是整个群集运行状况的重要指标。但是,检查点也可能成为Apache Hadoop集群运营商混淆的根源。

在这篇文章中,我将解释HDFS中检查点的目的,检查点如何在不同的群集配置中工作的技术细节,然后完成一系列操作问题和有关此功能的重要错误修复。

HDFS中的文件系统元数据

首先,让我们首先介绍NameNode如何保留文件系统元数据。

HDFS元数据更改将持久保存到编辑日志中。

在较高的层次上,NameNode的主要职责是存储HDFS命名空间。这意味着目录树,文件权限以及文件到块ID的映射。重要的是,将此元数据(及其所有更改)安全地保存到稳定存储以实现容错。

此文件系统元数据存储在两个不同的结构中:fsimage和编辑日志。fsimage是一个文件,表示文件系统元数据的时间点快照。但是,虽然fsimage文件格式的读取效率非常高,但它不适合进行小的增量更新,例如重命名单个文件。因此,不是每次修改命名空间时都编写新的fsimage,而是NameNode会在编辑日志中记录修改操作的持久性。这样,如果NameNode崩溃,它可以通过首先加载fsimage然后重放编辑日志中的所有操作(也称为编辑或事务)来恢复其状态,以赶上名称系统的最新状态。编辑日志包含一系列文件,称为编辑日志段,

另外,对于传统文件系统来说,在另一种存储格式之上使用日志进行增量更改的这种模式非常常见。日志结构文件系统将这种情况发挥到极致,仅使用日志来保存数据,但更常见的日记文件系统(如EXT3,EXT4和XFS)支持在将日志应用到磁盘上的最终位置之前将更改写入日志。

为什么Checkpointing很重要?

典型的编辑范围从10到100个字节,但随着时间的推移,足够的编辑可能会累积变得难以处理。这些大型编辑日志可能会产生一些问题。在极端情况下,它可以填满节点上的所有可用磁盘容量,但更巧妙的是,大型编辑日志可以在NameNode重新应用所有编辑时显着延迟NameNode启动。这是检查点的来源。

检查点是一个获取fsimage和编辑日志并将它们压缩成新fsimage的过程。这样,NameNode可以直接从fsimage加载最终的内存中状态,而不是重放可能无限制的编辑日志。这是一个更有效的操作,减少了NameNode的启动时间。

Checkpointing从旧的fsimage和编辑日志创建一个新的fsimage

但是,创建新的fsimage是一种I / O和CPU密集型操作,有时需要几分钟才能完成。在检查点期间,名称系统还需要限制来自其他用户的并发访问。因此,HDFS不会暂停活动的NameNode来执行检查点,而是将其延迟到SecondaryNameNode或Standby NameNode,具体取决于是否配置了NameNode高可用性。检查点的机制取决于是否配置了NameNode高可用性; 我们将涵盖两者。

但在任何一种情况下,检查点都是由两个条件之一触发的:如果自上一个检查点(dfs.namenode.checkpoint.period)以来已经过了足够的时间,或者是否累积了足够的新编辑日志事务(dfs.namenode.checkpoint.txns)。检查点节点定期检查是否满足这些条件中的任何一个(dfs.namenode.checkpoint.check.period),如果满足,则启动检查点过程。

使用备用NameNode检查点

在处理HA设置时,检查点实际上要简单得多,所以让我们先介绍一下。

的NameNode高可用性配置,活动和备用NameNodes具有一个共享的存储,其中的编辑被存储。通常,这个共享存储是三个或更多JournalNode的集合,但是它从抽象点过程中抽象出来。

备用NameNode通过定期重播由活动NameNode写入共享编辑目录的新编辑来维护命名空间的相对最新版本。因此,检查点就像检查是否满足两个前提条件中的任何一个一样简单,将命名空间保存到新的fsimage(大致相当于hdfs dfsadmin -saveNamespace在命令行上运行),然后通过HTTP将新的fsimage传输到活动的namenode。

配置了NameNode HA的检查点

这里,Standby NameNode缩写为SbNN,Active NameNode缩写为ANN:

  1. SbNN检查是否满足两个前提条件中的任何一个:自上一个检查点以来经过的时间或累计编辑的数量。
  2. SbNN将其名称空间保存到具有中间名称的新fsimage fsimage.ckpt_,其中txid是最新编辑日志事务的事务ID。然后,SbNN为fsimage写入MD5文件,并将fsimage重命名为fsimage_。在此过程中,大多数其他SbNN操作都被阻止。这意味着管理操作,如NameNode故障转移或访问部分SbNN的webui。常规HDFS客户端操作(例如列表,读取和写入文件)不受影响,因为这些操作由ANN提供服务。
  3. SbNN发送一个HTTP GET到活动NN的GetImageServlet/getimage?putimage=1。URL参数还具有新fsimage的事务ID以及SbNN的主机名和HTTP端口。
  4. 活动NN的servlet使用GET请求中的信息反过来自己GET回到SbNN GetImageServlet。与备用数据库类似,它首先使用中间名保存新的fsimage,为fsimage fsimage.ckpt_创建MD5文件,然后将新的fsimage重命名为fsimage_

使用SecondaryNameNode检查点

在非HA部署中,检查点是在SecondaryNameNode而不是备用NameNode上完成的。由于没有共享编辑目录或编辑日志的自动拖尾,因此在继续执行相同的基本步骤之前,SecondaryNameNode必须首先执行几个步骤来刷新其命名空间视图。

具有注释步骤的2NNNN的时间图

这里,NameNode缩写为NN,SecondaryNameNode缩写为2NN:

  1. 2NN检查是否满足两个前提条件中的任何一个:自上一个检查点以来经过的时间或累计编辑的数量。
    • 在没有共享编辑目录的情况下,需要通过显式RPC向NameNode(NamenodeProtocol#getTransactionId)查询最新的编辑日志事务ID 。
  2. 2NN触发编辑日志滚动,结束当前编辑日志段并启动新的日志段。NN可以继续编写对新段的编辑,而SNN压缩所有以前的段。这还返回当前fsimage的事务ID和刚刚滚动的编辑日志段。在HA配置中不需要显式触发编辑日志卷,因为备用NameNode会定期将编辑日志滚动到与检查点正交。
  3. 给定这两个事务ID,2NN将根据需要获取新的fsimage并编辑文件 GET到NN GetImageServlet。2NN可能已经有一些来自先前检查点的文件(例如当前的fsimage)。
  4. 如有必要,2NN将从新下载的fsimage重新加载其命名空间。
  5. 2NN重播新的编辑日志段以赶上当前的事务ID。

从这里开始,其余部分与具有StandbyNameNode的HA情况相同。

  1. 2NN将其命名空间写入新的fsimage。
  2. 2NN通过HTTP GET与NN联系/getimage?putimage=1,导致NN的servlet自己做 GET2NN以下载新的fsimage。

运作影响

与检查点相关的最大操作问题是它何时未能发生。我们已经看到NameNode累积了数百GB编辑日志的情况,在磁盘完全填满并崩溃NN之前没有人注意到。当发生这种情况时,除了重新启动NN并等待它重放所有编辑之外没有太多事情要做。由于此问题的潜在严重性,Cloudera Manager将警告当前fsimage是否已过期,检查点2NN或SbNN是否已关闭,以及NN磁盘是否接近容量。

检查点是一种非常I / O和网络密集型操作,可能会影响客户端性能。在具有数百万个文件和多GB fsimage的大型群集上尤其如此,因为将新的fsimage复制到NameNode会占用所有可用带宽。在这种情况下,传输速度可以受到限制dfs.image.transfer.bandwidthPerSec。如果您确实调整了此参数,则可能还需要dfs.image.transfer.timeout根据预期的传输时间进行调整。

如果您使用的是较早版本的CDH,则还有一些与检查点相关的问题可能会使升级变得有价值。

  • HDFS-4304(在CDH 4.1.4,4.2.14.3.0中修复)。以前,可以编写一个如此大的编辑日志操作,以便在重放编辑日志时无法读取。这将导致检查点和NameNode启动失败。这对于包含大量块的文件来说是一个问题,因为关闭文件涉及将所有块ID写入编辑日志。修复方法是简单地增加允许的最大编辑日志操作的大小。
  • HDFS-4305  (在CDH 4.3.0中修复)。 与上面的HDFS-4304相关,具有大量块的文件通常是由于配置错误造成的。例如,用户可能会意外地将块大小设置为128KB而不是128MB,或者可能仅将单个reducer用于大型MapReduce作业。通过让NameNode强制执行最小块大小以及每个文件的最大块数来解决此问题。
  • HDFS-4816(在CDH 4.5.0中修复)。以前,从备用NN到活动NN的映像传输保持备用NN的写锁定。因此,如果活动NN在图像传输期间失败,则备用NN将无法在传输完成之前进行故障转移。由于传输fsimage实际上并不修改任何命名空间数据,因此传输只是移动到临界区之外。
  • HDFS-4128(在CDH 4.3.0中修复)。如果2NN在编辑日志重放期间遇到内存不足(OOM)异常,它可能会陷入一种不一致的状态,即在将来的检查点尝试期间尝试从不正确的偏移重放编辑日志。因为即使我们修复了日志重放,这个OOM很可能会继续发生,所以如果2NN无法重播日志几次,它现在就会中止。但是,底层修复是使用与NameNode相同的堆大小配置2NN。
  • HDFS-4300(在CDH 4.3.0中修复)。如果2NN或SbNN在传输编辑文件时遇到错误,则以后不会重试下载完整文件。此过程将停止检查点,因为无法重播部分编辑文件。首先将编辑文件传输到临时位置,然后在传输完成后将其重命名为其最终目标,从而解决了此问题。
  • HDFS-4569(在CDH4.2.1CDH4.3.0中修复)。将图像传输超时从1分钟提高到10分钟。默认超时导致使用多GB fsimages进行检查点问题,尤其是在启用限制时。

结论

检查点是健康HDFS操作的重要部分。在本文中,您了解了文件系统元数据如何在HDFS中保留,检查点对此角色的重要性,检查点在HA和非HA设置中的工作原理,最后介绍了与检查点相关的一些重要修复和改进。

通过了解检查点的目的及其工作原理,您现在掌握了在生产集群中调试这些问题的知识。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值