集群環境說明：
準備5臺服務器，hadoop1、hadoop2、hadoop3、hadoop4、hadoop5；
分別部署5個節點的zookeeper集群、hadoop集群、hbase集群
本次對于Hadoop集群測試主要分為五個方面：
- 手動進行datanode節點刪除：（陣列卡電池損壞或者添加內存條等情況需要停機，需要手動刪除節點，停止服務器運行）無需重啟集群服務，保證文件系統的高可用性，數據的完整性，最后驗證block副本數目在節點刪除后是否恢復到默認設置（即3個副本）
- 手動進行datanode節點添加：（有淘汰的舊服務器不使用了，加入hadoop集群增加集群存儲容量及節點數等）無需重啟集群服務，驗證數據的可靠性，架構的可擴展性，數據完整性等。
- datanode節點被動刪除：（服務器主板損壞，網絡故障、操作系統故障等導致主機宕機）
datanode每三秒種向namenode發送心跳如果10分鐘沒有發送心跳，則namenode認為該datanode已經dead，namenode將取出該datanode上對應的block，對其進行復制。
測試過程，在hadoop的文件系統上創建一個30M文件，查看block副本文件的具體分布在哪三個datanode上面，確保第四個節點上 無此副本，對其中一個節點執行關機操作，等待10分鐘后，namenode節點確認datanode死掉后對其block副本進行復制。查看第四個 datanode上是否有新的block副本，即：副本數目又達到3個。驗證正常后下載文件，看文件是否能正常使用。 - Datanode節點的磁盤損壞（所有磁盤完全壞掉，或者只是存放block副本的磁盤損壞）
此節點DataNode正常服務，壞掉的磁盤上的數據盡快通知Namenode，namenode對數 據塊進行復制，查看第四個datanode節點上是否新增了數據塊（所損壞磁盤的datanode上存儲的數據塊） - 人為原因操作失誤刪除了datanode節點上的數據塊（此情況與4的磁盤損壞相似）
手動刪除block數據塊存放目錄下的block文件，看一下多長時間恢復，在哪里恢復？
故障場景一、
手動刪除集群中任何一臺datanode數據節點
【測試描述】
模擬集群中hadoop2數據節點故障（datanode節點數量應該大于dfs.replication設置的文件塊復制數，否則在刪減datanode時不會成功，一直處于Decommission in process的狀態）
【測試步驟】
- 把每個datanode節點的Block數量重定向一個目標文件為1.txt
- 本地上傳一個30M的file.222文件到hdfs文件系統中，驗證是否只有3個datanode節點有數據塊？
- 再次統計每個datanode節點的Block數量重定向到目標文件2.txt，并且與1.txt文件比較有沒有增加數據Block
a) hadoop2數據節點已增加一個數據塊
b) hadoop3數據節點已增加一個數據塊
c) hadoop4數據節點已增加一個數據塊
d) hadoop5數據節點未增加一個數據塊 - 在namenode節點hadoop家目錄的conf目錄下新建一個excludes的文件，寫上需要remove的節點IP地址，一行只能一個IP。
- 修改namenode節點的主配置文件core-site.xml，在configuration內增加如下內容：
- 在namenode節點執行hadoop dfsadmin –refreshNodes命令，它不用重啟集群服務去讀取core-site.xml配置文件，也會在后臺進行Block塊的移動，從移除的Nodes上移動到其它的Nodes上面。
- 通過hadoop dfsadmin –report查看集群狀態能查看到數據是否移除完畢。只有hadoop2數據節點狀態是移除狀態。
觀察一段時間后，等Decommissioned in progress狀態變為Decommissioned后，表示此移除的Nodes節點上的所有數據塊已全部被復制到其它工作正常的Nodes上，應為3份。
網頁上也會顯示把移除的節點剔除列表 - 驗證hadoop5數據節點是否有上傳過30M文件的數據塊
- 下載hdfs文件系統中的file.222文件到本地，并且驗證hbase是否可用
【測試結果】
hadoop集群中手動刪除任何其中一臺datanode節點，對文件系統沒有任何影響。
故障場景二、
手動增加一臺datanode數據節點到集群
【測試描述】
模擬往正在運行的hadoop集群中增加一臺datanode數據節點，驗證是否影響文件系統的使用？
【測試步驟】
- 新datanode節點上部署jdk、hadoop、hbase、zookeeper軟件，保證和所以集群中的機器的目錄結構一致。并且配置相應的環境變量。
- 在新datanode節點和namenode節點之間建立無密碼認證關系。實現互相登錄不需要密碼。
- 設置datanode節點的hosts文件和集群中所有的機器hosts文件一致。
- Namenode節點的slaves文件增加上相應的節點，并且Namenode的hosts文件也增加新節點。
- 在新節點啟動datanode和tasktracker進程。如下圖已把hadoop2數據節點加入到hadoop集群中了。中間一些其余的截圖已省略。
【測試結果】
往hadoop集群中手動增加一臺datanode不影響文件系統和hbase數據庫的查看和使用。
故障場景三、
集群中其中一臺datanode數據節點出現自動宕機故障。（此方法有點類似第一種）
【測試描述】
模擬hadoop集群中其中一臺datanode數據節點宕機故障，驗證是否影響文件系統和hbase的使用？
【測試步驟】
- 本地上傳一個大小為30M的文件上傳到集群文件系統。
- 查看哪三臺機器上面有Block塊的新增。分別是hadoop2、hadoop4、hadoop5三臺機器
- 在任何一臺有數據塊的datanode節點執行關機操作，這里選擇hadoop4機器。
- 觀察集群的狀態，Last Contact表示最后一次檢查時間
十分鐘之后再刷新一下網頁會顯示，宕機的節點已經被自動從集群中踢除了。 - 查看hadoop2主機沒有Block塊文件的節點是否已經有塊文件復制過去？這樣就實現達到了復制三份的目的了。
- 驗證能否從文件系統下載test.file文件和hbase的使用？
【測試結果】
hadoop集群中任何一臺datanode節點意外宕機，不會影響文件系統和hbase的使用。
故障場景四
集群中其中一臺datanode數據節點硬盤故障。
【測試描述】
模擬hadoop集群中其中一臺datanode數據節點硬盤故障，驗證是否影響文件系統和hbase的使用？
【測試步驟】
- 手動拔掉hadoop2節點的所有硬盤，hadoop集群仍然運行
- namenode節點會檢查每個正常工作datanode的文件塊是否都為3份，如果不是則會備份成3份放到正常工作的datanode節點中。
- 在任何別的節點上查看和讀取文件系統的數據一切正常。
- hbase也一切正常。
【測試結果】
hadoop集群中任何節點的硬盤故障對數據存儲的完整性無影響。
