[转]hadoop破坏试验可靠性验证

标签： | 发表时间：2013-04-09 10:19 | 作者：zeo112140

出处：http://blog.csdn.net/zeo112140

Hadoop集群环境测试报告

测试结果说明：

集群环境说明：

主机名	IP地址	操作系统版本	Hadoop版本	Hbase版本	Zookeeper版本	机器用途
hadoop1	192.168.3.65	Linux AS 4.8	hadoop-0.20.2	hbase-0.90.4	zookeeper-3.3.3	namenode
hadoop2	192.168.3.66	Linux AS 4.8	hadoop-0.20.2	hbase-0.90.4	zookeeper-3.3.3	datanode
hadoop3	192.168.3.67	Linux AS 4.8	hadoop-0.20.2	hbase-0.90.4	zookeeper-3.3.3	datanode
hadoop4	192.168.5.57	Linux AS 4.8	hadoop-0.20.2	hbase-0.90.4	zookeeper-3.3.3	datanode
hadoop5	192.168.5.58	Linux AS 4.8	hadoop-0.20.2	hbase-0.90.4	zookeeper-3.3.3	datanode

本次对于Hadoop集群测试主要分为五个方面：

1、手动进行datanode节点删除：（阵列卡电池损坏或者添加内存条等情况需要停机，需要手动删除节点，停止服务器运行）无需重启集群服务，保证文件系统的高可用性，数据的完整性，最后验证block副本数目在节点删除后是否恢复到默认设置（即3个副本）

2、手动进行datanode节点添加：（有淘汰的旧服务器不使用了，加入hadoop集群增加集群存储容量及节点数等）无需重启集群服务，验证数据的可靠性，架构的可扩展性，数据完整性等。

3、datanode节点被动删除：（服务器主板损坏，网络故障、操作系统故障等导致主机宕机）

datanode每三秒种向namenode发送心跳如果10分钟没有发送心跳，则namenode认为该datanode已经dead，namenode将取出该datanode上对应的block，对其进行复制。

测试过程，在hadoop的文件系统上创建一个30M文件，查看block副本文件的具体分布在哪三个datanode上面，确保第四个节点上无此副本，对其中一个节点执行关机操作，等待10分钟后，namenode节点确认datanode死掉后对其block副本进行复制。查看第四个datanode上是否有新的block副本，即：副本数目又达到3个。验证正常后下载文件，看文件是否能正常使用。

4、Datanode节点的磁盘损坏（所有磁盘完全坏掉，或者只是存放block副本的磁盘损坏）

此节点DataNode正常服务，坏掉的磁盘上的数据尽快通知Namenode，namenode对数据块进行复制，查看第四个datanode节点上是否新增了数据块（所损坏磁盘的datanode上存储的数据块）

5、人为原因操作失误删除了datanode节点上的数据块（此情况与4的磁盘损坏相似）

手动删除block数据块存放目录下的block文件，看一下多长时间恢复，在哪里恢复？

故障场景一、

手动删除集群中任何一台datanode数据节点

【测试描述】

模拟集群中hadoop2数据节点故障（datanode节点数量应该大于dfs.replication设置的文件块复制数，否则在删减datanode时不会成功，一直处于Decommission in process的状态）

【测试步骤】

1、把每个datanode节点的Block数量重定向一个目标文件为1.txt

2、本地上传一个30M的file.222文件到hdfs文件系统中，验证是否只有3个datanode节点有数据块？

3、再次统计每个datanode节点的Block数量重定向到目标文件2.txt，并且与1.txt文件比较有没有增加数据Block？

a) hadoop2数据节点已增加一个数据块

b) hadoop3数据节点已增加一个数据块

c) hadoop4数据节点已增加一个数据块

d) hadoop5数据节点未增加一个数据块

4、在namenode节点hadoop家目录的conf目录下新建一个excludes的文件，写上需要remove的节点IP地址，一行只能一个IP。

5、修改namenode节点的主配置文件core-site.xml，在configuration内增加如下内容：

6、在namenode节点执行hadoop dfsadmin –refreshNodes命令，它不用重启集群服务去读取core-site.xml配置文件，也会在后台进行Block块的移动，从移除的Nodes上移动到其它的Nodes上面。

7、通过hadoop dfsadmin –report查看集群状态能查看到数据是否移除完毕。只有192.168.3.66数据节点状态是移除状态。

观察一段时间后，等Decommissioned in progress状态变为Decommissioned后，表示此移除的Nodes节点上的所有数据块已全部被复制到其它工作正常的Nodes上，应为3份。

网页上也会显示把移除的节点剔除列表

8、验证hadoop5数据节点是否有上传过30M文件的数据块

9、下载hdfs文件系统中的file.222文件到本地，并且验证hbase是否可用？

【测试结果】

hadoop集群中手动删除任何其中一台datanode节点，对文件系统没有任何影响。

故障场景二、

手动增加一台datanode数据节点到集群

【测试描述】

模拟往正在运行的hadoop集群中增加一台datanode数据节点，验证是否影响文件系统的使用？

【测试步骤】

1、新datanode节点上部署jdk、hadoop、hbase、zookeeper软件，保证和所以集群中的机器的目录结构一致。并且配置相应的环境变量。

2、在新datanode节点和namenode节点之间建立无密码认证关系。实现互相登录不需要密码。

3、设置datanode节点的hosts文件和集群中所有的机器hosts文件一致。

4、 Namenode节点的slaves文件增加上相应的节点，并且Namenode的hosts文件也增加新节点。

5、在新节点启动datanode和tasktracker进程。如下图已把hadoop2数据节点加入到hadoop集群中了。中间一些其余的截图已省略。

【测试结果】

往hadoop集群中手动增加一台datanode不影响文件系统和hbase数据库的查看和使用。

故障场景三、

集群中其中一台datanode数据节点出现自动宕机故障。（此方法有点类似第一种）

【测试描述】

模拟hadoop集群中其中一台datanode数据节点宕机故障，验证是否影响文件系统和hbase的使用？

【测试步骤】

1、本地上传一个大小为30M的文件上传到集群文件系统。

2、查看哪三台机器上面有Block块的新增。分别是hadoop2、hadoop4、hadoop5三台机器

3、在任何一台有数据块的datanode节点执行关机操作，这里选择hadoop4机器。

4、观察集群的状态，Last Contact表示最后一次检查时间

十分钟之后再刷新一下网页会显示，宕机的节点已经被自动从集群中踢除了。

5、查看hadoop2主机没有Block块文件的节点是否已经有块文件复制过去？这样就实现达到了复制三份的目的了。

6、验证能否从文件系统下载test.file文件和hbase的使用？

【测试结果】

hadoop集群中任何一台datanode节点意外宕机，不会影响文件系统和hbase的使用。

故障场景四、

集群中其中一台datanode数据节点硬盘故障。

【测试描述】

模拟hadoop集群中其中一台datanode数据节点硬盘故障，验证是否影响文件系统和hbase的使用？

【测试步骤】

1、手动拔掉hadoop2节点的所有硬盘，hadoop集群仍然运行

2、 namenode节点会检查每个正常工作datanode的文件块是否都为3份，如果不是则会备份成3份放到正常工作的datanode节点中。

3、在任何别的节点上查看和读取文件系统的数据一切正常。

4、 hbase也一切正常。

【测试结果】

hadoop集群中任何节点的硬盘故障对数据存储的完整性无影响。

作者：zeo112140 发表于2013-4-9 10:19:00 原文链接

阅读：6 评论：0 查看评论