|
由于Hadoop 2.5.x 已经出来有好几个月了，网上配置类似架构的文章也有很多，所以在这里重点描述一下namenode 和 secondary namenode不再同一台机器上的配置方法，以及namenode 宕机后 meta数据的恢复方法，并且描述一下几个主要配置文件中配置项的意义。 集群大概框架为 1个namenode 一个 secondary namenode 两个datanode。 其中 secondary namenode 和 datanode 理论上来说是可以无限扩展的。 安装jdk、ssh免密码登陆，下载hadoop神马的就不啰嗦了，主要来记录下几个主要配置文件的配置项 文件一 core-site.xml
<configuration>
<property>
<property> 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>
<property>
<property>
<property> dfs.namenode.name.dir：Path on the local filesystem where the NameNode stores the namespace and transactions logs persistently. dfs.datanode.data.dir：Comma separated list of paths on the local filesystem of a DataNode where it should store its blocks. dfs.replicatio：副本数量，建议配置和slaves数目相同 dfs.webhdfs.enabled：dfs 的web页面功能是否启用，建议启动 dfs.namenode.secondary.http-address：secondary namenode 的地址，在此着重说下这个配置。 大部分人包括我 仅仅认为 snn是 nn 的一个热备份，其实它真正的用途，是用来保存namenode中对HDFS metadata的信息的备份，并减少namenode重启的时间。hadoop的默认配置中让 snn进程默认运行在了 namenode 的那台机器上，但是这样的话，如果这台机器出错，宕机，对恢复HDFS文件系统是很大的灾难，更好的方式是：将snn的进程配置在另外一台机器 上运行。在hadoop中，namenode负责对HDFS的metadata的持久化存储，并且处理来自客户端的对HDFS的各种操作的交互反馈。为了保 证交互速度，HDFS文件系统的metadata是被load到namenode机器的内存中的，并且会将内存中的这些数据保存到磁盘进行持久化存储。为 了保证这个持久化过程不会成为HDFS操作的瓶颈，hadoop采取的方式是：没有对任何一次的当前文件系统的snapshot进行持久化，对HDFS最 近一段时间的操作list会被保存到namenode中的一个叫Editlog的文件中去。当重启namenode时，除了 load fsImage意外，还会对这个EditLog文件中 记录的HDFS操作进行replay，以恢复HDFS重启之前的最终状态。 而SecondaryNameNode，会周期性的将EditLog中记录的对HDFS的操作合并到一个checkpoint中，然后清空 EditLog。所以namenode的重启就会Load最新的一个checkpoint，并replay EditLog中 记录的hdfs操作，由于EditLog中记录的是从 上一次checkpoint以后到现在的操作列表，所以就会比较小。如果没有snn的这个周期性的合并过程，那么当每次重启namenode的时候，就会 花费很长的时间。而这样周期性的合并就能减少重启的时间。同时也能保证HDFS系统的完整性。 关于如何分离 namenode 和secondary namenode 下面这篇文章说的很详细了
关于如何恢复 在这里也不再啰嗦，感兴趣的朋友可以自己去搜一下。 关于checkpoin频率等优化问题我们后面再慢慢研究。 文件三：.mapred-site.xml
<configuration> mapreduce.framework.name：新框架支持第三方 MapReduce 开发框架以支持如 SmartTalk/DGSG 等非 Yarn 架构，注意通常情况下这个配置的值都设置为 Yarn，如果没有配置这项，那么提交的 Yarn job 只会运行在 locale 模式，而不是分布式模式。 mapreduce.jobtracker.http.address:job tracker 监听端口 mapreduce.jobhistory.*：hadoop历史服务器，可以通过历史服务器查看已经运行完的Mapreduce作业记录，比如用了多少个Map、用了多少个Reduce、作业提交时间、作业启动时间、作业完成时间等信息。默认情况下，Hadoop历史服务器是没有启动的，我们可以通过下面的命令来启动Hadoop历史服务器。 sbin/mr-jobhistory-daemon.sh start historyserver 这篇文章很详细的介绍了历史服务器的原理以及配置： 文件四：yarn-site.xml <configuration> <!-- Site specific YARN configuration properties -->
<property>
<property>
mapreduce_shuffle :
主要配置就是这些了。后续会就事论事，遇到哪个配置不明白或者需要重点说明的 我会都记录下来跟大家一起分享。 |