Hadoop 具有一致性和分区容错性,即它属于 CAP 定理的 CP 类别。
Hadoop 不可用,因为所有节点都依赖于名称节点。如果名称节点下降,集群就会下降。
但是考虑到 HDFS 集群有一个辅助名称节点这一事实,为什么我们不能将 hadoop 称为可用。如果名称节点关闭,则可以使用辅助名称节点进行写入。
使hadoop不可用的名称节点和辅助名称节点之间的主要区别是什么。
提前致谢。
Hadoop 具有一致性和分区容错性,即它属于 CAP 定理的 CP 类别。
Hadoop 不可用,因为所有节点都依赖于名称节点。如果名称节点下降,集群就会下降。
但是考虑到 HDFS 集群有一个辅助名称节点这一事实,为什么我们不能将 hadoop 称为可用。如果名称节点关闭,则可以使用辅助名称节点进行写入。
使hadoop不可用的名称节点和辅助名称节点之间的主要区别是什么。
提前致谢。
The namenode stores the HDFS filesystem information in a file named fsimage. Updates to the file system (add/remove blocks) are not updating the fsimage file, but instead are logged into a file, so the I/O is fast append only streaming as opposed to random file writes. When restaring, the namenode reads the fsimage and then applies all the changes from the log file to bring the filesystem state up to date in memory. This process takes time.
The secondarynamenode job is not to be a secondary to the name node, but only to periodically read the filesystem changes log and apply them into the fsimage file, thus bringing it up to date. This allows the namenode to start up faster next time.
Unfortunatley the secondarynamenode service is not a standby secondary namenode, despite its name. Specifically, it does not offer HA for the namenode. This is well illustrated here.
See Understanding NameNode Startup Operations in HDFS.
Note that more recent distributions (current Hadoop 2.6) introduces namenode High Availability using NFS (shared storage) and/or namenode High Availability using Quorum Journal Manager.
多年来情况发生了变化,尤其是Hadoop 2.x。现在 Namenode 具有高可用性,具有故障转移功能。
辅助 Namenode现在是可选的,备用 Namenode已用于故障转移过程。
备用 NameNode将与Active NameNode所做的所有文件系统更改保持同步。
HDFS高可用性可通过两个选项实现:NFS和 Quorum Journal Manager,但 Quorum Journal Manager 是首选选项。
查看 Apache文档
来自幻灯片 8:http ://www.slideshare.net/cloudera/hdfs-futures-world2012-widescreen
当主动节点执行任何命名空间修改时,它会将修改记录持久地记录到这些 JN 中的大多数。Standby 节点从 JN 中读取这些编辑并应用于它自己的名称空间。
在发生故障转移的情况下,备用节点将确保它已从 JounalNodes 读取所有编辑,然后再将其提升为活动状态。这可确保在发生故障转移之前完全同步命名空间状态。
查看相关 SE 问题中的故障转移过程:
关于您对 Hadoop CAP 理论的查询:
Name Node 是一个主节点,其中所有的元数据都会定期存储到 fsimage 和 editlog 文件中。但是,当名称节点关闭时,辅助节点将在线,但该节点只有对 fsimage 和 editlog 文件的读取权限,而没有对它们的写入权限。所有辅助节点操作都将存储到 temp 文件夹。当名称节点恢复在线时,此临时文件夹将被复制到名称节点,名称节点将更新 fsimage 和 editlog 文件。
即使在 HDFS 高可用性中,有两个 NameNode,而不是一个 NameNode 和一个 SecondaryNameNode,也不存在严格 CAP 意义上的可用性。它仅适用于 NameNode 组件,即使存在网络分区将客户端与两个 NameNode 分开,那么集群实际上也不可用。
当 NameNode 启动时,它会加载 FSImage 并重播 Edit Logs 以创建最新更新的命名空间。如果编辑日志文件的大小很大,此过程可能需要很长时间,从而增加启动时间。Secondary Name Node 的工作是定期检查编辑日志和重播以创建更新的 FSImage 并存储在持久存储中。名称节点启动时不需要重播编辑日志来创建更新的 FSImage,它使用辅助名称节点创建的 FSImage。
如果我以简单的方式解释它,假设名称节点作为男性(工作/生活)和辅助名称节点作为 ATM 机(存储/数据存储)
所以所有功能仅由 NN 或男性执行,但如果它出现故障/失败则 SNN 将无用它不起作用但稍后它可用于恢复您的数据或日志
namenode 是一个主节点,包含 fsimage 方面的元数据,还包含编辑日志。编辑日志包含最近在名称节点的命名空间中添加/删除的块信息。fsimage 文件包含永久存储中整个 hadoop 系统的元数据。每次我们需要在 fsimage 中进行永久更改时,我们都需要重新启动 namenode,以便在 namenode 上写入编辑日志信息,但这需要花费很多时间。
辅助名称节点用于使 fsimage 保持最新。辅助名称节点将访问编辑日志并永久更改 fsimage,以便下次名称节点可以更快地启动。
基本上,辅助 namenode 是 namenode 的助手,并为 namenode 执行管理功能。