【问题标题】:Hadoop 2.0 Name Node, Secondary Node and Checkpoint node for High AvailabilityHadoop 2.0 名称节点、辅助节点和检查点节点以实现高可用性
【发布时间】:2019-01-27 13:18:15
【问题描述】:

看完ApacheHadoop documentation后,对Secondary node & check point node的职责理解有点疑惑

我很清楚Namenode的角色和职责:

  • NameNode 将文件系统的修改存储为附加到本机文件系统文件的日志,编辑。当 NameNode 启动时,它会从图像文件 fsimage 中读取 HDFS 状态,然后应用编辑日志文件中的编辑。然后它将新的 HDFS 状态写入 fsimage 并使用空的编辑文件开始正常操作。由于 NameNode 仅在启动期间合并 fsimage 和编辑文件,因此在繁忙的集群上,编辑日志文件可能会随着时间的推移变得非常大。较大的编辑文件的另一个副作用是下次重新启动 NameNode 需要更长的时间。

但我在理解辅助名称节点和检查点名称节点职责方面有一点困惑。

辅助NameNode:

  • 辅助 NameNode 定期合并 fsimage 和编辑日志文件,并将编辑日志大小保持在限制范围内。它通常在与主 NameNode 不同的机器上运行,因为它的内存需求与主 NameNode 的顺序相同。

检查点节点:

  • 检查点节点定期创建命名空间的检查点。它从活动 NameNode 下载 fsimage 和编辑,在本地合并它们,然后将新图像上传回活动 NameNode。 Checkpoint 节点通常运行在与 NameNode 不同的机器上,因为它的内存需求与 NameNode 的顺序相同。 Checkpoint 节点由配置文件中指定的节点上的 bin/hdfs namenode -checkpoint 启动。

Secondary namenode 和 Checkpoint 节点之间的职责似乎并不清楚。两者都在进行编辑。那么最终谁来修改呢?

另一方面,我在 jira 中创建了两个错误,以消除理解这些概念时的歧义。

issues.apache.org/jira/browse/HDFS-8913 
issues.apache.org/jira/browse/HDFS-8914 

【问题讨论】:

    标签: hadoop hdfs hadoop2 high-availability


    【解决方案1】:

    NameNode(主)

    NameNode 存储 HDFS 的元数据。 HDFS 的状态存储在一个名为 fsimage 的文件中,是元数据的基础。在运行时修改只是写入一个名为edits的日志文件。在 NameNode 的下一次启动时,从 fsimage 读取状态,将编辑的更改应用于该状态,并将新状态写回 fsimage。在此编辑被清除并且包含现在准备好新的日志条目之后。

    检查点节点

    引入了检查点节点来解决 NameNode 的缺点。这些更改只是写入编辑,而不是在运行时合并到 fsimage。如果 NameNode 运行一段时间,编辑会变得很大,并且下一次启动将需要更长的时间,因为必须对状态应用更多更改才能确定元数据的最后状态。

    检查点节点定期从 NameNode 获取 fsimage 和编辑并将它们合并。结果状态称为检查点。在此之后将结果上传到 NameNode。

    还有一种类似的节点称为“辅助节点”,但它没有“上传到 NameNode”功能。所以NameNode需要从Secondary NameNode获取状态。这也令人困惑,因为名称表明如果 NameNode 失败,Secondary NameNode 会接受请求,但事实并非如此。

    备份节点

    备份节点提供与检查点节点相同的功能,但与名称节点同步。它不需要定期获取更改,因为它会接收一系列文件系统编辑。从名称节点。它在内存中保存当前状态,只需将其保存到图像文件中即可创建新的检查点。

    【讨论】:

    • 看起来 Apache 没有正确记录该功能。>* ThCommunication Protocols 所有 HDFS 通信协议都位于 TCP/IP 协议之上。客户端与 NameNode 机器上的可配置 TCP 端口建立连接。它与 NameNode 对话 ClientProtocol。 DataNode 使用 DataNode 协议与 NameNode 通信。远程过程调用 (RPC) 抽象包装了客户端协议和数据节点协议。按照设计,NameNode 从不启动任何 RPC。相反,它只响应 DataNode 或客户端发出的 RPC 请求。
    • 在 Jara 中创建了两个错误:issues.apache.org/jira/browse/HDFS-8914 和 issues.apache.org/jira/browse/HDFS-8913。希望能在文档中获得更好的内容
    【解决方案2】:

    NameNode- 也称为主节点。 Namenode 存储元数据,即块的数量、它们的位置、副本和其他详细信息。此元数据可在主设备的内存中使用,以便更快地检索数据。 NameNode 维护和管理从节点,并为它们分配任务。它应该部署在可靠的硬件上,因为它是 HDFS 的核心。 Namenode 使用以下两个文件保存其命名空间:

    FsImage:FsImage 是一个“图像文件”。它包含整个文件系统命名空间,并作为文件存储在名称节点的本地文件系统中。

    EditLogs:它包含最近对文件系统所做的关于最近 FsImage 的所有修改。

    Checkpoint node- Checkpoint 节点是周期性创建命名空间检查点的节点。 Hadoop 中的检查点节点首先从活动的 Namenode 下载 fsimage 和编辑。然后它在本地合并它们(FsImage 和编辑),最后将新图像上传回活动的 NameNode。检查点节点将最新的检查点存储在一个目录中。它的结构与 Namenode 的目录相同。它允许检查点图像可供名称节点读取。

    备份节点-备份节点提供与检查点节点相同的检查点功能。在 Hadoop 中,备份节点在内存中保留文件系统命名空间的最新副本,该副本始终与活动 NameNode 状态同步。备份节点不需要从活动 NameNode 下载 fsimage 和编辑文件来创建检查点,这对于检查点节点或辅助 Namenode 是必需的,因为它已经具有命名空间状态的最新状态在记忆中。备份节点检查点过程效率更高,因为它只需将命名空间保存到本地 fsimage 文件并重置编辑。 NameNode 一次支持一个备份节点。如果正在使用备份节点,则不得注册任何检查点节点。

    【讨论】:

      猜你喜欢
      • 2013-11-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-04-05
      相关资源
      最近更新 更多