【Hadoop】40-维护

1、日常管理过程

1.1、元数据备份

如果namenode的永久性元数据丢失或损坏，则整个文件系统无法使用。因此，元数据备份非常关键。可以在系统中分别保存若于份不同时间的备份（例如，1小时前、1天前、1周前或1个月前），以保护元数据。方法一是直接保存这些元数据文件的复本；方法二是整合到namenode上正在使用的文件中。
最直接的元数据备份方法是使用dfsadmin命令下载namenode最新的fsimage文件的复本：

％hdfs dfsadmin -fetchlmage fsimage.backup

可以写一个脚本从准备存储fsimage存档文件的异地站点运行该命令。该脚本还需测试复本的完整性。测试方法很简单，只要启动一个本地namenode守护进程，查看它是否能够将fsimage和“文件载人内存（例如，通过扫描namenode日志以获得操作成功信息）。

1.2、数据备份

尽管HDFS已经充分考虑了如何可靠地存储数据，但是正如任何存储系统一样，仍旧无法避免数据丢失。因此，备份机制就很关键。Hadoop中存储着海量数据，判断哪些数据需要备份以及在哪里备份就极具挑战性。关键在于为数据划分不同优先级。那些无法重新生成的数据的优先级最高，这些数据对业务非常关键。同理，可再生数据和一次性数据商业价值有限，所以优先级最低，无需备份。

不要误以为HDFS的复本技术足以胜任数据备份任务。HDFS的程序纰漏、硬件故障都可能导致复本丢失。尽管Hadoop的设计方案可确保硬件故障极不可能导致数据丢失，但是这种可能性无法完全排除，特别是软件bug和人工误操作情况在所难兔。
再比较HDFS的备份技术和RAIDORAID可以确保在某一个RAID盘片发生故障时数据不受损坏。但是，如果发生RAID控制器故障、软件纰漏（可能重写部分数据）或整个磁盘阵列故障，数据肯定会丢失。
通常情况下，HDFS的用户目录还会附加若干策略，例如目录容量限制和夜间备份等。用户需要熟悉相关策略，才可以预料执行结果。
是一个理想的备份工具，其并行的文件复制功能可以将备份文件存储到其他HDFS集群（最好软件版本不同，以防Hadoop软件纰漏而丢失数据）或其他Hadoop文件系统（例如S3)。此外，还可以用3.4节提到的方法将数据从HDFS导出到完全不同的存储系统中。
Hadoop自带的OflIine lmage Viewer和OfiIine Edits Viewer工具能检测fsimage和edits文件的一致性。这两种工具均支持旧版文件。因此，用户可以用这些工具来诊断Hadoop的早期发布版本中存在的问题。可以键人hdfsoiv和hdfsoev来调用这些工具。

HDFS允许管理者和用户对文件系统进行快照。快照是对文件系统子树在给定时刻的一个只读复本。由于并不真正复制数据，因此快照非常高效，它们简单地记录每个文件的元数据和块列表，这对于重构快照时刻的文件系统内容已经足够了。
快照不是数据备份的替代品，但是对于恢复用户误删文件在特定时间点的数据而言，它们是一个有用的工具。可以制定一个周期性快照的策略，根据年份将快照保存一段特定的时间。例如，可以对前一天的数据进行每小时一次的快照，对前一个月的数据进行每天一次的快照。

1.3、文件系统检查（fsck）

建议定期地在整个文件系统上运行HDFS的凶文件系统检查）工具（例如，每天执行），主动查找丢失的或损坏的块。参见11.1.4节对文件系统检查的详细介绍。

1.4、文件系统均衡器

定期运行均衡器工具（参见11.1.4节对均衡器的详细介绍），保持文件系统的各个datanode比较均衡。

2、委任和解除节点

Hadoop集群的管理员经常需要向集群中添加节点，或从集群中移除节点。例如，为了扩大存储容量，需要委任节点。相反的，如果想要缩小集群规模，则需解除节点。如果某些节点表现反常，例如故障率过高或性能过于低下，则需要解除该节点。
通常情况下，节点同时运行datanode和节点管理器，因而两者一般同时被委任或解除。

2.1、委任新节点

委任一个新节点非常简单。首先，配置hdfs-site.xml文件，指向namenode;其次，配置yarn-site.xml文件，指向资源管理器；最后，启动datanode和资源管理器守护进程。然而，预先指定一些经过审核的节点以从中挑选新节点仍不失为一种好的方法。
随便允许一台机器以datanode身份连接到namenode是不安全的，因为该机器很可能会访问未授权的数据。此外，这种机器并非真正的datanode，不在集群的控制之下，随时可能停止，导致潜在的数据丢失。（想象一下，如果有多台这类机器连接到集群，而且某一个块的全部复本恰巧只存储在这类机器上，安全性如何？）由于错误配置的可能性，即使这些机器都在本机构的防火墙之内，这种做法的风险也很高。因此所有工作集群上的datanode（以及节点管理器）都应该被明确管理。
允许连接到namenode的所有datanode放在一个文件中，文件名称由dfs.hosts属性指定。该文件放在的本地文件系统中，每行对应一个datanode的网络地址（由datanode报告一一可以通过namenode的网页查看）。如果需要为一个datanode指定多个网络地址，可将多个网络地址放在一行，由空格隔开。类似的，可能连接到资源管理器的各个节点管理器也在同一个文件中指定（该文件的名称由yarn.resourcemanager.nodes.include-path属性指定。在通常情况下，由于集群中的节点同时运行datanode和节点管理器守护进程，dfs.hosts和yarn.resourcemanager.nodes.include-path会同时指向一个文件，即include文件。

dfs.hosts属性和include-path属性指定的（一个或多个）文件不同于“文件。前者供namenode和资源管理器使用，用于决定可以连接哪些工作节点。Hadoop控制脚本使用slaves文件执行面向整个集群范围的操作，例如重启集群等。Hadoop守护进程从不使用slaves文件。
向集群添加新节点的步骤如下。

1. 将新节点的网络地址添加到include文件中。
2. 运行以下指令，将审核过的一系列datanode集合更新至namenode信息：％hdfs dfsadmin -refreshNodes
3. 运行以下指令，将审核过的一系列节点管理器信息更新至资源管理器：％yarn rmadmin -refreshNodes
4. 以新节点更新slaves文件。这样的话，Hadoop控制脚本会将新节点包括在未来操作之中。
5. 启动新的datanode和节点管理器。
6. 检查新的和节点管理器是否都出现在网页界面中。

HDFS不会自动将块从旧的datanode移到新的datanode以平衡集群。用户需要自行运行均衡器，详情参考11.1.4节对均衡器的讨论。

2.2、解除旧节点

HDFS能够容忍datanode故障，但这并不意味着允许随意终止datanode。以三复本策略为例，如果同时关闭不同机架上的三个datanode，则数据丢失的概率会非常高。正确的方法是，用户将拟退出的若干datanode告知禮，Hadoop系统就可在这些妇停机之前将块复制倒其他datanode。
有了节点管理器的支持，Hadoop对故障的容忍度更高。如果关闭一个正在运行MapReduce任务的节点管理器，application master会检测到故障，并在其他节点上重新调度任务。

解除节点的过程由“砌壶文件控制。对于HDFS来说，文件由dfs.hosts.exclude属性设置；对于YARN来说，文件由yarn.resourcemanager.nodes.exclude-path属性设置。这些文件列出若干未被允许连接到集群的节点。通常，这两个属性指向同一个文件。
判断一个节点管理器能否连接到资源管理器非常简单。仅当节点管理器出现在include文件且不出现在exclude文件中时，才能够连接到资源管理器。注意，如果未指定include文件，或include文件为空，则意味着所有节点都包含在include文件中。
HDFS的规则稍有不同。如果一个datanode同时出现在include和exclude文件中，则该节点可以连接，但是很快会被解除委任。表11-3总结了datanode的不同组合方式。与节点管理器类似，如果未指定初砌文件或砌壶文件为空，都意味着包含所有节点。
 

表11-3．HDFS的include文件和exclude文件

节点是否出现在include文件中	节点是否出现在exclude文件中	解释
否	否	节点无法连接
否	是	节点无法连接
是	否	节点可连接
是	是	节点可连接，将被解除

从集群中移除节点的步骤如下。

1. 将待解除节点的网络地址添加到exclude文件中，不更新include文件。
2. 执行以下指令，使用一组新的审核过的来更新namenode设置：％hdfs dfsadmin -refreshNodes
3. 使用一组新的审核过的节点管理器来更新资源管理器设置：％yarn rmadmin -refreshNodes
4. 转到网页界面，查看待解除datanode的管理状态是否已经变为“正在解除”(Decommission ln Progress)，因为此时相关的datanode正在被解除过程之中。这些datanode会把它们的块复制到其他datanode中。
5. 当所有datanode的状态变为“解除完毕"(Decommissioned)时，表明所有块都已经复制完毕。关闭已经解除的节点。
6. 从include文件中移除这些节点，并运行以下命令：％hdfs dfsadmin -refreshN0des %yarn rmadmin -refreshNodes
7. 从slaves文件中移除节点。

2.3、升级

升级Hadoop集群需要细致的规划，特别是HDFS的升级。如果文件系统的布局的版本发生变化，升级操作会自动将文件系统数据和元数据迁移到兼容新版本的格式。与其他涉及数据迁移的过程相似，升级操作暗藏数据丢失的风险，因此需要确保数据和元数据都已经备份完毕。参见11.3.1节对日常管理过程的讨论。
规划过程最好包括在一个小型测试集群上的测试过程，以评估是否能够承担（可能的）数据丢失的损失。测试过程使用户更加熟悉升级过程、了解如何配置本集群和工具集，从而为在产品集群上进行升级工作消除技术障碍。此外，一个测试集群也有助于测试客户端的升级过程。用户可以阅读以下补充内容中对客户端兼容性的讨论。

兼容性
将Hadoop版本升级成另外一个版本时，需要仔细考虑需要升级步骤。同时还要考虑几个方面：API兼容性、数据兼容性和连接兼容性。
API兼容性重点考虑用户代码和发行的HadoopAPI之间的对比，例如JavaMapReduceAPI。主发行版本（例如从1.x.y到2.0.0）是允许破坏API兼容性的，因此，用户的程序要修改并重新编泽·次重点发行版本（例如从到1.0.x到1.1.0）和单点发行版本（例如从1.0.1到1.0.2）不应该破坏兼容性。
Hadoop针对API函数使用分类模式来表征其隐定性。按照先前的命名规则，API兼容性包括标记为lnterfacestability.Stable。公开发行的HadoopAPI中包含有部分函数，标记为InterfaceStability.Evolving或者InterfaceStability.Unstable(上述标注包含在org.apache.hadoop.classification软件包中），这意味允许它们分别在次重点发行版本和单点发行版本中破坏兼容性。
数据兼容性主要考虑持久数据和元数据的格式，例如在HDFS namenode中用于存储持久数据的格式·这些格式允许在主版本和次重点版本之间修改，但是这类修改对用户透明，因为系统升级时数据会自动迁移·系统升级路径有一些限制，这些限制包含在发行须知中。例如，在系统升级过程中可能需要通过某个中间发行版本依次升级，而非一步直接升级到最新版本。连接兼容性主要考虑通过利用RPC和HTTP这样的连接协议来实现客户端和服务器之间的互操作性。连接兼容性的規则是，客户端与服务器必须有相同的主版本号，但次版本号或单点发行版本号可以不同（例如，客户端2.0.2版可以和服务器2.0.1版或2.1.0版一起工作，但是与服务器3.0.0版不能一起工作）。
这条连接兼容性规贝刂和Hadoop早期版本中要求的不同。早期版本中，内部客户端（例如datane）必须和服务端一起加锁升级。目前这种客户端和服务端的版本可以不同的事实使得Hadoop2能够支持滚动升级。

如果文件系统的布局并未改变，升级集群就非常容易：在集群上安装新版本的Hadoop（客户端也同步安装），关闭旧的守护进程，升级配置文件，启动新的守护进程，令客户端使用新的库。整个过程是可逆的，换言之，也可以方便地还原到旧版本。
成功升级版本之后，还需要执行两个清理步骤。

1. 从集群中移除旧的安装和配置文件。
2. 在代码和配置文件中针对“被弃用”(deprecation)警告信息进行修复。

升级功能是Hadoop集群管理工具如Cloudera Manager和Apache Ambari的一个亮点。它们简化了升级过程，且使得滚动升级变得容易。节点以批量方式升级（或对于主节点，一次升级一个），这样客户端不会感受到服务中断。
HDFS的数据和元数据升级
如果采用前述方法来升级HDFS，且新旧HDFS的文件系统布局恰巧不同，则namenode无法正常工作，在其日志文件中产生如下信息：

最可靠的判定文件系统升级是否必要的方法是在一个测试集群做实验。
升级HDFS会保留前一版本的元数据和数据的复本，但这并不意味着需要两倍的存储开销，因为datanode使用硬链接保存指向同一块的两个应用（分别为当前版本和前一版本），从而能够在需要时方便地回滚到前一版本。需要强调的是，系统回滚到旧版本之后，原先的升级改动都将被取消。
用户可以保留前一个版本的文件系统，但无法回滚多个版本。为了执行HDFS数据和元数据上的另一次升级任务，需要删除前一版本，该过程被称为“定妥升级”(finalizing the upgrade)。一旦执行该操作，就无法再回滚到前一个版本。
一般来说，升级过程可以忽略中间版本。但在某些情况下还是需要先升级到中间版本，这种情况会在发布说明文件中明确指出。
仅当文件系统健康时，才可升级，因此有必要在升级之前调用为工具全面检查文件系统的状态（参见11.1.4节对工具的讨论）。此外，最好保留不的输出报告，该报告列举了所有文件和块信息；在升级之后，再次运行新建一份输出报告并比较两份报告的内容。

在升级之前最好清空临时文件，包括HDFS的MapReduce系统目录和本地的临时文件等。
综上所述，如果升级集群会导致文件系统的布局变化，则需要采用下述步骤进行升级。

1. 在执行升级任务之前，确保前一升级已经定妥。
2. 关闭YARN和MapReduce守护进程。
3. 关闭HDFS，并备份namenode目录。
4. 在集群和客户端安装新版本的Hadoop。
5. 使用-upgrade选项启动HDFS。
6. 等待，直到升级完成。
7. 检验HDFS是否运行正常。
8. 启动YARN和守护进程。
9. 回滚或定妥升级任务（可选的）。
    

运行升级任务时，最好移除PATH环境变量下的Hadoop脚本，这样的话，用户就不会混淆针对不同版本的脚本。通常可以为新的安装目录定义两个坏境变量。在后续指令中，我们定义了OLDHADOOP_HOME和NEWHADOOP-HOME两个环境变量。
启动升级为了执行升级，可运行以下命令（即前述的步骤5）：

％$NEW_HADOOP_HOME/bin/start-dfs.sh -upgrade

该命令的结果是让namenode升级元数据，将前一版本放在dfs.namenode.name.dir下的名为“的新目录中。类似地，datanode升级存储目录，保留原先的复本，将其存放在previous目录中。
等待，直到升级完成升级过程并非一蹴即就，可以用口查看升级进度，升级事件同时也出现在守护进程的日志文件中，步骤（6）：

％$NEW_HADOOP_HOME/bin/hdfs dfsadmin -upgradeProgress status

查验升级情况显示升级完毕。在本阶段中，用户可以检查文件系统的状态，例如使用fsck(一个基本的文件操作）检验文件和块，参见步骤（7）。检验系统状态时，最好让HDFS进人安全模式（所有数据只读），以防止其他用户修改数据。详见11.1.2节安全模式的有关内容。
回滚升级（可选的）如果新版本无法正确工作，可以回滚到前一版本，参见步骤（9），前提是尚未定妥更新。
回滚操作会将文件系统的状态转回到升级之前的状态，同期所做的任何改变都会丢失。换句话说，将回滚到文件系统的前一状态，而非将当前的文件系统降级到前一版本。
首先，关闭新的守护进程：

％NEW_HADOOP_HOME/bin/stop-dfs.sh

其次，使用-rollback选项启动旧版本的HDFS：

％$OLD_HADOOP_HOME/bin/start-dfs.sh -rollback

该命令会让namenode和datanode使用升级前的复本替换当前的存储目录。文件系统返回之前的状态。
定妥升级（可选）如果用户满意于新版本的HDFS，可以定妥升级，参见步骤（9），以移除升级前的存储目录。

一旦升级定妥，就再也无法回滚到前一版本。
在执行新的升级任务之前，必须执行这一步：

％$NEW_HADOOP_HOME/bin/hdfs dfsadmin -finalizeUpgrade
％$NEW_HADOOP_HOME/bin/hdfs dfsadmin -upgradeProgress status

There are no upgrades inprogress.
现在，HDFS已经完全升级到新版本了。