HDFS 用户手册

HDFS Users Guide

Purpose

本文档是用户使用HDFS的启蒙文档,不管是作为Hadoop集群的一部分,还是独立运行的通用分布式文件系统。虽然HDFS设计的目的是在很多环境工作就好,了解HDFS知识有助于进行配置升级和诊断。

Overview

HDFS是Hadoop应用的主要分布式存储。HDFS集群包含NameNode和DataNodes,NameNode管理文件系统元数据, DataNodes存储实际的数据。HDFS Architecture Guide 详细的阐述了HDFS。本用户手册主要介绍用户和管理员与HDFS集群的交互。HDFS architecture diagram 描述了NameNode,DataNodes,clients 的基本交互。Clients联系NameNode获取文件元数据or文件修改,实际的I/O直接联系DataNodes。

如下是一些用户感兴趣的突出特征:

  • Hadoop,包括HDFS,是适合于在普通硬件运行的分布式存储和分布式处理程序。它是容错的、可扩展的,并且极易扩展。MapReduce是Hadoop不可获取的一部分,以简单和适用于大量分布式应用而闻名。

  • HDFS高度可配置,默认配置适用于大多数安装。大多情况下,只需为超大的集群调整配置。

  • Hadoop以Java语言开发,被所有主流平台支持。

  • Hadoop支持以类shell的命令行直接与HDFS交互。

  • NameNode 和 Datanodes 都内置了web servers,可以很方便的查看集群当前状态。

  • HDFS定期实现新功能和改进。如下是HDFS有用的一些特性:

    • 文件权限和身份验证

    • 机架感知Rack awareness:在任务调度和分配任务的时候考虑节点的物理位置

    • 安全模式Safemode:维护时的管理员模式

    • fsck:分析文件系统健康状态的功能,可以发现丢失的文件or数据块

    • fetchdt:获取DelegationToken并存储在本地文件系统的文件上

    • Balancer:当数据在DataNodes见分配不均衡时,平衡集群的工具

    • Upgrade and rollback:在软件升级后,因为一些难以预测的问题,可以回滚至HDFS升级之前的状态

    • Secondary NameNode: 定期检查namespace的checkpoints,并帮助NameNode保持特定限制的、包含HDFS修改日志的文件大小。

    • Checkpoint node: 定期检查namespace的checkpoints,并帮助最小化NameNode存储HDFS变更的日志文件的尺寸。替换先前Secondary NameNode填充的role,虽然还没有经过严格的生产检验。只要没有 Backup nodes 注册到系统,NameNode 就可以允许同时存在多个Checkpoint nodes 。

    • Backup node:Checkpoint node的扩展。除了checkpointing ,它还接受来自NameNode的流并维护它自己的namespace在内存中的副本,该副本总是同步active NameNode命名空间的状态。一次只能向NameNode注册一个备份节点。

Prerequisites

如下文档描述了如何安装和设置一个 Hadoop 集群:

  • Single Node Setup for first-time users.
  • Cluster Setup for large, distributed clusters.

本文如下部分假设用户有能力在至少在一个DataNode上设置并运行一个HDFS实例。为了本文,NameNode 和DataNode 运行在同一个物理机上。

Web Interface

NameNode 和 DataNode 都内置web server 来提供集群状态的基础信息展示。默认配置,NameNode web接口 http://namenode-name:9870/。它列出了集群的DataNodes和集群的基础统计信息。 该web接口还可以用于浏览文件系统(点击 “Browse the file system”)。

Shell Commands

Hadoop包含类shell的命令可以与HDFS以及Hadoop支持的其他文件系统直接交互。命令bin/hdfs dfs -help 列出了Hadoop shell 支持的命令。命令bin/hdfs dfs -help command-name显示某命令更详细的信息。这些命令支持大多数正常的文件系统操作,如复制文件、更改文件权限等。它还支持一些特定于HDFS的操作,如更改文件的副本。更多信息参考File System Shell Guide。

  • DFSAdmin Command
    bin/hdfs dfsadmin命令支持一些HDFS管理相关的操作。bin/hdfs dfsadmin -help命令列出了所有当前支持的命令。比如:
    • -report:报告HDFS的基本统计数据。NameNode首页上也提供了一些此类信息。

    • -safemode:不常用,管理员可以手动进入、离开安全模式。

    • -finalizeUpgrade:删除上次升级时集群的备份。

    • -refreshNodes:更新namenode,使用被允许连接到namenode的datanodes集合。默认,Namenodes重新读取文件内dfs.hostsdfs.hosts.exclude定义的datanode主机名。定义在dfs.hosts的主机是属于集群的datanodes。如果dfs.hosts内有条目,只有在其内的主机被允许注册到namenode。dfs.hosts.exclude 内的条目是需要被停用的datanodes。或者,如果dfs.namenode.hosts.provider.classname被设置为org.apache.hadoop.hdfs.server.blockmanagement.CombinedHostFileManager,所有include和exclude的主机都在JSON文件内被dfs.hosts定义。当所有副本被复制到其他 datanodes,datanode完成停用。停用的nodes不会自动关闭,也不会被写入新副本数据。

    • -printTopology:打印集群拓扑。以树状显示racks,和在NameNode上看到的、racks上的datanodes。

命令的用法参考 dfsadmin。

Secondary NameNode

NameNode将文件系统的变更已日志的方式存储到原生文件系统文件edits上。当NameNode启动时,它从image file fsimage读取HDFS状态,然后从edits log文件附加edits。然后,它写入新的HDFS状态到fsimage,并以空edits文件正常启动。既然NameNode仅在启动时合并fsimage和edits文件,那么繁忙集群的edits log文件可能会逐渐变的很大。大edits文件的另外一个影响,就是下次NameNode启动时需要更长时间。

Secondary NameNode定期合并fsimage和edits log文件,并保持edits log在限制尺寸内。它通常与主NameNode在不同服务器上运行,因为它的内存需求跟主NameNode一样。

Secondary NameNode 上检查点进程的启动由两个参数控制。

  • dfs.namenode.checkpoint.period,默认设置为1 hour,指定连续两个checkpoints之间的最大延迟

  • dfs.namenode.checkpoint.txns,默认设置为100万,定义强制紧急checkpoint的uncheckpointed事务的数量,即便checkpoint周期尚未到达。

Secondary NameNode在目录内存储最后的checkpoint,目录结构和主NameNode目录相同。 所以,如果需要,已经checkpointed 的 image 总是可以被主NameNode读取。

命令使用请参见 secondarynamenode。

Checkpoint Node

NameNode使用两个文件持久化命名空间:命名空间最后一次checkpoint和edits的fsimage,自checkpoint后的命名空间的journal(log)。当NameNode启动时,合并fsimage和edits journal来提供一个最新的文件系统元数据视图。然后 NameNode 以新HDFS状态覆盖fsimage,并开始新的edits journal。

Checkpoint node定期创建命名空间的checkpoints。它从active NameNode下载fsimage和edits,在本地合并,然后回传新image给active NameNode。Checkpoint 通常和NameNode运行于不同的服务器,因为它的内存需求和NameNode相同。Checkpoint node在配置文件指定的node上以bin/hdfs namenode -checkpoint启动。

Checkpoint (or Backup) node 的位置和相随的 web interface 通过dfs.namenode.backup.addressdfs.namenode.backup.http-address 变量指定。

Checkpoint node上checkpoint进程的启动由两个配置参数控制:

  • dfs.namenode.checkpoint.period,默认设置为1 hour,指定连续两个checkpoints之间的最大延迟
  • dfs.namenode.checkpoint.txns,默认设置为100万,定义强制紧急checkpoint的uncheckpointed事务的数量,即便checkpoint周期尚未到达。

Checkpoint node在目录内存储最后的checkpoint,目录结构和主NameNode目录相同。这允许checkpointed image始终可被NameNode读取。参见导入checkpoint。

多checkpoint nodes可以在集群配置文件指定。

命令使用,参见namenode。

Backup Node

Backup node提供与Checkpoint node一样的checkpointing功能,还维护着一套及时同步active NameNode状态的最近的文件系统命名空间的内存中的副本。除了接受来自NameNode的文件系统的日志流,并持久化到硬盘,Backup node还将这些edits应用到其在内存中的命名空间副本,从而创建命名空间的备份。

Backup node不像Checkpoint node 或 Secondary NameNode那样需要从active NameNode下载fsimage 和 edits 文件,因为它已经在内存内保存了一份实时更新的命名空间状态。Backup node的checkpoint进程效率更高,因为它只需要保存命名空间到本地fsimage文件,然后重置edits。

因为Backup node在内存维护着命名空间的副本,那么它的内存需求也就与NameNode相同了。

NameNode同时只支持一个Backup node。如果使用了Backup node,那么Checkpoint nodes就注册不了了。未来会支持多Backup nodes同时使用。

Backup node 配置方式与 Checkpoint node 相同。以bin/hdfs namenode -backup启动。

Backup (or Checkpoint) node 的位置和相随的 web interface 通过dfs.namenode.backup.address 和 dfs.namenode.backup.http-address 变量指定。

Backup node的使用提供了不依赖固化存储运行NameNode的选项,授权所有的仓库将命名空间的状态持久化到Backup node。为此,需要以 -importCheckpoint 参数启动NameNode,同时指定NameNode配置dfs.namenode.edits.dir没有持久化存储目录。

有关创建Backup node和Checkpoint node动机的讨论,参见HADOOP-4539。
命令使用,参见 namenode。

Import Checkpoint

如果image的其他副本和edits文件全部丢失,最近的checkpoint可以被导入到NameNode。操作如下:

  • 创建一个在dfs.namenode.name.dir变量中指定的空目录

  • 在配置文件变量dfs.namenode.checkpoint.dir指定checkpoint 目录的位置

  • -importCheckpoint 参数启动NameNode

NameNode将从dfs.namenode.checkpoint.dir目录上传checkpoint,然后保存到dfs.namenode.name.dir目录。如果dfs.namenode.name.dir目录已经存在合法Image,则失败。NameNode验证dfs.namenode.checkpoint.dir下image的一致性,但是不会以任何方式修改。

命令使用,参见 namenode.

Balancer

HDFS数据跨DataNode的遍布可能是不一致的。一个常见原因是向现有集群添加新DataNodes。当放置新数据块时,(文件作为一系列块存储),NameNode在选择哪些DataNodes接受这些数据块前会考虑很多因素。比如:

  • 将块的副本之一放在写入该块的同一台node上

  • 需要将块的副本放置与不同机架上,这样即使整个机架故障也不影响集群

  • 副本之一通常放置于写文件的node的同一机架上,这样可以减少跨机架的网络I/O

  • 将HDFS数据均匀的分布于集群的DataNodes上

基于多种因素,数据可能不会均衡的分布于DataNodes上。HDFS提供了一个工具给管理员用于分析块的散步情况和重新在DataNode间平衡数据。Balancer的主要管理员手册参见HADOOP-1652.

命令行使用,参见balancer.

Rack Awareness

HDFS集群可以识别nodes所在racks的拓扑结构。为了优化数据容量和使用率,配置拓扑是非常重要的。详细信息请参见 rack awareness 。

Safemode

在启动时,NameNode从fsimage和edits log文件加载文件系统状态。然后,等待DataNodes报告它们的块,这样就不会过早的开始复制块虽然集群内已经存在足够的副本。在这期间,NameNode保持在Safemode。NameNode的Safemode基本上就是HDFS集群的只读模式,不允许对文件系统和块进行任何修改。通常,在DataNodes报告大多数文件系统的块可用后,NameNode自动离开Safemode。如果需要,HDFS可以使用bin/hdfs dfsadmin -safemode命令明确指定Safemode。NameNode web接口会显示Safemode是on还是off。更多细节描述和配置维护在setSafeMode()的JavaDoc内。

fsck

HDFS支持fsck命令来检查各种不一致性。它被设计用户报告各种文件的问题,比如,文件缺少块或正在复制块。与原生文件系统的传统fsck功能不同,该命令不会修复检测到的错误。通常,NameNode会自动纠正大多数可恢复的故障。默认fsck忽略打开的文件,但是提供了一个选项可以在报告期间选择所有文件。HDFS fsck 命令不是Hadoop shell命令。可以通过bin/hdfs fsck运行。
命令的使用,参见 fsck。fsck可以在整个文件系统或者文件子集上运行。

fetchdt

HDFS支持fetchdt命令获取Delegation Token,并存储到本地文件系统的文件。这个token可以用于从非安全客户端访问安全服务器 (比如 NameNode)。功能使用RPC or HTTPS (over Kerberos)获取token,因此在运行前需要存在kerberos tickets (运行 kinit 获取 tickets)。 HDFS fetchdt 命令不是Hadoop shell命令。它可以通过 bin/hdfs fetchdt DTfile命令运行。获得token后,你可以无需Kerberos tickets运行HDFS command, 通过将HADOOP_TOKEN_FILE_LOCATION环境变量指向授权token文件。
命令使用,参见fetchdt 。

Recovery Mode

通常,你会配置多个元数据存储位置。然后,如果一个存储位置损坏了,你可以从其他位置读取元数据。

但是,如果唯一的可用存储位置损坏了怎么办?这种情况下,有一种特殊的NameNode启动模式 Recovery mode ,可以允许你恢复大多数数据。

你可以启动NameNode的recovery mode,如下:namenode -recover

当位于recovery mode,NameNode会在命令行交互的提示可以采用哪些措施恢复数据。

如果你不需要提示,可以使用 -force 选项。该选项将强制recovery mode选择第一选项。通常,这是最合理的选项。

因为Recovery mode可能会导致丢失数据,你应该在使用前备份 edit log 和 fsimage 。

Upgrade and Rollback

当Hadoop在现有集群上升级时,和其他软件升级一样,可能会存在一些以前没发现的bug或者不兼容的变更,影响已经存在的应用。在任何正式HDFS安装中,都不可以丢失数据,更不用说从头重启HDFS。HDFS允许管理员返回到Hadoop的早期版本,并将集群回滚到升级之前的状态。HDFS升级在Hadoop Upgrade Wiki 有更详细的描述。HDFS一次可以有一个这样的备份。升级前,管理员需要删除已有备份,使用命令bin/hadoop dfsadmin -finalizeUpgrade。下面描述主要升级过程:

  • 升级Hadoop前,确认是否已经存在备份

  • 停止集群,分发新版本

  • -upgrade参数运行新版本 (sbin/start-dfs.sh -upgrade)

  • 大多数时候,集群工作的很好。一旦新HDFS被认为运行良好 (可能在运行几天后),完成升级。注意,在集群完成之前,删除升级前存在的文件不会释放DataNodes上的真实磁盘空间。

  • 如果需要回滚到旧版本,

    • 停止集群,分发旧版本Hadoop

    • 在namenode运行rollback命令(bin/hdfs namenode -rollback)

    • 以rollback选项启动集群(sbin/start-dfs.sh -rollback)

当升级到新版本HDFS,有必要重命名或删除新版本HDFS的保留路径。如果NameNode在升级中遇到保留路径,会打印类似如下的报错:

/.reserved is a reserved path and .snapshot is a reserved path component in this version of HDFS. Please rollback and delete or rename this path, or upgrade with the -renameReserved [key-value pairs] option to automatically rename these paths during upgrade.

指定-upgrade -renameReserved [optional key-value pairs]参数会导致NameNode在启动时自动的重命名保留路径 。比如,重命名所有.snapshot路径为 .my-snapshot and 重命名.reserved路径为 .my-reserved,一个用户将指定 -upgrade -renameReserved .snapshot=.my-snapshot,.reserved=.my-reserved

如果-renameReserved没有指定键-值对,NameNode会给保留路径添加后缀 :.UPGRADE_RENAMED,比如:snapshot.-51.UPGRADE_RENAMED

重命名过程有些注意事项。如果可以,建议在升级前,首先hdfs dfsadmin -saveNamespace。这是因为,如果编辑日志操作引用自动重命名的文件的目标,可能会导致数据不一致。

DataNode Hot Swap Drive

Datanode支持热插拔。用户可以添加、替换HDFS数据卷而不需要关闭DataNode。如下主要描述了典型的热插拔过程:

  • 如果有新存储目录,用户应该格式化并合适的挂载它们

  • 用户升级DataNode配置dfs.datanode.data.dir来反映将被使用的数据卷目录

  • 用户运行dfsadmin -reconfig datanode HOST:PORT start来启动重配置进程。用户可以使用dfsadmin -reconfig datanode HOST:PORT status来查询重配置任务的运行状态。

  • 一旦重新配置完成,用户就可以安全的卸载数据卷目录并物理的移除磁盘

File Permissions and Security

文件权限被设计成与其他熟悉的平台(比如Linux)类似。目前,安全性仅限于简单的文件权限。启动NameNode的用户被视为HDFS的superuser。HDFS的未来版本将支持网络认证协议,比如Kerberos,来提供用户认证和数据传输加密。更多的细节在 Permissions Guide 有所讨论。

Scalability

Hadoop目前运行在有数千节点的集群上。 PoweredBy Wiki 页面列出了在大型集群上部署Hadoop的组织。HDFS每个集群都有一个NameNode。目前NameNode上总可用内存是主要扩展限制。在非常大的集群上,增加HDFS上文件的大小可以提升集群大小而不用增加NameNode的内存需求。默认设置不适合大集群。FAQ Wiki 列出了大型集群的配置优化建议。

Related Documentation

本用户手册是使用HDFS的一个好的开始。用户手册还在持续改进,还是有大量关于Hadoop和HDFS的文档。如下列表是进一步探索的起点:

  • Hadoop Site: Apache Hadoop 主页。
  • Hadoop Wiki: Hadoop Wiki。 不同于版本文档,作为Hadoop源码树的一部分,Hadoop Wiki 由Hadoop 社区定期编辑。
  • FAQ: FAQ Wiki。
  • Hadoop JavaDoc API.
  • Hadoop 用户邮件列表:user[at]hadoop.apache.org.
  • Explore hdfs-default.xml。它包含了可用配置变量的主要描述。
  • HDFS Commands Guide: HDFS 命令使用手册。

你可能感兴趣的:(HDFS 用户手册)