Hadoop集群日常运维

(一)备份namenode的元数据

namenode中的元数据非常重要,如丢失或者损坏,则整个系统无法使用。因此应该经常对元数据进行备份,最好是异地备份。

1、将元数据复制到远程站点

(1)以下代码将secondary namenode中的元数据复制到一个时间命名的目录下,然后通过scp命令远程发送到其它机器

#!/bin/bash
export dirname=/mnt/tmphadoop/dfs/namesecondary/current/`date +%y%m%d%H`
if [ ! -d ${dirname} ]
then
mkdir  ${dirname}
cp /mnt/tmphadoop/dfs/namesecondary/current/*  ${dirname}
fi
scp -r ${dirname} slave1:/mnt/namenode_backup/
rm -r ${dirname}

(2)配置crontab,定时执行此项工作

0 0,8,14,20 * * * bash /mnt/scripts/namenode_backup_script.sh

2、在远程站点中启动一个本地namenode守护进程,尝试加载这些备份文件,以确定是否已经进行了正确备份。

(二)数据备份

对于重要的数据,不能完全依赖HDFS,而是需要进行备份,注意以下几点

(1)尽量异地备份

(2)如果使用distcp备份至另一个hdfs集群,则不要使用同一版本的hadoop,避免hadoop自身导致数据出错。

(三)文件系统检查

定期在整个文件系统上运行HDFS的fsck工具,主动查找丢失或者损坏的块。

建议每天执行一次。

[[email protected] ~]$ hadoop fsck /
……省略输出(若有错误,则在此外出现,否则只会出现点,一个点表示一个文件)……
.........Status: HEALTHY
 Total size:    14466494870 B
 Total dirs:    502
 Total files:   1592 (Files currently being written: 2)
 Total blocks (validated):      1725 (avg. block size 8386373 B)
 Minimally replicated blocks:   1725 (100.0 %)
 Over-replicated blocks:        0 (0.0 %)
 Under-replicated blocks:       648 (37.565216 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    2
 Average block replication:     2.0
 Corrupt blocks:                0
 Missing replicas:              760 (22.028986 %)
 Number of data-nodes:          2
 Number of racks:               1
FSCK ended at Sun Mar 01 20:17:57 CST 2015 in 608 milliseconds

The filesystem under path '/' is HEALTHY

(1)若hdfs-site.xml中的dfs.replication设置为3,而实现上只有2个datanode,则在执行fsck时会出现以下错误;

/hbase/Mar0109_webpage/59ad1be6884739c29d0624d1d31a56d9/il/43e6cd4dc61b49e2a57adf0c63921c09:  Under replicated blk_-4711857142889323098_6221. Target Replicas is 3 but found 2 replica(s).

注意,由于原来的dfs.replication为3,后来下线了一台datanode,并将dfs.replication改为2,但原来已创建的文件也会记录dfs.replication为3,从而出现以上错误,并导致 Under-replicated blocks:       648 (37.565216 %)。

(2)fsck工具还可以用来检查一个文件包括哪些块,以及这些块分别在哪等

[[email protected] conf]$ hadoop fsck /hbase/Feb2621_webpage/c23aa183c7cb86af27f15d4c2aee2795/s/30bee5fb620b4cd184412c69f70d24a7 -files -blocks -racks

FSCK started by jediael from /10.171.29.191 for path /hbase/Feb2621_webpage/c23aa183c7cb86af27f15d4c2aee2795/s/30bee5fb620b4cd184412c69f70d24a7 at Sun Mar 01 20:39:35 CST 2015
/hbase/Feb2621_webpage/c23aa183c7cb86af27f15d4c2aee2795/s/30bee5fb620b4cd184412c69f70d24a7 21507169 bytes, 1 block(s):  Under replicated blk_7117944555454804881_3655. Target Replicas is 3 but found 2 replica(s).
0. blk_7117944555454804881_3655 len=21507169 repl=2 [/default-rack/10.171.94.155:50010, /default-rack/10.251.0.197:50010]

Status: HEALTHY
 Total size:    21507169 B
 Total dirs:    0
 Total files:   1
 Total blocks (validated):      1 (avg. block size 21507169 B)
 Minimally replicated blocks:   1 (100.0 %)
 Over-replicated blocks:        0 (0.0 %)
 Under-replicated blocks:       1 (100.0 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    2
 Average block replication:     2.0
 Corrupt blocks:                0
 Missing replicas:              1 (50.0 %)
 Number of data-nodes:          2
 Number of racks:               1
FSCK ended at Sun Mar 01 20:39:35 CST 2015 in 0 milliseconds

The filesystem under path '/hbase/Feb2621_webpage/c23aa183c7cb86af27f15d4c2aee2795/s/30bee5fb620b4cd184412c69f70d24a7' is HEALTHY

此命令的用法如下:

[[email protected] ~]$ hadoop fsck -files
Usage: DFSck <path> [-move | -delete | -openforwrite] [-files [-blocks [-locations | -racks]]]
        <path>  start checking from this path
        -move   move corrupted files to /lost+found
        -delete delete corrupted files
        -files  print out files being checked
        -openforwrite   print out files opened for write
        -blocks print out block report
        -locations      print out locations for every block
        -racks  print out network topology for data-node locations
                By default fsck ignores files opened for write, use -openforwrite to report such files. They are usually  tagged CORRUPT or HEALTHY depending on their block allocation status
Generic options supported are
-conf <configuration file>     specify an application configuration file
-D <property=value>            use value for given property
-fs <local|namenode:port>      specify a namenode
-jt <local|jobtracker:port>    specify a job tracker
-files <comma separated list of files>    specify comma separated files to be copied to the map reduce cluster
-libjars <comma separated list of jars>    specify comma separated jar files to include in the classpath.
-archives <comma separated list of archives>    specify comma separated archives to be unarchived on the compute machines.

The general command line syntax is
bin/hadoop command [genericOptions] [commandOptions]

详细解释请见《hadoop权威指南》P376

(四)均衡器

随时时间推移,各个datanode上的块分布来越来越不均衡,这将降低MR的本地性,导致部分datanode相对更加繁忙。

均衡器是一个hadoop守护进程,它将块从忙碌的DN移动相对空闲的DN,同时坚持块复本放置策略,将复本分散到不同的机器、机架。

建议定期执行均衡器,如每天或者每周。

(1)通过以下命令运行均衡器

[[email protected] log]$ start-balancer.sh
starting balancer, logging to /var/log/hadoop/hadoop-jediael-balancer-master.out

查看日志如下:

[[email protected] hadoop]$ pwd
/var/log/hadoop
[[email protected] hadoop]$ ls
hadoop-jediael-balancer-master.log  hadoop-jediael-balancer-master.out
[[email protected] hadoop]$ cat hadoop-jediael-balancer-master.log
2015-03-01 21:08:08,027 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /default-rack/10.251.0.197:50010
2015-03-01 21:08:08,028 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /default-rack/10.171.94.155:50010
2015-03-01 21:08:08,028 INFO org.apache.hadoop.hdfs.server.balancer.Balancer: 0 over utilized nodes:
2015-03-01 21:08:08,028 INFO org.apache.hadoop.hdfs.server.balancer.Balancer: 0 under utilized nodes:

(2)均衡器将每个DN的使用率与整个集群的使用率接近,这个“接近”是通过-threashold参数指定的,默认是10%。

(3)不同节点之间复制数据的带宽是受限的,默认是1MB/s,可以通过hdfs-site.xml文件中的dfs.balance.bandwithPerSec属性指定(单位是字节)。

时间: 2024-10-27 05:56:51

Hadoop集群日常运维的相关文章

Ceph 存储集群-低级运维

低级集群运维包括启动.停止.重启集群内的某个具体守护进程:更改某守护进程或子系统配置:增加或拆除守护进程.低级运维还经常遇到扩展.缩减 Ceph 集群,以及更换老旧.或损坏的硬件. 一.增加/删除 OSD 如果您的集群已经在运行,你可以在运行时添加或删除 OSD . 增加 OSD 你迟早要扩容集群, Ceph 允许在运行时增加 OSD .在 Ceph 里,一个 OSD 一般是一个 ceph-osd 守护进程,它运行在硬盘之上,如果你有多个硬盘,可以给每个硬盘启动一个 ceph-osd 守护进程.

Hadoop集群完全分布式模式环境部署和管理的5大工具

当你利用 Hadoop 进行大数据分析和处理时,首先你需要确保配置.部署和管理集群.这个即不容易也没有什么乐趣,但却受到了开发者们的钟爱.本文提供了5款工具帮助你实现. Apache Ambari Apache Ambari是对Hadoop进行监控.管理和生命周期管理的开源项目.它也是一个为Hortonworks数据平台选择管理组建的项目.Ambari向Hadoop MapReduce.HDFS. HBase.Pig, Hive.HCatalog以及Zookeeper提供服务. Apache M

hadoop日常运维与升级总结

日常运维 升级 问题处理方法 日常运维 进程管理 由于配置文件的更改,需要重启生效, 或者是进程自己因某种致命原因终止, 或者发现进程工作出现异常等情况下,需要进行手动进程的关闭或启动, 或者是增删节点过程中的需要, 进程的关闭与启动,使用 hadoop-daemon.sh start|stop datanode/namenode/journalnode/zkfc yarn-daemon.sh start|stop nodemanager/resourcemanager 检查进程是否完成关闭:

Hadoop日常运维问题汇总

一:namenode出现missing blocks 日常巡检CDH集群和HDP集群发现有些namenode下有很多missing blocks ,hadoop数据存储单位为块.一块64M,这些Missing大多因为元数据丢失而毁坏,很难恢复.就行硬盘故障一样,需要fsck并且delete. CDH集群 :Cloudera manager的dashboard----HDFS----NameNode  Web UI 如图: ----- HDP集群:Ambari Server 的dashboard-

Hbase 日常运维

1.1监控Hbase运行状况 1.1.1操作系统 1.1.1.1IO a.群集网络IO,磁盘IO,HDFS IO IO越大说明文件读写操作越多.当IO突然增加时,有可能:1.compact队列较大,集群正在进行大量压缩操作. 2.正在执行mapreduce作业 可以通过CDH前台查看整个集群综合的数据或进入指定机器的前台查看单台机器的数据: b.Io wait 磁盘IO对集群的影响比较大,如果io wait时间过长需检查系统或磁盘是否有异常.通常IO增加时io wait也会增加,现在FMS的机器

zookeeper 用法和日常运维

本文以ZooKeeper3.4.3版本的官方指南为基础:http://zookeeper.apache.org/doc/r3.4.3/zookeeperAdmin.html,补充一些作者运维实践中的要点,围绕ZK的部署和运维两个方面讲一些管理员需要知道的东西.本文并非一个ZK搭建的快速入门,关于这方面,可以查看<ZooKeeper快速搭建>. 1.部署 本章节主要讲述如何部署ZooKeeper,包括以下三部分的内容: 系统环境 集群模式的配置 单机模式的配置 系统环境和集群模式配置这两节内容大

Hadoop集群选择合适的硬件配置

为Hadoop集群选择合适的硬件配置 随着Apache Hadoop的起步,云客户的增多面临的首要问题就是如何为他们新的的Hadoop集群选择合适的硬件. 尽管Hadoop被设计为运行在行业标准的硬件上,提出一个理想的集群配置不想提供硬件规格列表那么简单. 选择硬件,为给定的负载在性能和经济性提供最佳平衡是需要测试和验证其有效性.(比如,IO密集型工作负载的用户将会为每个核心主轴投资更多). 在这个博客帖子中,你将会学到一些工作负载评估的原则和它在硬件选择中起着至关重要的作用.在这个过程中,你也

大数据系列(1)——Hadoop集群坏境搭建配置

前言 关于时下最热的技术潮流,无疑大数据是首当其中最热的一个技术点,关于大数据的概念和方法论铺天盖地的到处宣扬,但其实很多公司或者技术人员也不能详细的讲解其真正的含义或者就没找到能被落地实施的可行性方案,更有很多数据相关的项目比如弄几张报表,写几个T-SQL语句就被冠以“大数据项目”,当然了,时下热门的话题嘛,先把“大数据”帽子扣上,这样才能显示出项目的高大上,得到公司的重视或者高层领导的关注. 首先,关于大数据的概念或者架构一直在各方争议的背景下持续的存在着.目前,关于大数据项目可以真正被落地

Hadoop集群硬盘故障分析与自动化修复

作者:Zhang, Haohao 摘要: 硬盘在服务器中起着至关重要的作用,因为硬盘里面存储的是数据,随着制造业技术的提高,硬盘的类型也在逐渐的改变.对于硬盘的管理是IAAS部门的责任,但作为业务运维也需要懂得相关的技术. 有的公司采用LVM来管理硬盘,这样做方便扩缩容,也有的公司直接用裸盘来存数据,这样做的好处是不会因LVM而损失掉一部分硬盘I/O速度.需要根据不同的场景采用不同的方式来管理. Hadoop集群中跑Datanode服务的节点不建议做LVM,因为没有必要,你想想,Hadoop的H