测试结果说明：
集群环境说明：
| 主机名 | 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集群中任何节点的硬盘故障对数据存储的完整性无影响。