hadoop日常运维与升级总结

日常运维升级问题处理方法

日常运维

进程管理

由于配置文件的更改，需要重启生效，

或者是进程自己因某种致命原因终止，

或者发现进程工作出现异常等情况下，需要进行手动进程的关闭或启动，

或者是增删节点过程中的需要，

进程的关闭与启动，使用

hadoop-daemon.sh start|stop datanode/namenode/journalnode/zkfc

yarn-daemon.sh start|stop nodemanager/resourcemanager

检查进程是否完成关闭：

注意：要清楚自己关闭的每一个进程对正在运行的集群会产生什么样的影响

集群健康检查

hdfs fsck / 进行文件系统健康检查，是否有块丢失，如何处理？

hdfs fsck 也可以用来查看你关心的某些文件的块的分布情况。

Hdfs fsck /path –files –blocks –locations 可以显示详细的文件，block位置等信息。

Datanodes 是否有死的节点，有可能进程还在但是状态是不正常的。

ResourceManager的管理页面上观察是否有lost的nodemanager节点，查找原因，解决。

进程日志文件检查：检查其中频繁出现的异常，从warn级别的信息中往往能发现出现异常错误的原因，搜索查找原因，修改配置文件或做其他的调整。

新增节点

硬件安装

1）操作系统本身的安装，关闭防火墙，selinux

2）修改limits.conf sysctl.conf 保持一致

3）创建hadoop用户

4）生成ssh无密钥访问

Root: 直接拷贝其他系统的.ssh文件夹整个集群使用一个

Hadoop:生成密钥分发到某一固定节点，如namenode

最后从含有完整公钥的机器上把authorizedkeys 重新分发到各节点一份

5）修改主机名与集群保持一致，

sed –i ‘s/HOSTNAME=.*/HOSTNAME=dn1’ /etc/sysconfig/network

6）修改/etc/hosts

这个也可以在namenode上进行，配置好新增节点的ip信息，在ssh配好后，

可以直接分发到所有节点，不仅是新增节点。

7）同步文件

假设这个节点上只运行datanode,nm之类的

从已有节点同步jdk,hadoop到相同的目录(不用复制hadoop的日志文件，太大无用)

(rsync –v nn1:/app/cdh23502/ /app)

从已有节点复制 .bash_profile文件到新节点，并且source .bash_profile使之生效

测试 java –version 和 hadoop version 是否正常工作

8）测试本地库是否正常

Hadoop checknative

如果没有安装本地库压缩请安装相应程序

创建数据盘的根目录，并把此权限赋给hadoop用户

9）在nn1上修改etc/hadoop/slaves，在里面添加新增的节点hostname.

修改机架感知信息，一般是在一个文本文件里面，通过python加载，修改完成分发。

在新增节点上启动datanode,nodemanager等进程

10）通过 hdfs dfsadmin –report 或在webui 上观察datanode是否向namenode注册成功。

必要的时候运行：hadoop dfsadmin -refreshNodes

平衡数据

Start-balancer.sh

Hdfs balancer –help

Hdfs balancer –threshold 5

Hdfs-site.xml

dfs.datanode.balance.bandwidthPerSec：1m

dfs.datanode.balance.max.concurrent.moves :5

要理解数据平衡的基本原理，根据threshold计算集群点节点存储是否平衡，然后迭代进行移动，至到达到相对平衡，然后进程自动退出。

删除节点

如果需要主动把所在节点的数据转移，则建议使用：

先在配置的excludes文件中添加要删除的节点，然后执行下面命令

hadoop dfsadmin –refreshNodes

网上有资料表明，有同学使用这种方式进行数据的转移，在节点的磁盘被使用殆尽的情况下，平衡进程太慢，节点退役反而很快，退役后格式化磁盘，然后加回来，加快了数据的平衡处理。

处理磁盘问题

datanode 的配置可以在线更新了，http://blog.cloudera.com/blog/2015/05/new-in-cdh-5-4-how-swapping-of-hdfs-datanode-drives/

在大的hadoop生产集群中，每一台机器都会配置多块硬盘，而硬盘的损坏也是常态，如何让硬盘的损坏不影响正常的生产呢？

如果在hdfs-site.xml中把 dfs.datanode.failed.volumes.tolerated 设置为大于0的数字，则datanode 允许配置的磁盘有配置数量的损坏。

否则，如果配置为0 ，若发生了磁盘的损坏，Datanode进程会shutdown.

如果我们不想datanode进程自动关闭，可以合理配置dfs.datanode.failed.volumes.tolerated .

然后从日志监控中发现有磁盘发生损坏的情况发生，我们可以修改hdfs-site.xml中dfs.datanode.data.dir 的配置，

去掉坏掉的盘，然后执行

hdfs dfsadmin –reconfig datanode dnxx:50020 start

hdfs dfsadmin –reconfig datanode dnxx:50020 status

之类的，让datanode在线更新配置

换上新盘后，再刷新一下配置即可。

这样不用关闭Datanode进程。如果是低版本的，可以直接把发生问题的磁盘路径从配置的dfs.data.dir从去掉，然后启动datanode进程，然后修好后再加回来，重启datanode进程。

也可以调整容错的数量，dfs.datanode.failed.volumes.tolerated，思路是一样的，只是低版本的是需要重启动datanode进程。

处理长时间不能完成的任务

mapred job -fail-task

mapred job -kill-task

两者的不同，前者把任务失败掉，这个任务就不会再分配给这个节点运行，而kill的task则还可能会分给这个节点运行，而且fail-task的过多，这个节点会被加入黑名单。

升级

升级有风险，cdh之间小版本的升级可能不需要修改hdfs的元数据，只需要替换应用包即可。如果是大版本的升级，则需要升级hdfs文件的元数据。

今天主要说一下hadoop的升级，在生产中，我们一起升级套件，如hive和hbase等，这时候需要和开发人员多交流，我之前做开发有过经历，项目中写的hive语句与调用方式在一次hive的升级后变得不可用，需要花一段时间进行调整。

以下的链接记录了我做的升级实验，hadoop2.35.0.2升级到hadoop2.6cdh5.5 .

原因，我所在山东移动使用hadoop2.35.0.2 ，而且有新集群已经部署,hadoop2.6.

两台机器，nn1,nn2搭建的ha,同时又担任nn,dn,rm,nm,jn,zkfc,zk等职能。

以下是升级回滚再升级的记录。仅供参考，同时参考了cdh官网的说明，官网主要是使用CM的。

1 官网上下载hadoop2.6cdh5.5.tar包和hadoop的rpm包

rpm2cpio hadoop.rpm | cpio –div

可以从里面找到我们需要的native的文件。

2 复制原cdh下的etc/下的所有文件到hadoop2.6下的etc/hadoop

3 进入安全模式，生成fsimage文件，并备份整个metadata 文件夹

hdfs dfsadmin -safemode enter
hdfs dfsadmin –saveNamespace

cd /hdp/dfs/name
tar -cvf nn_backup_data.tar .

4. 关停所有相关的进程

stop-all.sh
stop-hbase.sh
ps -aef | grep java

5 纷发新的文件到其他节点

6 修改.bash_profile（根据你自己的配置）把HADOOP_HOME 指向新的目录

并纷发到所有机器上，并加载这个文件使其生效。

7 先启动jn 然后升级hdfs metadata

hadoop-daemons.sh start journalnode

hdfs namenode -upgrade
hadoop-daemons.sh start datanode

根据你的block的数量情况，但是一般会很快的。我这边遇到的情况下，一直会报：缓存管理器在扫描之类的日志，好像是bug.不影响升级。

8 回滚

升级后,namenode ，journalnode和datanode下面的相关version等文件有变动.回滚的操作如下：

先操作journalnode的：

可以直接进入journalnode配置目录下，把current的改成new,把previous的改成current.

或执行

hadoop-daemons.sh start journalnode -rollback（未尝试）

hdfs namenode –rollback

hadoop-daemons.sh start datanode –rollback

9升级后测试

pdsh -w nn1,nn2 "source /home/student/.bash_profile; zkServer.sh start"

在nn2上，hdfs namenode –bootstrapStandby

同步新生成的fsimage

start-dfs.sh

start-yarn.sh

hadoop jar /app/cdh26550/share/hadoop/mapreduce2/hadoop-mapreduce-examples-2.6.0-cdh5.5.0.jar wordcount pi 10 100

问题处理

问题归类

1．个人操作：错误的判断所做的操作或误操作

2．错误配置:35%的问题都是因为错误或不合理的配置引发的

一定要深入理解配置参数的含义，要根据自己集群的情况定制，不是放之四海而皆准的固定的答案。

操作系统级别的配置

Hadoop/hdfs/yarn本身的配置 (内存参数等)

3．硬件错误（常见硬盘错误）

4．资源耗尽（nodemanager 健康检查报告）

方法论

1．查看出现问题进程日志文件（$HADOOP_HOME/logs）

2． Dump相关进程，查看进程栈相关代码

Javacore 文件中也有当前栈的信息可供分析

3．查看系统信息/var/log/messages 或 dmesg 查看是否有显示相关错误，如硬件错误或文件系统的错误

如果是map/reduce任务的错误，查看相关的输出stdout,syslog,syserr中可以找到相关根本的原因。(class not found …)