hadoop集群部署时候的几个问题记录
本章部署一个hadoop集群
由于2.5.x已经出来有好几个月了,网上配置类似架构的文章也有很多,所以在这里重点描述一下namenode和secondarynamenode不再同一台机器上的配置方法,以及namenode宕机后meta数据的恢复方法,并且描述一下几个主要配置文件中配置项的意义。
集群大概框架为
1个namenode一个secondarynamenode两个datanode。
其中secondarynamenode和datanode理论上来说是可以无限扩展的。
安装jdk、ssh免密码登陆,下载hadoop神马的就不啰嗦了,主要来记录下几个主要配置文件的配置项
文件一core-site.xml
<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://cloud001:9000</value> <description>NameNode URI<description/> </property> <property> <name>io.file.buffer.size</name> <value>4069</value> <description>Size of read/write buffer used in SequenceFiles.<description/> </property> <property> <name>hadoop.tmp.dir</name> <value>/snwz/hadoop/config/temp</value> <description><description/> </property> </configuration>
io.file.buffer.size:hadoop访问文件的IO操作都需要通过代码库。因此,在很多情况下,io.file.buffer.size都被用来设置缓存的大小。不论是对硬盘或者是网络操作来讲,较大的缓存都可以提供更高的数据传输,但这也就意味着更大的内存消耗和延迟。这个参数要设置为系统页面大小的倍数,以byte为单位,默认值是4KB,一般情况下,可以设置为64KB(65536byte)
hadoop.tmp.dir:hadoop文件系统依赖的基本配置,很多配置路径都依赖它,它的默认位置在/tmp/{$user}下面,建议修改默认路径,因为linux启动会将temp目录下文件删除。
文件二:hdfs-site.xml
<configuration> <property> <name>dfs.namenode.secondary.http-address</name> <value>cloud001:9001</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:/snwz/hadoop/config/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:/snwz/hadoop/config/data</value> </property> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.webhdfs.enabled</name> <value>true</value> </property> </configuration>
dfs.namenode.name.dir:PathonthelocalfilesystemwheretheNameNodestoresthenamespaceandtransactionslogspersistently.
dfs.datanode.data.dir:CommaseparatedlistofpathsonthelocalfilesystemofaDataNodewhereitshouldstoreitsblocks.
dfs.replicatio:副本数量,建议配置和slaves数目相同
dfs.webhdfs.enabled:dfs的web页面功能是否启用,建议启动
dfs.namenode.secondary.http-address:secondarynamenode的地址,在此着重说下这个配置。
大部分人包括我仅仅认为snn是nn的一个热备份,其实它真正的用途,是用来保存namenode中对HDFSmetadata的信息的备份,并减少namenode重启的时间。hadoop的默认配置中让snn进程默认运行在了namenode的那台机器上,但是这样的话,如果这台机器出错,宕机,对恢复HDFS文件系统是很大的灾难,更好的方式是:将snn的进程配置在另外一台机器上运行。在hadoop中,namenode负责对HDFS的metadata的持久化存储,并且处理来自客户端的对HDFS的各种操作的交互反馈。为了保证交互速度,HDFS文件系统的metadata是被load到namenode机器的内存中的,并且会将内存中的这些数据保存到磁盘进行持久化存储。为了保证这个持久化过程不会成为HDFS操作的瓶颈,hadoop采取的方式是:没有对任何一次的当前文件系统的snapshot进行持久化,对HDFS最近一段时间的操作list会被保存到namenode中的一个叫Editlog的文件中去。当重启namenode时,除了loadfsImage意外,还会对这个EditLog文件中记录的HDFS操作进行replay,以恢复HDFS重启之前的最终状态。
而SecondaryNameNode,会周期性的将EditLog中记录的对HDFS的操作合并到一个checkpoint中,然后清空EditLog。所以namenode的重启就会Load最新的一个checkpoint,并replayEditLog中记录的hdfs操作,由于EditLog中记录的是从上一次checkpoint以后到现在的操作列表,所以就会比较小。如果没有snn的这个周期性的合并过程,那么当每次重启namenode的时候,就会花费很长的时间。而这样周期性的合并就能减少重启的时间。同时也能保证HDFS系统的完整性。
关于如何分离namenode和secondarynamenode下面这篇文章说的很详细了
http://blog.csdn.net/xiaojiafei/article/details/10162919
关于如何恢复在这里也不再啰嗦,感兴趣的朋友可以自己去搜一下。
关于checkpoin频率等优化问题我们后面再慢慢研究。
文件三:.mapred-site.xml
<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> <property> <name>mapreduce.jobtracker.http.address</name> <value>cloud001:50030</value> </property> <property> <name>mapreduce.jobhistory.address</name> <value>cloud001:10020</value> </property> <property> <name>mapreduce.jobhistory.webapp.address</name> <value>cloud001:19888</value> </property> </configuration>
mapreduce.framework.name:新框架支持第三方MapReduce开发框架以支持如SmartTalk/DGSG等非Yarn架构,注意通常情况下这个配置的值都设置为Yarn,如果没有配置这项,那么提交的Yarnjob只会运行在locale模式,而不是分布式模式。
mapreduce.jobtracker.http.address:jobtracker监听端口
mapreduce.jobhistory.*:hadoop历史服务器,可以通过历史服务器查看已经运行完的Mapreduce作业记录,比如用了多少个Map、用了多少个Reduce、作业提交时间、作业启动时间、作业完成时间等信息。默认情况下,Hadoop历史服务器是没有启动的,我们可以通过下面的命令来启动Hadoop历史服务器。
sbin/mr-jobhistory-daemon.shstarthistoryserver
这篇文章很详细的介绍了历史服务器的原理以及配置:http://www.aboutyun.com/thread-8150-1-1.html
文件四:yarn-site.xml
<configuration> <!-- Site specific YARN configuration properties --> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> <property> <name>yarn.resourcemanager.address</name> <value>nameNode:8032</value> </property> <property> <name>yarn.resourcemanager.scheduler.address</name> <value>nameNode:8030</value> </property> <property> <name>yarn.resourcemanager.resource-tracker.address</name> <value>nameNode:8031</value> </property> <property> <name>yarn.resourcemanager.admin.address</name> <value>nameNode:8033</value> </property> <property> <name>yarn.resourcemanager.webapp.address</name> <value>nameNode:8088</value> </property> </configuration>
yarn.resourcemanager.address:namenode与resourcemanager通讯接口
yarn.resourcemanager.resource-tracker.address:新框架中NodeManager需要向RM报告任务运行状态供Resouce跟踪,因此NodeManager节点主机需要知道RM主机的tracker接口地址
yarn.resourcemanager.admin.address:管理命令通过ResourceManager主机访问host:port
yarn.resourcemanager.webapp.address:管理页面地址
主要配置就是这些了。后续会就事论事,遇到哪个配置不明白或者需要重点说明的我会都记录下来跟大家一起分享。