Hadoop实验学习笔记（参考）

实验环境：Ubuntu 12.04，Hadoop-1.1.2, VirtualBox 虚拟机 3-4 台

192.168.1.7 hadoop-master

192.168.1.8 hadoop-slave1

192.168.1.9 hadoop-slave2

为分离NameNode 和 SecondaryNameNode ，新建以下SecondaryNameNode节点

192.168.1.10 SNN

一、 能否给web监控界面加上安全机制，怎样实现？抓图过程

1. 配置core-site.xml，并scp到其他节点

2013-8-9 22:55 上传 下载附件 (243.98 KB)

2. 手动创建 ${user.home}/hadoop-http-auth-signature-secret 文件，并sep到其他节点

2013-8-9 22:55 上传 下载附件 (492.96 KB)

注：这里无法自动创建，必须手动创建。见 BUG ：HADOOP-8857

3. 访问web console，无法匿名访问，输入user.name后能访问

2013-8-9 22:55 上传 下载附件 (208.15 KB)

2013-8-9 22:55 上传 下载附件 (537.11 KB)

注：只有首次访问需要user.name

主要参考：

http://hadoop.apache.org/docs/stable/HttpAuthentication.html

以上只是简单的伪验证，如果需要使用kerberos来加密，过程非常复杂，可参考：

http://www.cloudera.com/content/support/en/documentation/cdh3-documentation/cdh3-documentation-v3-latest.html

http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/4.2.1/CDH4-Security-Guide/cdh4sg_topic_3_2.html

http://blog.zhengdong.me/2011/10/20/install-hadoop-with-kerberos-in-ubuntu

http://blog.chinaunix.net/uid-1838361-id-3243243.html

二、 模拟namenode崩溃，例如将name目录的内容全部删除，然后通过secondary namenode恢复namenode，抓图实验过程

1. 删除NameNode中 name目录下的所有内容， NameNode down

2013-8-9 22:56 上传 下载附件 (719.67 KB)

2013-8-9 22:56 上传 下载附件 (839.33 KB)

2. 停止集群，格式化NameNode

3. 从DataNode获取down之前的namespaceID

2013-8-9 22:56 上传 下载附件 (414.69 KB)

4. 修改NameNode namespaceID 为 down之前的namespaceID

2013-8-9 22:56 上传 下载附件 (242.42 KB)

5. 删除新NameNode 的 fsimage文件

2013-8-9 22:56 上传 下载附件 (433.51 KB)

6. 从 SecondaryNameNode scp fsimage 到 NameNode

2013-8-9 22:56 上传 下载附件 (259.16 KB)

7. 重新启动集群

2013-8-9 22:56 上传 下载附件 (436.79 KB)

三、怎样改变HDFS块大小？实验验证并抓图过程

1. 查看原block size

2013-8-9 22:56 上传 下载附件 (228.95 KB)

2. 设置hdfs-site.xml 中 dfs.block.size = 128M, scp 到其他节点，并重启集群

2013-8-9 22:56 上传 下载附件 (72.82 KB)

3. bin/hadoop fs -put ~/input in, 并查看web console

2013-8-9 22:56 上传 下载附件 (204.6 KB)

四、 把secondary namenode和namenode分离，部署到单独的节点，抓图实验过程

原系统namenode 和 secondaryNamenode 运行在同一机器上：hadoop-master

2013-8-9 22:56 上传 下载附件 (447.23 KB)

1. clone hadoop-master

2.  ip：192.168.1.10

3. /etc/hostname : SNN

所有节点：

4. /etc/hosts : 192.168.1.10  SNN

5. /usr/local/hadoop/conf/masters:  SNN

6. hdfs-site.xml 设置 dfs.http.address 和 dfs.secondary.http.adress

2013-8-9 22:56 上传 下载附件 (139.15 KB)

7.重启虚拟机

8. 配置 ssh 免密码登陆

9. bin/hadoop namenode -format

10. 修改其他节点（包括SNN）的namespaceID 与namenode 的 namespaceID 相同，或者删除其他节点tmp目录下的数据。（参考第五题）

11. 启动集群

NameNode 和 SecondaryNameNode 已经分开

2013-8-9 22:58 上传 下载附件 (478.53 KB)

12. 参考第六题 设置 fs.checkpoint.period, 实现NameNode和SecondaryNameNode分离提交下，checkpoint 控制

2013-8-9 22:59 上传 下载附件 (554.01 KB)

五、 在Hadoop集群实施成功后，再次格式化名称节点，请问此时datanode还能加入集群不？如果不能加入怎样解决？模拟过程并抓图

1. 停止集群，并bin/hadoop namenode -format

2013-8-9 22:59 上传 下载附件 (815.35 KB)

2. 启动集群，并查看datanode

2013-8-9 22:59 上传 下载附件 (631.29 KB)

datanode 无法启动

3. 查看日志，显示 datanode 与 namenode namespaceID 不同所致

2013-8-9 22:59 上传 下载附件 (475.29 KB)

4. 修改所有datanode /usr/local/hadoop/tmp/dfs/data/current/VERSION 中namespaceID 为 namenode namespaceID，或删除datanode 中 /usr/local/hadoop/tmp/dfs/data 目录。这里采用后者。

2013-8-9 22:59 上传 下载附件 (316.97 KB)

5. 重启集群，datanode 启动

2013-8-9 22:59 上传 下载附件 (620.54 KB)

六、 怎样控制namenode检查点发生的频率，用实验模拟检查点发生的前后过程，并抓图发生前和发生后的元数据情况进行比较，说明之

1. core-site.xml 中设置 fs.checkpoint.period=180, scp 到 所有节点

2013-8-9 22:59 上传 下载附件 (74.39 KB)

2. 重启集群，并查看namenode /usr/local/hadoop/tmp/dfs/name/current中 fsimage,edits等的更新频率。

每隔4分钟查看，发现namenode 每隔 180 秒 checkpoint 更新

2013-8-9 22:59 上传 下载附件 (646.82 KB)

3. 观察checkpoint 前后 namenode的变化

检查点发生前：

（1）16:10 的checkpoint 显示，namenode的fsimage和edits 最后修改时间为16：10。

（2）16：11 向hdfs系统加入 input ，namenode 中的edits 记录 这次操作，其修改时间为16：11

检查点发生后（16：13）：namenode 中的fsimage（16：10） 被 seondarynamenode 新产生的fsimage（16：13-由fsimage16：10 和 edits 16：11合成）代替，edits（16：11）被新产生的edits代替。

2013-8-9 22:59 上传 下载附件 (622.6 KB)

4.  基本原理

当距离上个checkpoint 时间 为${fs.checkpoint.period} 时：

1. 次（secondary）名称节点请求名称节点滚动edits文件，使新的edits log 放到另一个新生成的edits文件。

2. 次名称节点 通过 HTTP GET 获取名称节点的fsimage和edits文件

3. 次名称节点将fsimage文件载入 内存，并应用edits 文件中的每一项操作，这样就创建了一个新的合成的fsimage 文件。

4. 次名称节点采用 HTTP POST 方式 将刚合成的fsimage 发送回 名称节点

5. 名称节点用刚从次名称节点收到的fsimage代替老一版本的fsimage, 并用第一步中产生的edits 代替原先的edits，同时将fctime文件更新到checkpoint发生的时间

最终，名称节点就有了一份最新的fsimage文件和一个更短的edits文件（该edits文件不一定空，当次名称节点在执行checkpoint操作时，edits 可能已经记录下了一些hdfs系统的操作）