维护
日常管理过程
元数据备份
如果namenode的永久性元数据丢失或损坏，则整个文件系统无法使用。因此，元 数据备份非常关键。可以在系统中分别保存若干份不同时间的备份(例如，1小时 前、1天前、1周前或一个月前)，以保护元数据。方法一是直接保存这些元数据文 件的副本，方法二是整合到namenode上正在使用的文件中。
最直接的元数据备份方法是利用脚本文件定期将辅助namenode的 previous, checkpoint子目录打包，再放到其他站点。注意，该子目录放在 fs.checkpoint.dir属性定义的目录之中。此外，还需测试复本的一致性。测试 方法很简单，只要启动一个本地namenode守护进程，查看它是否能够将fsimage 和edits文件载入内存(例如，扫描namenode日志，查找相应的成功信息)。
数据备份
尽管HDFS已经充分考虑了如何可靠地存储数据，但是正如任何存储系统一样， 仍旧无法避免数据丢失。因此，备份机制就很关键。Hadoop中存储着海量数据， 判断哪些数据需要备份以及在哪里备份就极具挑战性。关键点在于为数据划分不同 优先级。最髙优先级是指那些无法重新产生的数据，这些数据对业务非常关键。同 理，能够重新产生的数据和一次性数据商业价值有限，所以优先级最低，无需备份。
通常情况下，HDFS的用户目录还会附加若干策略，例如目录容量限制和夜间备份 等。用户需要熟悉相关策略，才可预料执行结果。
distcp是一个理想的备份工具，其并行复制文件的功能可以将备份文件存储到其他 HDFS集群(最好版本不同，以防软件纰漏而丢失数据)或其他Hadoop文件系统(例 如S3或KFS)。
fsck工具
建议定期地在整个文件系统上运行HDFS的fsck(文件系统检查)工具(例如，毎天执行)，主动查找丢失的或损坏的块。
文件系统均衡器
定期运行均衡器工具，保持文件系统的各个 datanode比较均衡。
委任和解除节点
Hadoop集群的管理员需要经常向集群中添加节点，或从集群中移除节点。例如， 为了扩大存储容量，需要委任节点。相反的，如果想要缩小集群规模，则需解除节 点。如果某些节点表现反常，例如故障率过髙或性能过于低下，则需要解除该节 点。
委任新节点
委任一个新节点非常简单。首先，配置hdfs-site.xml文件，指向namenode,其 次，配置mapred-site.xml文件，指向jobtracker;最后，启动datanode和jobtracker守护进程。此外，最好指定一些经过审核的节点，新节点包含在其中。
随便允许一台机器以datanode身份连接到namenode是非常危险的，因为该机器很可能会访问未授权的数据。此外，这种机器并非真正的datanode，不在集群的控制之下，随时可能停止，从而导致潜在的数据丢失。的想象一下，如果有多台这种机器连接到集群，而且某一个块恰巧只存储在这种机器上，安全性如何？即使这些机器都在本机构的防火墙之内，这种做法的风险也很髙。如果配置错误，datanode(W及tasktracker)可能会被所有集群管理。
被允许连接到namenode的所有datanode放在一个文件中，文件名称由dfs.hosts属性指定。该文件放在namenode的本地文件系统中，每行对应一个datanode的网络地址（由datanode报告 可以通过namenode的网页查看）。如果需要为一个datanode指定多个网络地址，可将多个网络地址放在一行，由空格隔开。
类似的，可能连接到jobtracker的各个tasktracker也在同一个文件中指定(该文件的名称由mapred.hosts属性指定。在通常情况下，由于集群中的节点同时运行datanode 和 tasktracker 守护进程，dfs.hosts 和 mapred.hosts 会同时指向一个文件，即include文件。
解除旧节点
HDFS能够容忍datanode故障，但这并不意味着允许随意终止datanode。以三复本 策略为例，如果同时关闭不同机架上的三个datanode，丢失数据的概率会非常髙。 正确的方法是：用户将拟退出的若干datanode告知namenode,方可在这些 datanode停机之前将块复制到其他datanode。
Hadoop的tasktracker也可容忍故障的发生。如果关闭一个正在运行任务的 tasktracker,jobtracker会意识到发生故障，并在其他tasktracker上重新调度任务。
若要解除一个节点，则该节点需要出现在exclude文件。对于HDFS来说，文件名 称由dfs.hosts.exclude属性控制；对于MapReduce来说，文件名称由 mapred.hosts.exclude属性控制。这些文件列出若干未被允许连接到集群的节 点。通常情况下，这两个属性指向同一个文件。
判断一个tasktracker能否连接到jobtracker非常简单。仅当tasktracker出现在 include文件且不出现在exclude文件中时，才能够连接到jobtracker。注意：如果 未指定include文件，或include文件为空，则意味着所有节点均在include文件 中。
HDFS的规则稍有不同。如果一个datanode同时出现在include和exclude文件中， 则该节点可以连接，但是很快会被解除委任。表10-4总结了 datanode的不同组合 方式。与tasktracker类似，如果未指include文件或include文件为空，都意味着 包含所有节点。
表10-4. HDFS的include文件和exclude文件
| 节点是否出现在include文件中 | 节点是否出现在exclude文件中 | 解释 |
|---|---|---|
| 否 | 否 | 节点无法连接 |
| 否 | 是 | 节点无法连接 |
| 是 | 否 | 节点可连接 |
| 是 | 是 | 节点可连接，将被解除 |
从集群中移除节点的步骤如下。
1.将待解除节点的网络地址添加到exclude文件中。不更新include文件。
2.重启MapReduce集群，以终止在待解除节点上运行的tasktracker。
3.执行以下指令，使用一系列新的审核过的datanode来更新的namenode设置：
% hadoop dfsadmin -refreshNodes
4.转到网页界面，査看待解除datanode的管理状态是否已经变为 "Decommission In Progress"。将这些 datanode 的块复制到其他 datanode 中。
5.当所有datanode的状态变为“Decommissioned”时，表明所有块都已经复制 完毕。关闭已经解除的节点。
6.从include文件中移除这些节点，并运行以下命令：
% hadoop dfsadmin -refreshNodes
7.从slaves文件中移除节点。
升级
升级HDFS和MapReduce集群需要细致的规划，特别是HDFS的升级。如果文件 系统的布局的版本发生变化，升级操作会自动将文件系统数据和元数据迁移到兼容 新版本的格式。与其他涉及数据迁移的过程相似，升级操作暗藏数据丢失的风险， 因此需要确保数据和元数据都已经备份完毕。
规划过程最好包括在一个小型测试集群上的测试过程，以评估是否能够承担(可能 的)数据丢失的损失。测试过程使用户更加熟悉升级过程、了解如何配置本集群和 工具集，从而为升级工作集群消除技术障碍。此外，一个测试集群也有助于测试客 户端的升级过程。
| 版本兼容性 在1.0版本之前，Hadoop组件的兼容性非常差，仅当同属一个版本时，组件才 可彼此兼容。这意味着整个系统——从守护进程到客户端——必须同时升级，导 致整个集群必须停机一段时间。 Hadoopl.O版本显著提髙了组件的兼容性。例如，旧版本的客户端也可以调用新 版本的服务器(二者的主发布号相同)，后续发布还将支持滚动升级法，即允许集 群的守护进程分阶段升级，因此在升级期间集群仍可有效工作。 |
如果文件系统的布局并未改变，升级集群就非常容易：在集群上安装新的HDFS 和MapReduce(客户端也同步安装），关闭旧的守护进程，升级配置文件，启动新的 守护进程，令客户端使用新的库。整个过程完全可逆，换言之，也可以方便地还原 到旧版本。
每当成功升级版本之后，还需要执行几个清除步骤。
HDFS的数据和元数据升级
如果采用前述方法来升级HDFS，且新旧HDFS的文件系统布局恰巧不同，则namenode无法正常工作，会在其日志文件中产生如下信息。
File system image contains an old layout version -16.An upgrade to version -18 is required.Please restart NameNode with -upgrade option.
最可靠的判定文件系统升级是否必要性的方法是在一个测试集群做实验。
升级HDFS还会保留前一版本的元数据和数据的复本，但是这并不意味着升级需 要两倍存储开销，因为datanode使用硬链接保存指向同一块的两个应用(分别为当 前版本和前一版本）。这样的话，就能够方便地回滚到前一版本。需要强调的是， 系统回滚到旧版本之后，原先的升级改动都将被取消。
用户可以保留前一个版本的文件系统，但无法回滚多个版本。为了执行HDFS数 据和元数据上的另一升级任务，需要删除前一版本，这个过程被称为“定妥升级” (finalizingtheupgrade)。一且执行这个操作，就无法再回滚到前一个版本了。一般来说，升级过程可以忽略中间版本(例如，从0.18.3升级到0.20.0不需要先升 级到0.19.x)。但在某些情况下还是需要先升级到中间版本，这一般会在发布说明 中清楚地指出。
仅当文件系统健康时，才可升级，因此有必要在升级之前调用方&工具全面检查 文件系统的状态。此外，最好保留月&的输出 报告，该报告列举了所有文件和块信息；在升级之后，再次运行力&来新建一份 输出报告，并比较两份报告的内容。
在升级之前最好清空临时文件，包括HDFS的MapReduce系统目录和本地临时文 件等。
综上所述，如果升级集群会导致文件系统的布局变化，则需要采用下述步骤进行 升级。
1.在执行升级任务之前，确保前一升级已经定妥。
2.关闭MapReduce,终止在tasktracker上运行的任何孤儿任务。
3.关闭HDFS,并备份namenode目录。
4.在集群和客户端安装新版本的Hadoop HDFS和MapReduce。
5.使用-upgrade选项启动HDFS。
6.等待，直到升级完成。
7.检验HDFS是否运行正常。
8.启动MapReduce。
9.回滚或定妥升级任务(可选的)。
运行升级任务时，最好移除PATH环境变量下的Hadoop脚本，这样的话，用户就 不会混淆针对不同版本的脚本。通常可以为新的安装目录定义两个环境变量。在后 续指令中，我们定义了 OLD_HADOOP_INSTALL和NEW_HADOOP_INSTALL两个环境 变量。
启动升级为了执行升级，请运行以下命令(即前述的步骤5):
% $NEW_HADOOP_INSTALL/bin/start-dfs.sh -upgrade
该命令的结果是让namenode升级元数据，将前一版本放在名为previous的新目 录中：
${dfs.name.din}/cunnent/VERSION/edits/fsimage/fstime/previous/VERSION/edits/fsimage/fstime
类似地，datanode升级存储目录，保留原先的副本，存放在previous目录中。
等待，直到升级完成升级过程并非一蹴即就，可以用dfsadmin查看升级进度(升级事件同时也出现在守护进程的日志文件中，步骤6):
% $NEW_HADOOP_INSTALL/bin/hadoop dfsadmin -upgnadeProgress status Upgrade for version -18 has been completed.Upgrade is not finalized.
査验升级情况显示升级完毕。在本阶段中，用户可以检查文件系统的状态，例如使用fsck(一个基本的文件操作)检验文件和块(步骤7)。检验系统状态时，最好让 HDFS进入安全模式(所有数据只读），以防止其他用户修改数据。
回滚升级(可选的）如果新版本无法正确工作，可以回滚到前一版本中去(步骤 9),前提是尚未定妥更新。
定妥升级(可选）如果用户满意于新版本的只0?5,可以定妥升级(步骤9),以移除 升级前的存储目录。
一旦升级定妥，就无法回滚到前一版本。
在执行新的升级任务之前，必须执行这一步：
% $NEW_HADOOP_INSTALL/bin/hadoop dfsadmin -finaXizeUpgrade % $NEW_HADOOP_INSTALL/bin/hadoop dfsadmin -upgradeProgress status There are no upgrades in progress.
现在，HDFS已经完全升级到新版本了。
