hadoop平常运维与升级总结

平常运维 升级 问题处理方法java

平常运维

进程管理

因为配置文件的更改,须要重启生效,node

或者是进程本身因某种致命缘由终止,python

或者发现进程工做出现异常等状况下,须要进行手动进程的关闭或启动,linux

或者是增删节点过程当中的须要,web

进程的关闭与启动,使用bootstrap

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

yarn-daemon.sh start|stop nodemanager/resourcemanager安全

检查进程是否完成关闭:bash

jps 或者 ps –ef | grep datanode|namenode|journalnode|zkfc|nodemanager|resourcemanagerapp

注意:要清楚本身关闭的每个进程对正在运行的集群会产生什么样的影响

集群健康检查

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 …)

相关文章
相关标签/搜索