集群环境说明：

准备5台服务器，hadoop1、hadoop2、hadoop3、hadoop4、hadoop5；
分别部署5个节点的zookeeper集群、hadoop集群、hbase集群

本次对于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查看集群状态能查看到数据是否移除完毕。只有hadoop2数据节点状态是移除状态。
   观察一段时间后，等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集群中任何节点的硬盘故障对数据存储的完整性无影响。