关于hadoop:一篇文章彻底理解-HDFS-的安全模式

一篇文章彻底了解 HDFS 的平安模式

1 什么是 HDFS 的平安模式

Hdfs 的平安模式，即 HDFS safe mode, 是 HDFS 文件系统的一种非凡状态，在该状态下，hdfs 文件系统只承受读数据申请，而不承受删除、批改等变更申请，当然也不能对底层的 block 进行正本复制等操作。

从实质上将，平安模式 是 HDFS 的一种非凡状态，而 HDFS 进入该非凡状态的目标，是为了确保整个文件系统的数据一致性 / 不失落数据，从而限度用户只能读取数据而不能改变数据的。

2 什么状况下 HDFS 会进入平安模式

HDFS 进入平安模式的状况分为两种，即被动进入与被动进入。

2.1 HDFS 被动进入平安模式

管理员出于运维治理等各种起因，能够被动执行命令让 hdfs 进入平安模式，相干的命令有：hdfs dfsadmin -safemode enter/get/leave;

2.2 HDFS 被动进入平安模式

HDFS 也可能会被动进入平安模式，这种状况更为常见，是 HDFS 在非凡情况下，为了保障整个文件系统的数据一致性 / 整个文件系统不失落数据，而被动进入的一种自我爱护状态，底层根本原因又分为两种：

• HDFS 底层启动胜利并可能跟 namenode 放弃定期心跳的 datanode 的个数没有达到指定的阈值, 阈值通过参数 dfs.namenode.safemode.min.datanodes 指定；
• HDFS 底层达到了最小正本数要求的 block 的百分比没有达到指定的阈值：最小正本数通过参数 dfs.namenode.replication.min/dfs.namenode.safemode.replication.min 指定，阈值通过参数 dfs.namenode.safemode.threshold-pct 指定；
• 当然如果 HDFS 底层启动胜利并可能跟 namenode 放弃定期心跳的 datanode 的个数没有达到指定的阈值, 此时 HDFS 底层达到最小正本数要求的 block 的百分比个别也都不会达到指定的阈值；
• 不难理解，失常状况下，HDFS 启动过程中会有一段时间被动进入平安模式并在一段时间后被动退出平安模式，这是由 hdfs 的分本式架构决定的，因为 namenode 启动胜利后，须要期待 datanode 启动胜利并通过心跳汇报 datanode 上存储的 block 的信息（block report），只有在把握了足够的 block 的信息（达到最小正本数要求的 block 占所有 block 的百分比达到指定的阈值），并期待特定工夫后（通过参数 dfs.namenode.safemode.extension 30000 管制），才会被动退出平安模式。

从现实情况来看，常见的 HDFS 进入平安模式的间接起因有：

• 局部 datanode 启动失败或者因为网络起因与 namenode 心跳失败；
• 局部 datanode 节点存储 hdfs 数据的磁盘卷有损坏，导致存储在该磁盘卷中的数据无奈读取；
• 局部 datanode 节点存储 hdfs 数据的磁盘分区空间满，导致存储在该磁盘卷中的数据无奈失常读取；

3 HDFS 进入平安模式怎么办？

3.1 剖析起因

当 HDFS 被动进入平安模式后，首先须要剖析其被动进入平安模式的起因，能够通过以下路径进行剖析：

• 查看 namenode webui: 能够查看 hdfs namenode webui 的 “overview”/”Startup Progress”/”Datanode Volume Failures” 等页面；
• 查看 namenode 和 datanode 日志，能够间接查看后盾主机特定目录下的文件，如 /var/log/hadoop-hdfs 目录下的 hadoop-hdfs-hdfs-datanode-node1.out/hadoop-cmf-hdfs-NAMENODE-node1.log.out 等文件，也能够通过 CM 等管控台的 “ 诊断 - 日志 ” 等页面指定服务指定工夫指定日志级别进行搜寻；
• 比方如下报错日志，即提醒了 /dev/mapper/rhel-root 对应的文件系统即根目录磁盘空间有余，hadoop 主动进入了平安模式:

- org.apache.hadoop.hdfs.server.namenode.FSNamesystem:NameNode low on available disk space.Already in safemode.
- org.apache.hadoop.hdfs.StateChange: STATE* Safemode is ON. Resources are low on NN. Please add or free up more resources then turn off safemode manually. NOTE:If you turn off safemode before adding resources,the NN will immediately return to safemode. Use"hdfs dfsadmin -safemode leave" to turn safemode off.
- org.apache.hadoop.hdfs.server.namenode.NameNodeResourceChecker:Space available on volume '/dev/mapper/rhel-root' is 103092224, which is below the configured reserved amount 104857600

3.2 修复问题

通过以上排查确认进入平安模式的起因后，就能够进行针对性的修复了：

• 比方如果有 datanode 未启动胜利，则尝试修复并启动对应的 datanode;
• 比方如果有 datanode 存储 hdfs 数据的磁盘分区空间满，则尝试扩大磁盘分区空间；
• 比方如果有 datanode 存在存储卷故障，则尝试修复存储卷，如果无奈修复则须要替换存储卷（会失落存储卷上的数据）；
• 须要留神的是，如果呈现了某些 datanode 节点彻底损坏无奈启动，或某些 datanode 节点磁盘卷故障彻底无奈修复的状况，则这些数据对应的 block 及 block 下层的 hdfs 文件，就被失落了，后续可能须要联系业务人员补数据（从上游从新拉取数据，或从新运行作业生成数据），如果业务人员也无奈补数据，这些数据就被彻底损坏无奈复原了；
• 能够通过如下命令查看失落的 block 及这些 block 对应的下层 hdfs 文件，并记录下来后续交给业务人员去判断是否须要补数据：hdfs fsck / -list-corruptfileblocks，hdfs fsck / -files -blocks -locations；
• 对于不存在数据失落的状况，依照上述形式修复并重启集群后，HDFS 就会退出平安模式并失常对外提供读写服务；

• 对于存在数据失落的状况，须要通过如下命令手动退出平安模式并删除损坏的 / 失落的 block 对应的下层 hdfs 文件：

  • 退出平安模式（只有退出平安模式能力删除数据）：sudo -u hdfs hdfs dfsadmin -safemode leave;
  • 删除失落的 blockd 对应的下层 hdfs 文件（主动查看文件系统并把失落的 block 的下层 hdfs 文件删除）：sudo -u hdfs hdfs fsck / -delete;

  • 在删除了失落的 block 对应的下层 hdfs 文件后，HDFS 底层达到最小正本数要求的 block 的百分比就达到了指定的阈值（总文件数升高了总 block 数也相应升高了，所以胜利汇报的 block 的百分比就相应回升达到阈值了），所以重启后也就可能失常退出平安模式并失常对外提供读写服务了；

    3.3 修复问题的错误方法

    不对 hdfs 被动进入平安模式的具体起因进行剖析，而是间接通过如下办法强制退出平安模式，是无脑的谬误示范：

• 间接通过命令强制退出平安模式：sudo -u hdfs hdfs dfsadmin -safemode leave
• 不经剖析间接删除损坏的文件：sudo -u hdfs hdfs fsck / -delete
• 间接更改相干参数升高平安模式阈值：比方 dfs.namenode.safemode.threshold-pct/dfs.namenode.safemode.min.datanodes;

4 HDFS 平安模式相干参数

HDFS 平安模式相干参数有：

- dfs.namenode.safemode.threshold-pct: 正本数达到最小要求的 block 占零碎总 block 数的百分比, default 0.999f,Specifies the percentage of blocks that should satisfy the minimal replication requirement defined by dfs.namenode.replication.min. Values less than or equal to 0 mean not to wait for any particular percentage of blocks before exiting safemode. Values greater than 1 will make safe mode permanent;
- dfs.namenode.safemode.min.datanodes: 来到平安模式的最小可用 datanode 数量要求,default 0,Specifies the number of datanodes that must be considered alive before the name node exits safemode. Values less than or equal to 0 mean not to take the number of live datanodes into account when deciding whether to remain in safe mode during startup. Values greater than the number of datanodes in the cluster will make safe mode permanent;
- dfs.namenode.safemode.extension: 集群可用 block 比例、可用 datanode 都达到要求之后，主动退出平安模式的时延，default    30000,Determines extension of safe mode in milliseconds after the threshold level is reached. Support multiple time unit suffix (case insensitive), as described in dfs.heartbeat.interval;
- dfs.namenode.safemode.replication.min: 判断是否退出平安模式时对 block 的最小正本数的要求，默认为 1，a separate minimum replication factor for calculating safe block count. This is an expert level setting. Setting this lower than the dfs.namenode.replication.min is not recommend and/or dangerous for production setups. When it's not set it takes value from dfs.namenode.replication.min;
- dfs.namenode.replication.min: block 的最小正本数，default 1,    Minimal block replication;
其余磁盘预留空间大小类参数：dfs.datanode.du.reserved/dfs.datanode.du.reserved.pct/dfs.datanode.du.reserved.calculator/dfs.namenode.resource.du.reserved/dfs.namenode.resource.checked.volumes/dfs.namenode.resource.checked.volumes.minimum；

5 一个某客户生产环境 HDFS 进入平安模式的修复案例

某客户线上业务零碎中的大数据 HIVE 作业无奈运行，查看 hdfs 发现进入了平安模式，如下所示：

进一步查看发现，所有 datanode 都胜利启动了，但局部 datanode 存在存储卷故障，且这些存储卷背地是 nfs 网络文件系统，如下所示：

查看 datanode 日志发现，datanode 底层的 DataXceiver 线程无奈读取局部 block, 导致 ReplicaNotFoundException:

通过 CM 管控台的 “ 诊断 - 日志 ” 页面，指定服务为 HDFS，指定工夫为近期 1 个小时，指定日志级别为 WARN, 搜寻发现，调用办法
user=pwd.getpwuid(s.st_uid) 时报错了：keyError:’getpwuid(): uid not found: 4294967294’，且报错对应的正是 nfs 网盘目录:

通过 ls 命令查看发现，上述报错对应的 nfs 网盘目录的 owner 显示的正是错误信息中的 4294967294，而不是用户名比方 hdfs 等，且通过命令”uid hdfs“查看发现 hdfs 对应的 uid 并不是 4294967294:

至此问题确认，概括如下：

• nfs 挂载的目录被认为是 “Datanode Volume Failures”，所以 nfs 目录下的 block 数据对 hdfs 不可读写，所以正本数达到最小要求的 block 占零碎总 block 数的百分比达不到默认的阈值,hdfs 出于数据一致性的要求，主动进入了平安模式；
• 而导致 hdfs 无奈读写 nfs 对应目录下的 block 数据的起因是，不知出于何种起因，nfs 对应目录的 owner/group 显示的是 4294967294/4294967294，而不是冀望的 hdfs/hdfs，所以底层调用办法 user=pwd.getpwuid(s.st_uid) 获取 nfs 对应目录的 woner/group 时，报错了：keyError:’getpwuid(): uid not found: 4294967294’，最初 hdfs 因为无奈获取 nfs 对应目录的 owner/group 而无奈读取该目录下的文件；
• 为修复问题，手动通过命令 chown 更改了 nfs 对应目录的 owner/group 为 hdfs/hdfs，而后重启 hdfs，在重启后 hdfs 主动进入并主动退出了平安模式，失常对外提供读写服务。
• 为防止节点重启再呈现上述问题，后续安顿了理解 nfs 的运维同学帮忙排查下 nfs 挂载的目录为什么显示的 owner/group 是 4294967294/4294967294 而不是 hdfs/hdfs。
• 最初须要强调阐明下，因为 NFS 在性能和稳定性上相比本地磁盘差距不小，不倡议在 hdfs 底层应用 nfs 网盘。（如果在测试等环境应用 nfs 网盘，肯定要记得须要通过批改文件 /etc/fstab 确保开机主动挂载 nfs）.